Recovering a BTRFS partition on a Western Digital WD4000F9YZ disk after a power failure requires checking for metadata corruption, running a read-only scrub to identify bad blocks, and remounting with the ro option if necessary. This process prioritizes data integrity over immediate write access, preventing further damage during the diagnostic phase.
Initial Assessment and Safety Precautions
A sudden power loss can leave the BTRFS file system in an inconsistent state, particularly if journal transactions were not flushed to the disk. The first step is to ensure the system does not attempt automatic mounting of the affected partition upon boot. If the disk is detected as part of a RAID array or multi-device setup, removing it from the active pool temporarily prevents kernel-level background tasks from causing additional writes.
Connect the WD4000F9YZ disk to your Linux machine. Identify the correct device name using dmesg | grep -i sd or lsblk. It is critical to distinguish between the physical disk (e.g., /dev/sdb) and its partitions (e.g., /dev/sdb1). Mounting the wrong device will result in errors or data loss on unrelated volumes. Always proceed with caution when dealing with raw block devices.
Checking Disk Health and SMART Data
Before attempting file system repairs, verify that the hardware itself is not failing. Power failures often coincide with underlying drive issues, especially on older mechanical drives like the 4TB Western Digital model. Use the smartctl utility from the smartmontools package to retrieve self-monitoring, analysis, and reporting technology data.
sudo smartctl -a /dev/sdXLook for reallocated sector counts, pending reallocation reports, or any flags indicating "Pre-fail" attributes that have exceeded their thresholds. If the drive shows signs of physical degradation, prioritize data extraction over repair. A healthy drive with logical corruption is recoverable; a failing drive may become unreadable during aggressive repair attempts.
Running a Read-Only Scrub
BTRFS provides a built-in mechanism called a scrub to check data integrity across all mirrors and parity information. After a power failure, this is the most reliable way to identify corrupted checksums without risking further instability. Crucially, you must run this operation in read-only mode initially to prevent the kernel from attempting to fix issues while they are being identified.
If the partition is currently mounted, unmount it first:
sudo umount /mnt/your_mount_pointThen, start the scrub process. Note that BTRFS scrubs do not have a strict "read-only" flag in the same way mount options do, but by avoiding any write operations prior to the scrub, you ensure the filesystem state remains static. You can monitor progress via:
cat /sys/fs/btrfs//scrub/status Replace <UUID> with the actual UUID of your BTRFS partition, found via btrfs filesystem show. If the scrub reports errors, specifically "checksum verify failed," refer to BTRFS Corrupted Filesystem: Checksum Verify Failed for detailed remediation steps involving forced checks and potential data recovery tools.
Repairing Metadata Corruption
If the scrub identifies inconsistencies, or if the filesystem refuses to mount cleanly, you may need to force a repair. The btrfs check command is used for offline repairs. Never run this on a mounted filesystem unless explicitly instructed by support documentation, as it can cause catastrophic data loss.
sudo btrfs check --readonly /dev/sdX1The --readonly flag allows you to see what errors exist without applying fixes. Review the output carefully. If the report indicates minor transaction log issues, you might attempt a non-destructive repair by removing the --readonly flag. However, always create a bit-for-bit image of the partition using dd before applying any changes.
In cases where deleted files are causing persistent scrub errors despite successful recovery, consider reading BTRFS: Persisting Deleted Files Scrub Errors to understand how orphaned inodes interact with the scrubbing process.
Mounting and Verification
Once repairs are complete, attempt to mount the partition again. Use the ro (read-only) mount option first to verify that all data is accessible and readable. This confirms that the structural integrity has been restored.
sudo mount -o ro /dev/sdX1 /mnt/recovered_dataIf the mount succeeds and data is visible, copy critical files to a safe location. Only after verifying data integrity should you remount the filesystem in read-write mode. If the initial mount fails with I/O errors, the issue may be deeper than filesystem corruption, possibly requiring specialized recovery software or professional services.
Frequently Asked Questions
Can I use fsck on a BTRFS partition?
No, fsck is designed for ext4 and other traditional filesystems. Using it on BTRFS can destroy the filesystem structure. Always use btrfs check or btrfs rescue commands instead for offline diagnostics and repair.
What if the drive is not detected by lsblk?
If the drive is not listed, check the physical connections and SATA ports. Run dmesg | tail immediately after connecting the drive to see kernel messages about detection. Electrical issues from the power failure may have damaged the controller interface.
Is it safe to run btrfs check without readonly?
It is generally unsafe unless you have a backup image. Running btrfs check without --readonly applies fixes that cannot be undone. Always create a full disk image using dd before allowing any tool to modify the partition table or superblocks.
Why does my scrub report missing chunks?
Missing chunks usually indicate that parts of the filesystem metadata are unrecoverable due to severe corruption or disk surface defects. This often happens after abrupt power losses where the last few sectors were not written. In such cases, data recovery may be partial.
Should I replace the WD4000F9YZ after this event?
If SMART data shows increased reallocated sectors or high temperature spikes during the scrub, the drive is degrading. Mechanical stress from power loss can exacerbate existing weaknesses. For critical data storage, replacing the drive is recommended even if the filesystem appears repaired.