No — a finished btrfs restore run, whether you invoked it directly or through an undelete helper script, is not a guarantee that the recovered file is byte-for-byte identical to the version you deleted. The result can be perfectly intact, partially recovered, or an older revision of the file. The tool is designed for salvage, not for certified recovery, so treat every restored file as unverified until you have actually checked it.
What a successful restore actually proves
btrfs restore bypasses the normal mount path. It walks filesystem trees directly from the device and copies file contents out to a destination directory. That makes it useful both for damaged filesystems and for fishing deleted files out of older tree roots. But because it operates in salvage mode, its consistency checks are deliberately looser than a normal mount would be, and its own documentation warns that it can retrieve data that is incomplete or belongs to an earlier version of the file.
A clean exit therefore tells you three things: metadata for the path was found, at least some extents were readable, and the tool finished. It tells you nothing about whether those extents still contain the bytes you last wrote. Seeing the correct filename next to a nonempty file is encouraging, but it is not an integrity check.
Three ways a recovered file can differ from the original
- Overwritten extents. Deleting a file frees its data extents for reuse. Any write that happens afterward — by the system, by another recovery attempt, or by the recovery tool itself — can consume those blocks. What comes back is then zeros or fragments of unrelated data stitched into your file.
- An older revision. Undelete tooling for btrfs typically locates previous tree roots left on disk and points
restoreat them, because the current tree no longer references the deleted file. The content you get is the state as of that older tree, which may lag your last save by minutes or weeks. A perfectly readable but outdated file is a real and common outcome. - Errors skipped silently. Some recovery wrappers invoke
btrfs restore -i, where-imeans "ignore errors and keep going" — and then discard the tool's output entirely, counting nonempty destination files as their success metric. That count says nothing about content. If you use such a script, at least capture the log:
btrfs restore -v --path-regex '^/home/user/\.config/.*$' /dev/sdb2 /mnt/rescue/out 2>&1 | tee restore.logReading what the tool complained about tells you far more than a file tally ever will.
How to verify a recovered file
If you have a reference copy
The only true proof of bit-level fidelity is comparison against a known-good version of the same pre-deletion file — a backup, a synced copy, an attachment you emailed yourself. Both cmp and a checksum pair will settle the question:
sha256sum recovered/memcard.ps2 backup/memcard.ps2
cmp recovered/memcard.ps2 backup/memcard.ps2 && echo identicalIf the hashes match, you are done.
If you have no reference
Preserve the recovered file untouched and run your checks on a copy. Start with cheap sanity checks: a standard PCSX2 memory-card image is a fixed size, so a recovered file shorter than expected is almost certainly truncated. Then test the copy in the application itself — confirm the card is recognized, the save list appears, and the saves you actually need load without errors. Understand what this proves: it demonstrates that the saves present are usable, not that every byte of the card survived or that your most recent progress is on it. A clean, readable file from last month can pass every one of these tests.
Limiting further damage while you work
- Stop writing to the affected filesystem immediately. Every write is a chance to overwrite the freed extents you are trying to salvage. If practical, remount it read-only:
mount -o remount,ro /mountpoint- Put the recovery output somewhere else.
btrfs restorenever writes to the source device, but if the destination lives on the same filesystem, its own allocations can consume the very blocks you are recovering. Use a different disk. - Keep the first result. Once you have a recovery attempt, copy it off and never let a subsequent run overwrite it.
Preventing the next scare
The cleanest fix is making recovery unnecessary. On btrfs, scheduled snapshots (via tools like snapper or timeshift) give you near-instant rollback points at trivial cost. Pair them with periodic backups to a separate device — btrfs send/receive between filesystems, or a file-level tool such as borg or restic — and keep one copy off the machine. For game saves specifically, backing up the memory-card images is small and cheap, and it converts a nerve-wracking salvage operation into a two-minute copy job. Shell hygiene helps too: quote variables, preview destructive commands with echo, and consider a trash utility instead of bare rm.
Frequently Asked Questions
Does btrfs restore verify data checksums?
Btrfs normally verifies checksums on every ordinary read, but restore is a salvage tool: depending on the version and flags, it reports or tolerates checksum problems rather than refusing output, and a flag exists to keep going past them. Even a checksum-clean read only proves that a block matches its recorded checksum — not that you recovered the newest version or every extent.
Will restore give me the latest version of the file?
Not necessarily. A default run reads the current trees, in which a deleted file no longer appears; undelete approaches work by walking older tree roots found on disk. The content you get reflects whichever tree was used, so staleness is a built-in possibility.
A script reported "N files recovered" — is that an integrity check?
No. Typical wrappers count nonempty files in the destination directory. That confirms files were written out, not that their contents are complete, current, or correct. Check the tool's log output instead, and verify the files themselves.
How likely is corruption in a recovered file?
There is no universal probability. The outcome depends on how much writing occurred after deletion, where the extents landed, filesystem layout, and how stale the tree used for recovery was. An intact older file and a partially mangled one are both plausible results, and finding the file does not distinguish between them.
Can I start using the recovered memory card directly?
Test a copy first, never the original. If the copy works in the emulator, continue working from further copies and export or back up the saves you care about. This keeps one pristine image available if a later problem appears.
What is the single most important rule during recovery?
Minimize writes. Halt activity on the affected filesystem, remount it read-only if you can, and direct all recovery output to a different disk. Everything else about recovery quality flows from how much of the freed data is still physically present when you read it.