Why Can a Repository Integrity Check Pass While One File Still Fails to Restore?

A repository check can pass while one file fails to restore when the check validates metadata or sampled data rather than that exact recovery path.

Backup verification is not one universal operation. Some checks confirm repository structure, indexes, manifests, and referenced chunks without reading every stored byte. Others sample data, skip files that were never captured, or say nothing about the destination filesystem’s names, permissions, ACLs, labels, free space, and application locks. Treat the failed file as a path from snapshot selection through stored objects to destination creation.

Identify Exactly What the Passing Check Verified

Save the check command, options, backup-tool version, repository backend, snapshot ID, and final log. Determine whether it checked repository structure, archive metadata, referenced chunks, stored data, or an actual extraction.

Borg states that its standard archive check reads metadata but not file data by default unless data verification is explicitly requested.

A green result therefore may prove that references are internally consistent while leaving some payload chunks unread. Do not label the repository fully restorable until representative files are extracted.

Determine Whether the File’s Stored Data Was Actually Read

Locate the file in the intended snapshot and identify the packs, chunks, or objects required to reconstruct it. Compare the failed restore with the repository check’s data-reading scope.

Restic documents read-data and read-data-subset checks, showing that a routine structural check and a full payload read are different verification levels.

If only a subset was read, the failed file may depend on an unchecked pack. Run a targeted or complete supported data check before attempting repair.

Confirm the File Was Included in That Snapshot

List the exact relative path in the selected snapshot. Check filters, exclusions, unreadable-source warnings, symlink rules, mount boundaries, and whether the restore UI selected another version.

Kopia warns that ignore policies omit matching paths, so repository consistency can pass even when the desired file was never captured.

A placeholder path or parent directory entry is not proof that the file payload exists. Compare snapshot inventory, size, hash, and timestamp with the expected source record.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Check Destination Filename and Path Constraints

Restore the same file to a short, empty local path using a simple name. Compare invalid characters, reserved names, case collisions, trailing spaces, path length, and Unicode normalization.

Microsoft’s file-naming guidance documents Windows filename and path restrictions that can reject one restored path while the repository itself remains healthy.

If the file restores to a temporary short path, the stored content is available. Correct the destination layout or rename mapping instead of repairing the repository.

Verify ACL, Extended-Attribute, and Ownership Restore

Repeat the restore with metadata preservation disabled only in a disposable target, then compare it with the normal metadata-aware restore. Record the first failed attribute.

GNU tar documents separate ACL and extended-attribute restoration, illustrating why file data can be readable while metadata application fails.

Do not accept a metadata-free restore as the production fix when applications depend on ACLs, ownership, sparse ranges, or xattrs. Use it only to identify the failing layer.

Check Security Labels and Destination Policy

Inspect SELinux labels, antivirus or endpoint protection, ransomware controls, immutable flags, share permissions, and application locks on the restore target.

Red Hat documents restoring default security contexts when files arrive with missing or inappropriate labels.

A file that extracts but cannot be opened may be a destination-policy failure rather than a repository failure. Test through the same user and application that needs the restored file.

Perform an Isolated Restore Before Any Repair

Restore the failed file, its parent metadata, and several nearby files into an empty dataset or temporary directory. Save hashes, logs, and repository state before running repair commands.

The ZimaSpace guide to checksum and metadata verification provides the adjacent distinction between stored content integrity and usable application recovery.

The issue is resolved when the selected file restores from the intended snapshot, matches its expected content, receives required metadata, and opens through the production application path.

Frequently Asked Questions

Does a passing repository check prove every file can restore?

No. It depends on whether the check read all stored data and whether the destination can recreate each path and its metadata.

Should I run repair immediately after one restore failure?

No. First test another destination, confirm the file exists in the snapshot, and run a supported data check. Repair can remove damaged metadata or objects.

Is a successful test restore stronger than a verification report?

Yes for the tested recovery path. It proves selection, decryption, payload reading, destination creation, and metadata handling for that specific sample.