keepcalculator

06 Numbers and Powers

Btrfs Data Recovery: How to Restore Files

Card No. 06·16352 · Updated · Standard formula, shown below

Btrfs data recovery is possible using built-in tools like btrfs restore, btrfs check, and snapshot rollbacks, but the success rate depends heavily on how quickly you stop using the drive and whether you have a recent snapshot. This article explains the practical methods, when each works, and the common pitfalls that turn a recoverable situation into a permanent data loss.

Background: Why Btrfs Is Different

Btrfs (B-tree File System) is a modern copy-on-write (CoW) filesystem for Linux. Unlike ext4 or XFS, it keeps multiple versions of data blocks and metadata, which gives it unique recovery advantages. Key features that matter for data recovery:

  • Snapshots: Instant, read-only or writable copies of the entire subvolume. If you have a snapshot from before the data was lost, recovery is trivial.
  • Checksums: Every data block and metadata block has a checksum, so corruption is detected immediately, rather than silently propagating.
  • Copy-on-write: When a file is modified, the old blocks are not overwritten immediately; they remain until a later reclamation. This means deleted or overwritten data may still exist in free space.
  • Self-healing: On a RAID setup with redundancy, Btrfs can automatically repair corrupted blocks from a good copy.

These features make Btrfs more resilient than traditional filesystems, but they also introduce new failure modes, like running out of metadata space or hitting a bug in an early version. Understanding these features is the first step in choosing the right recovery strategy.

How Btrfs Data Recovery Works

When you delete a file on Btrfs, the file’s data blocks are not immediately wiped. The directory entry is removed, and the block references are dropped, but the actual data remains in the free space until the filesystem reuses it. Similarly, if a file is overwritten, the old version’s blocks are still on disk until the CoW garbage collection reclaims them. This is why forensic recovery tools can often pull back deleted files, but only if you stop using the drive immediately.

Btrfs also has a dedicated recovery tool, btrfs restore, which scans the raw device for valid Btrfs structures and extracts files without mounting the filesystem. It works even if the filesystem metadata is partially corrupted, because it walks the B-tree and reads file extents directly. The tool is not a silver bullet: it may not recover file names or directory structure if the metadata is damaged, and it can be slow on large drives.

For filesystem-level corruption (e.g., after a power failure or a bug), btrfs check can repair metadata errors. It has a read-only mode (--readonly) to assess damage first, and a repair mode (--repair) that rewrites damaged structures. This is a last resort, because a wrong repair can cause further loss.

How to Recover from a Snapshot

If you have a snapshot that contains the file as it existed before deletion or corruption, recovery is a simple copy operation.

  1. Mount the Btrfs filesystem (or the snapshot subvolume directly) with mount -o subvol=@snapshots /dev/sdX /mnt/snap.
  2. Navigate to the snapshot’s subvolume and copy the desired files back to the live subvolume: cp -a /mnt/snap/path/to/file /mnt/live/path/to/file.
  3. If you want to roll back the entire subvolume to the snapshot, unmount the filesystem and use btrfs subvolume snapshot /mnt/snap /mnt/live after moving the current live subvolume aside.

This works even if the file was deleted from the live subvolume, because the snapshot still holds the old data. The main requirement is that you took a snapshot before the data loss occurred. If you have no snapshot, you must rely on the free-space recovery methods below.

Using btrfs restore for Deleted Files

When you have no snapshot, btrfs restore is the primary tool for recovering deleted files. It scans the device block by block and reconstructs files from the raw B-tree data.

  1. Unmount the filesystem immediately to prevent new writes from overwriting the deleted data.
  2. Run btrfs restore -t /dev/sdX /mnt/recovery to copy all recoverable files to a different drive. The -t flag tells it to preserve the directory structure.
  3. If the filesystem is severely damaged, use -o to allow recovery from a partially corrupted tree, or -D to recover only file data without metadata.
  4. After recovery, check the files for integrity. Files that were overwritten or partially corrupted may be incomplete.

The tool works best when the metadata is intact. If the metadata is gone, you can try btrfs restore -D to scan for file data blocks, but you will lose file names and directory structure. Recovery to a different drive is essential; writing recovered files back to the same drive risks overwriting the very data you are trying to save.

Common Problems and Mistakes

Many recovery attempts fail because of avoidable errors:

  • Continuing to use the drive. Every write, even a temporary file, can overwrite a deleted file’s data blocks. Unmount the drive or remount it read-only as soon as you notice data loss.
  • Running btrfs check –repair on a healthy filesystem. The repair mode is aggressive and can make things worse if the metadata is not actually corrupted. Always run btrfs check --readonly first and review the output.
  • Recovering to the same drive. Always copy recovered files to a different physical disk, ideally one connected via a different controller.
  • Ignoring checksum errors. If btrfs scrub reports checksum mismatches, that means data corruption is real. Do not ignore it; investigate before it spreads.
  • Using an outdated Btrfs version. Early Btrfs implementations had bugs that caused data loss. Always use a recent kernel (5.x or newer) and update the btrfs-progs package.

Another common misconception is that Btrfs is inherently unsafe. In reality, modern Btrfs is stable for most workloads, but it requires regular maintenance (scrub, balance) and snapshots to be truly resilient. The filesystem’s advanced features are only useful if you use them correctly.

Comparison with Other Filesystems

Compared to ext4, Btrfs offers significantly better recovery options. Ext4 has no native snapshots or checksums, so deleted files can only be recovered with third-party tools that scan raw blocks, and corruption is often silent. XFS is similar to ext4 in this regard, though it has better scalability for large files.

ZFS, the other major CoW filesystem, has similar snapshot and checksum features, but it is not natively supported in the Linux kernel (due to licensing) and requires a separate module. Btrfs is the only mainstream Linux filesystem that combines CoW, snapshots, checksums, and RAID-like features without extra software. For data recovery, the key difference is that Btrfs tools are built into the kernel and btrfs-progs, so you always have them available in a live environment.

Costs and Safety Considerations

Data recovery on Btrfs is free in terms of software, but it costs time and requires a spare drive. The time depends on the drive size and the extent of damage. A full btrfs restore on a 2 TB drive can take several hours. The only hardware cost is the destination drive, which should be at least as large as the source.

Safety is paramount. Never attempt recovery on a drive that is still mounted read-write. If the drive is failing (clicking, I/O errors), consider using a hardware write-blocker or cloning the drive first with ddrescue. Recovery tools are non-destructive in read-only mode, but btrfs check --repair modifies the filesystem, so it should be used only after a full backup (or clone) of the drive.

Alternatives to Built-in Tools

If btrfs restore fails, there are third-party tools, but they are not specifically designed for Btrfs. Tools like PhotoRec and TestDisk scan raw data and can recover files by their signatures, regardless of the filesystem. They are useful when the Btrfs metadata is completely destroyed, but they will not preserve file names or directory structure.

For professional recovery, commercial services use proprietary tools that can reconstruct Btrfs structures at a lower level. These are expensive (hundreds to thousands of dollars) and are only worth it for truly critical data. Before going that route, try the free methods described above, and always keep a backup strategy in place: regular snapshots, scrubs, and off-site backups are the cheapest insurance against data loss.

Frequently Asked Questions

Can I recover a deleted file from Btrfs without a snapshot?

Yes, if the file’s data blocks have not been overwritten. Use btrfs restore on an unmounted drive. The success rate drops the longer you use the drive after deletion, so stop writing immediately.

Does btrfs check –repair fix data corruption?

It repairs metadata corruption, not data corruption. If a data block’s checksum fails, btrfs check cannot recreate the data; it can only mark it as bad. On a RAID setup, it can reconstruct from a good copy.

Why can’t I mount my Btrfs drive after a crash?

It may be due to metadata corruption. Try mounting with usebackuproot option, which uses an alternate root from the backup copy. If that fails, run btrfs check --readonly to assess the damage.

How do I create a snapshot for future recovery?

Use btrfs subvolume snapshot -r /mnt/live /mnt/snapshots/$(date +%Y%m%d). Make it read-only with -r and schedule it regularly with cron or systemd timers.

Is Btrfs safe for production use?

Modern Btrfs (kernel 5.x and later) is stable for most workloads, but it requires regular maintenance: run btrfs scrub monthly and btrfs balance when free space is fragmented. Avoid using it on hardware with known issues until you have tested it thoroughly.

Related

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →