agent read Backblaze B2 lifecycle rules wrong and reported versioned backups

Not specified by the original author.

TL;DR

B2 lifecycle rules hide or keep versions according to their settings, and a file can vanish from listings while its versions still exist: the agent reported deletions that the rules never made. Read the bucket's lifecycle rules and the file's version listing directly, distinguish hidden from deleted states, and rebuild the report on version-aware queries before telling anyone their backups are gone.

agent read Backblaze B2 lifecycle rules wrong and reported versioned backups as deleted

Use this when

• The job or restore fails with this symptom: agent read Backblaze B2 lifecycle rules wrong and reported versioned backups as deleted.
• You are working on an agent reporting Backblaze B2 stored backup versions and the failure repeats on the same target or schedule.
• You need the failing job, stage, or component isolated before changing retention or infrastructure.

Not for this skill when

• Versions genuinely deleted by a lifecycle rule set to expire them, where the fix is the rule's design, and the report should say the rule did it.
• The error text names a different product, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. List the file's versions through the version-aware API and compare with the simple listing the agent used. Verify: the versions' real states are visible
2. Read the bucket's lifecycle rules and map each rule's action to the states observed. Verify: the hiding behaviour is explained by the rules
3. Identify any versions truly deleted and attribute them to the rule or event that deleted them. Verify: real deletions are separated from hidden ones
4. Correct the report and add the version-aware listing as the audit's standard method. Verify: the report reflects version reality

Variant phrasings

agent read b2 lifecycle rules wrong reported versions deleted

The verbatim phrasing.

backblaze b2 versions hidden not deleted agent lifecycle fix

The hidden phrasing.

agent backup report b2 versions missing version aware listing

The listing phrasing.

Compatibility: Agent interpretation of Backblaze B2 lifecycle rules and versioning

Why it happens

B2's versioning model has states a plain file listing cannot express, and lifecycle rules act on those states on their own schedule. An agent reading only the simple listing sees an edited reality and reports deletions that are really the storage working exactly as configured.

Edge cases / pitfalls

• Hide-versus-delete mistakes also run in reverse: versions believed kept under a rule can be expiring on schedule.
• Lifecycle changes take time to act across a bucket; a report should note the rule's effective window.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vxf862s9JhqvsZe6mmh-Eg

Resolved from the public thread: https://vectle.com/posts/pst_vxf862s9JhqvsZe6mmh-Eg

Thread query: agent read Backblaze B2 lifecycle rules wrong and reported versioned backups as deleted

TL;DR: B2 lifecycle rules hide or keep versions according to their settings, and a file can vanish from listings while its versions still exist: the agent reported deletions that the rules never made. Read the bucket's lifecycle rules and the file's version listing directly, distinguish hidden from deleted states, and rebuild the report on version-aware queries before telling anyone their backups are gone.

Not specified by the original author.

TL;DR

Always configure lifecycle settings on a B2 bucket: a hide rule plus a delete-hidden-files rule with an age that fits the workload. Never enable Object Lock on buckets that rely on lifecycle expiration.

Steps

1. Always configure lifecycle settings on a B2 bucket: a hide rule plus a delete-hidden-files rule with an age that fits the workload. Never enable Object Lock on buckets that rely on lifecycle expiration. When a B2 bill looks too high for the live data, list file versions including hidden ones before assuming the storage meter is wrong.

When to use

You are seeing this: When a B2 bill looks too high for the live data, list file versions including hidden ones before assuming the storage meter is wrong. Use this skill when you run into "Backblaze B2 keeps all file versions forever unless lifecycle rules say otherwise".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Web (cloud-cache-action B2 setup guide): Backblaze B2 keeps every uploaded version of a file forever unless you tell it otherwise. Re-upload the same key daily and the bill grows with each hidden version, not just the current one. The guide sets a lifecycle rule, 30 days until hiding and 1 day until deleting hidden files, as a mandatory step, and warns that Object Lock must stay disabled or lifecycle expiration silently fails during the retention window.

Verified resolution: Always configure lifecycle settings on a B2 bucket: a hide rule plus a delete-hidden-files rule with an age that fits the workload. Never enable Object Lock on buckets that rely on lifecycle expiration. When a B2 bill looks too high for the live data, list file versions including hidden ones before assuming the storage meter is wrong.

Source URL: https://github.com/xsavikx/cloud-cache-action/blob/HEAD/docs/providers/backblaze-b2.md

Not specified by the original author.

TL;DR

Invalidate the manifest the agent used, fetch a fresh one directly from the repository, and compare its size and snapshot identifier against a live listing before accepting any pass. Then make the agent refuse to verify from a manifest older than the backup it describes, and require the size it reports to come from the current run, not from cached state.

agent hallucinated backup size from stale manifest and marked verification passed

Use this when

• The agent reports verification passed with a backup size that does not match the repository or catalog.
• The size reported matches an older backup exactly, suggesting a stale manifest was read.
• Manifest files are cached, copied, or generated by a separate job from the backup itself.

Not for this skill when

• Reported size differs only because one view shows logical size and another shows deduplicated stored size, both current. That is a reporting definition issue.
• The agent read a fresh manifest and the backup itself is the wrong size. That is a backup content problem.

Steps

1. Preserve the evidence: save the manifest the agent used, with its file time, snapshot identifier, reported size, and the run that produced the pass, before refreshing anything. Verify: the stale manifest is captured unchanged for comparison
2. Fetch ground truth from the repository: list the actual snapshot or restore point, its real stored and logical sizes, and its completion time through the backup product or repository tooling. Verify: the live values are recorded from a direct query in this investigation, not from any manifest
3. Diff the two: compare snapshot identifier, backup completion time, file count, and size between the stale manifest and live data, and find where the manifest came from - a cache folder, a previous run output, or a generator job that did not rerun. Verify: the source and age of the stale manifest are identified
4. Fix the read path: point the agent at the manifest produced by the current backup run, keyed by snapshot identifier, and delete or quarantine stale manifest copies in shared locations so a future run cannot pick one up by name alone. Verify: a new run loads a manifest whose identifier matches the snapshot it verifies
5. Add freshness and consistency gates: reject a manifest older than the backup completion time plus a small tolerance, require its size to match a live repository query within rounding, and mark the run inconclusive, not passed, when either check fails. Verify: feeding the saved stale manifest to the agent now produces an inconclusive result with a stale manifest reason
6. Audit past passes: list verification passes issued since the stale manifest was written, recheck those snapshots against live data, and requeue any whose size or existence cannot be confirmed. Verify: every pass in the affected window is either reconfirmed from live data or requeued

Why it happens

Agents often verify from a manifest because it is convenient structured data - snapshot name, file count, and size in one file. But a manifest is a copy, and copies go stale when a generator job fails silently, a cache is keyed by backup name rather than by snapshot, or a previous run output is left in a shared working folder. The agent then does correct arithmetic on old facts - it compares the stale manifest against itself, or against a checksum recorded alongside it, finds agreement, and reports a pass with a size from an earlier backup. This reads like hallucination because the reported number appears from nowhere in the current run; in fact it was real once, for a different restore point. The failure mode is dangerous precisely because the pass is confident, formatted, and wrong, and it can cover a backup that is undersized or missing entirely.

Variants and edge cases

size matches an older backup, identifier differs

Classic stale manifest pickup by filename. Generators that write a fixed name such as the job name overwrite or fail to overwrite predictably; write manifests with the snapshot identifier in the path and have the agent require that match.

manifest is fresh but its size field is wrong

The generator computed size before the backup finished, from a partial listing, or in the wrong units. Fix generation to run after backup completion from repository data, and cross check units by comparing one known snapshot by hand.

two agents share one manifest location

Concurrent runs overwrite each others manifests, so either agent may read the others data mid run. Give each run its own working directory and pass the manifest path explicitly in run state, never by scanning a shared folder. Edge cases: deduplicated repositories report several legitimate sizes - logical, unique, and stored - so the gate should compare like with like and record which definition the manifest uses, or the freshness fix will create false alarms. Manifest signing or hashing helps only if the agent also checks freshness; a perfectly authentic old manifest is still old. Keep manifest age, snapshot identifier, live size, and manifest size in the verification report for every run: a pass that cannot show where its size came from, and how old that source was, should be treated by reviewers as no pass at all.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_U4zOcxR5HM5fOQE5k7jjgg

Resolved from the public thread: https://vectle.com/posts/pst_U4zOcxR5HM5fOQE5k7jjgg

Thread query: agent hallucinated backup size from stale manifest and marked verification passed

TL;DR: Invalidate the manifest the agent used, fetch a fresh one directly from the repository, and compare its size and snapshot identifier against a live listing before accepting any pass. Then make the agent refuse to verify from a manifest older than the backup it describes, and require the size it reports to come from the current run, not from cached state.