Recover a Btrfs Superblock from a Verified Backup Copy

You will check a Btrfs backup superblock, run a read-only filesystem check against it, and only then use btrfs-select-super to replace the device's superblock copies. The installed command is from btrfs-progs 6.6.3. Allow at least 20 minutes for the checks, plus a maintenance window for an important filesystem.

This is a recovery operation, not routine maintenance. You need root access, an unmounted Btrfs device, a known device path, and a current backup or disk image if the operation goes wrong. Do not practise the final command on a real device. Use a disposable test device if you need to learn the syntax.

1. Identify the standalone command and the device

btrfs-select-super is a standalone program in this installation. It is not the btrfs select-super subcommand, so invoking the latter is an error. Confirm the binary and package version without changing anything:

$ command -v btrfs-select-super
/usr/bin/btrfs-select-super
$ dpkg-query -W -f='${Package} ${Version}\n' btrfs-progs
btrfs-progs 6.6.3-1.1build2
$ btrfs-select-super --help
btrfs-select-super: invalid option -- '-'
usage: btrfs-select-super -s number dev

The help output above is the installed program rejecting the GNU-style help spelling. The useful syntax is -s number device. Do not copy a command that uses btrfs select-super, and do not assume a newer package has identical help text.

2. Stop access to the filesystem

The manual requires the device to be unmounted. Find the device and its mount points first:

$ findmnt --source /dev/DEVICE
$ lsblk -o NAME,TYPE,FSTYPE,SIZE,MOUNTPOINTS /dev/DEVICE

Replace /dev/DEVICE with the actual block device, such as a whole disk or partition. If it is mounted, stop the services using it and unmount it through your normal change procedure. Do not use --force on a check to work around an active mount. A mounted device can change while you are examining it, making the diagnosis unreliable and risking further damage.

Checkpoint: rerun findmnt --source /dev/DEVICE. It should print no mounted filesystem before you continue. If the Btrfs filesystem spans several devices, identify every member and follow the same maintenance plan for the filesystem as a whole.

3. Inspect the backup superblocks

Btrfs stores superblock copies at fixed offsets when the device is large enough: the primary is at 64 KiB, copy 1 at 64 MiB, and copy 2 at 256 GiB. A copy is usable only when its offset exists on the device. Use the read-only inspection command to examine a candidate:

$ sudo btrfs inspect-internal dump-super --super 1 /dev/DEVICE
$ sudo btrfs inspect-internal dump-super --super 2 /dev/DEVICE

Look through the output for the Btrfs signature, checksum status, device and filesystem identifiers, and generation information. The exact values are host-specific. A command that prints text is not proof that the copy is sound: the tool performs only limited sanity checks and reports the superblock checksum status. Compare copy 1 and copy 2 with the known filesystem identity before choosing one.

Do not select a copy merely because it is the newest or because it is the first command that succeeds. A damaged backup can be readable but inconsistent. If neither backup has a valid signature and checksum, stop and use a filesystem image or specialist recovery process instead.

4. Check the candidate without repair

Use btrfs check with the same superblock number. It is read-only by default, and --readonly makes that choice explicit. Do not add --repair during this assessment:

$ sudo btrfs check --readonly --super 1 /dev/DEVICE
$ sudo btrfs check --readonly --super 2 /dev/DEVICE

Run the command separately for each candidate that passed inspection. A successful exit status means the selected starting superblock passed this structural check; it does not prove that every file or data block is healthy. If the output reports errors, or the two candidates describe different filesystem identities or generations, stop and investigate. Do not guess between conflicting copies.

Checkpoint: record the candidate number and the output from both dump-super and btrfs check. The command you eventually run will overwrite state on the device, so this record is part of your rollback plan.

5. Warn everyone before the destructive operation

Before proceeding, confirm all of these points:

• The device path is correct and is not a mounted filesystem.
• The chosen copy passed inspection and btrfs check --readonly.
• You have stopped services that could use the device and have a recovery image or backup.
• Everyone who needs the filesystem understands that the command changes on-disk metadata immediately.

Use elevated privileges for the final write. A normal user should not be able to alter a block device, and adding sudo does not make an unverified choice safe.

6. Select the verified backup copy

Replace 1 with the candidate you verified, and replace /dev/DEVICE with the exact device path:

$ sudo btrfs-select-super -s 1 /dev/DEVICE

The normal success output is brief or empty. Treat the exit status as the first checkpoint:

$ printf 'btrfs-select-super exit status: %s\n' "$?"
btrfs-select-super exit status: 0

Capture the status immediately, before running another command. A non-zero status means the operation did not complete normally; keep the device unmounted and review the error rather than retrying with a different copy.

7. Verify the result before remounting

Inspect the primary copy and repeat the structural check against it:

$ sudo btrfs inspect-internal dump-super --super 0 /dev/DEVICE
$ sudo btrfs check --readonly --super 0 /dev/DEVICE

The output should now describe the filesystem you selected, with a valid signature and checksum status. The read-only check should complete successfully. If it does not, do not mount the filesystem or run repair commands as a reflex. Preserve the device state and use the backup or recovery plan you prepared.

Only after verification should you remount it and restart dependent services. Then check the filesystem from its mount point and review service logs. Keep the original recovery image until the filesystem has been used successfully and a fresh backup has completed.