Job success, catalog visibility, byte/hash checks and application startup are different evidence. Limit conclusions to tested data, methods and releases; one check does not guarantee recoverability of every backup.
Screenshots were captured from the actual lab interface on 16 October 2026. The interface is in English; explanations follow your selected language. Resource names, dates and settings are examples; use values for your own environment.
Visual note: earlier real lab catalog and recovery-point screens are reused. These are not evidence of a new validation job or successful restore. No backup/restore, data modification, deletion or integrity scan was performed during this content work.
Platform, release, repository and recovery point
Full/incremental chain and data scope
Isolated target, capacity and application owner
Measurable acceptance criteria and evidence record
01
1. Select the verification layer
Package checksums, backup file hashes, repository chunk verification and application consistency are different checks. Identify the data and release being checked. A SHA-256 match establishes identical bytes only against a trusted reference; alone it does not prove publisher identity or application consistency.
Expected result
The scope established by the check is defined.
02
2. Identify the recovery point and dependencies
Record the Full and required incrementals, parent relationship, disk/file scope and repository identity in the catalog. Do not ignore missing manifests, unreadable pieces or parent errors. A catalog listing does not establish readability of every piece.
Earlier real lab RESTORE selection screen. It shows Full/Incremental catalog points, not read data, a hash result or proof of a complete chain. Enlarge ↗
Expected result
The chain to inspect is explicitly listed.
03
3. Prepare a trusted hash baseline
Use the same algorithm and byte scope for source and restored copies of small unchanged test data. Keep names, sizes and hashes in an access-restricted evidence record. Hashing a potentially corrupted file today does not establish its past integrity.
Expected result
The origin and time of the hash reference are documented.
04
4. Validate the backend contract against the release
The RustFS native design specifies length and SHA-256 verification after each object read, manifest-last commit and shared Full/incremental chunks. These are design and release-dependent acceptance gates, not evidence of a passed production test on the installed backend. Never manually delete or alter referenced chunks.
Expected result
Backend claims are matched to installed-release evidence.
05
5. Distinguish the BTRFS verify limitation
The inspected erabackup_btrfs_dedup.py verify mode writes post-dedup usage snapshot to the verification field; it does not verify content hashes or perform restore. Successful mount/usage reporting does not establish byte integrity. report/verify can write report files; dedup changes extent sharing.
Expected result
Usage reporting is separated from content verification.
06
6. Preserve evidence on mismatch
On size/hash mismatch, preserve job, point, piece identity, time and error records. Recheck scope and time consistency between source and restored data. Do not corrupt production backups for fault tests or lose evidence through automatic repair, chunk deletion or cleanup.
Expected result
The mismatch is recorded with investigable evidence.
07
7. Complete with restore and application checks
Complete byte checks with isolated restore, file readability, permissions and application/DBA acceptance. State the tested chain and out-of-scope data in the report. Encryption, WORM or a matching hash alone does not establish acceptance of every recovery scenario.
Expected result
Integrity and recovery evidence are reported together.
COMMON QUESTIONS
Is BTRFS verify an integrity scan?
Not in the inspected tool. This mode is a post-dedup usage snapshot; content hashes and restore acceptance need separate checks.