agent validated a backup by its file size alone and missed in-archive corruption found on extraction

TL;DR

Size is a property of the container, not of the contents: a backup can be exactly the right size and corrupt inside, which only extraction reveals. Validate by extracting, fully for small archives and by sampled members plus archive integrity testing for large ones, and hash the extracted sample against source hashes where they exist. Record the validation method per archive so a size-only pass is never mistaken for an extraction pass later.

agent validated a backup by its file size alone and missed in-archive corruption found on extraction

Use this when

• The job or restore fails with this symptom: agent validated a backup by its file size alone and missed in-archive corruption found on extraction.
• You are working on an agent validating backup archives for restorability 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

• An archive format with a strong internal integrity check that the agent can run in full, where extraction sampling supplements rather than replaces it.
• The error text names a different product, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Re-validate the archive in question by extraction and catalogue what the corruption actually damaged. Verify: the true state of the archive is known
2. Define the validation ladder: size and metadata, archive integrity test, sampled extraction, and full extraction for the smallest tier. Verify: methods are explicit per tier
3. Implement sampled extraction with member hashes compared against a manifest where the backup tool provides one. Verify: sampling verifies content, not just readability
4. Mark historical validations that used size alone as unverified and queue the critical archives for real validation. Verify: the backlog of false assurance is visible
5. Report validation results with the method named, so consumers can weigh the assurance level. Verify: reports distinguish proof levels

Variant phrasings

agent validated backup file size alone missed corruption extraction

The verbatim phrasing.

backup validation extraction integrity test not size agent fix

The extraction phrasing.

agent archive corrupt inside size correct sampled extraction verify

The sampling phrasing.

Compatibility: Agent backup validation methods beyond file size inspection

Why it happens

Corruption lives inside archives, in member data that containers describe only by size and name until read. A validation that never opens the archive can only certify that a file exists with plausible dimensions, which is why extraction, the cheapest form of an actual restore, is the floor for calling a backup verified.

Edge cases / pitfalls

• Sampling rates should rise with archive age and storage tier risk, not stay flat.
• A failed extraction on one member condemns the archive for restore purposes even if other members read fine.

Provenance

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

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

Thread query: agent validated a backup by its file size alone and missed in-archive corruption found on extraction

TL;DR: Size is a property of the container, not of the contents: a backup can be exactly the right size and corrupt inside, which only extraction reveals. Validate by extracting, fully for small archives and by sampled members plus archive integrity testing for large ones, and hash the extracted sample against source hashes where they exist. Record the validation method per archive so a size-only pass is never mistaken for an extraction pass later.