Filesystem check, repair, and recovery with fsck and xfs_repair · Linux

Filesystem corruption is rare but happens: unclean shutdown, bad disk, kernel bug, hardware failure. The recovery process is different for ext4 vs XFS, but the discipline is the same: unmount first, check second, repair last, and always have a backup.

The discipline

fsck for ext4

Read-only / Safefsck -n— fsck -n opens the filesystem read-only and answers no to every question, so it never writes. It is still only meaningful on an unmounted or read-only-mounted filesystem. Against a mounted read-write filesystem the kernel dirty cache makes e2fsck report inode and block-count errors that do not exist. To check a live root filesystem, remount read-only (mount -o remount,ro /) or boot to rescue.target first.

$ fsck.ext4 -n /dev/sda1

e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda1: 12345/6553600 files (0.2% non-contiguous), 234567/26214400 blocks

A common mistake is to treat -n as a licence to check anything, including a mounted production root. It is not. Read-only means e2fsck will not write; it does not mean the answer is true. The kernel is mutating the same metadata while e2fsck reads it, so e2fsck sees a torn view and reports phantom corruption. An on-call engineer who acts on that output escalates a healthy host into an unnecessary emergency unmount.

Read-only / Safefsck -p— fsck -p is automatic repair - it fixes simple problems (unconnected inodes, bad blocks) without prompting. Use when fsck -n finds problems and you trust the auto-repair.

$ fsck.ext4 -p /dev/sda1

e2fsck 1.47.0 (5-Feb-2023)
/dev/sda1: clean, 12345/6553600 files, 234567/26214400 blocks

xfs_repair for XFS

Read-only / Safexfs_repair -n— xfs_repair -n is read-only. It scans all metadata for inconsistency. Use this to verify filesystem health before any other action.

$ xfs_repair -n /dev/sda1

Phase 1 - find and verify superblock...
Phase 2 - scan filesystems for bad magic numbers...
Phase 3 - scan inodes for bad magic numbers...
done

Data-loss riskxfs_repair— xfs_repair without -n repairs the filesystem. It is not lossless: orphaned inodes are reconnected into lost+found renamed to their inode number, so files lose their original path and name, and quota information may be partially or entirely cleared (xfs_repair warns before exiting if so). Snapshot the block device first - an LVM, EBS or VM-disk snapshot is your only undo. Run only on an unmounted filesystem, and re-check quota configuration afterwards.

$ xfs_repair /dev/sda1

Phase 1 - find and verify superblock...
Phase 2 - scan filesystems for bad magic numbers...
Phase 3 - scan inodes for bad magic numbers...
Phase 4 - scan directory entries...
Phase 5 - rebuild directory tree...
Phase 6 - rebuild link counts...
Phase 7 - rebuild freespace information...
Maximum filesystem writebacks: 0
done

xfs_repair must have the filesystem unmounted, and it is not lossless

Two rules, both from man 8 xfs_repair.

The filesystem must be unmounted. Running xfs_repair against a mounted filesystem produces an inconsistent or corrupt result. There is no -f-style override that makes this safe. For a root filesystem, boot to rescue media.

Repair loses data. It is often described as conservative, and that description is wrong. Three documented loss modes:

Allocated, in-use but unreferenced inodes are reconnected into lost+found and renamed to their inode number. The file survives; its path and name do not.
Unrecoverable inodes are cleared outright.
Quota information may be partially or wholly cleared. If all quota state is lost, quotas are disabled and must be rebuilt.

So the discipline is identical to the fsck case: snapshot the block device before the repair run, and verify quota configuration after it. The snapshot is the only undo.

Common recovery scenarios

Recovering from a corrupted superblock

Read-only / Safemke2fs -n— mke2fs -n prints the superblock parameters without writing anything. Use this to see the filesystem parameters, then restore from a backup superblock with e2fsck -b.

$ mke2fs -n /dev/sda1

mke2fs 1.47.0 (5-Feb-2023)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum

Run mke2fs -n /dev/sda1 to see the superblock parameters
Run e2fsck -b 32768 /dev/sda1 to restore from superblock backup at block 32768
If that fails, try other backup locations: 98304, 163840, 229376, 294912
Mount and verify: mount /dev/sda1 /mnt; ls /mnt
If all superblock backups fail, restore from filesystem backup

Recovering from a full journal

Configuration changeumount— A full journal is often the cause of read-only mounts. Unmounting the filesystem is the first step in recovery. If the mount is stuck in read-only mode, umount -l /data (lazy unmount) is the next option, but it is not safe for repair.

$ umount /data

Data-loss riskxfs_repair -L— -L zeroes the log. Use when the log is corrupted and the journal cannot be replayed. This is a last-resort option - any pending metadata changes in the log are lost. Use only when the filesystem refuses to mount due to log corruption.

$ xfs_repair -L /dev/sda1

Phase 1 - find and verify superblock...
Phase 2 - scan filesystems for bad magic numbers...
Phase 7 - rebuild freespace information...
Maximum filesystem writebacks: 0
done