Filesystem repair strategies

In this lesson, you will learn how to safely detect and repair filesystem corruption using the fsck utility to restore data integrity.

When a filesystem experiences an unclean shutdown or hardware-level error, the metadata (the information describing where files live) can become inconsistent. Modern filesystems like Ext4, XFS, and Btrfs use journaling to mitigate this, but if the underlying structure is damaged, you must intervene.

The Golden Rule: Never Run fsck on a Mounted Filesystem

The most critical rule in filesystem repair is that the partition must be unmounted. If you run a repair tool on a mounted partition, the utility and the kernel will both attempt to write to the disk simultaneously, which can lead to catastrophic data loss.

Using fsck Safely

The fsck (filesystem check) command is a frontend that calls the specific repair tool for your filesystem type (e.g., fsck.ext4 or fsck.xfs). To repair a partition, identify it using the block device abstraction layer (e.g., /dev/sda1) and unmount it first:

# 1. Unmount the device
sudo umount /dev/sda1

# 2. Run the repair
sudo fsck -y /dev/sda1

The -y flag tells the utility to automatically answer "yes" to all repair prompts. If you prefer to manually approve every change to the filesystem structure, omit the -y.

Special Considerations

• Ext4: If fsck reports heavy corruption, it may move orphaned files into a lost+found directory located at the root of that partition. Check this directory after a repair to recover salvaged data.
• XFS: Unlike Ext4, fsck.xfs (often called xfs_repair) is designed to handle filesystem metadata repair. Note that for XFS, you should never attempt to repair a mounted partition, as the tool is specifically designed to work on unmounted volumes to prevent further corruption.
• Btrfs: Btrfs uses different logic. While btrfs check exists, always attempt a "read-only" check first to analyze the state before attempting a repair, as Btrfs’s copy-on-write nature makes recovery significantly different from traditional journaling filesystems.

If a filesystem fails to mount during boot, the system often drops you into an emergency shell. In this state, the partition is usually unmounted, allowing you to run these repair tools directly to restore system stability.

Key Takeaway: To prevent permanent data loss, always unmount a filesystem before running repair utilities, and prioritize read-only diagnostics before applying automated fixes.