Restore an XFS Metadump Without Overwriting the Wrong Disk

Someone has handed you an XFS metadump and asked for it back as a filesystem image, and xfs_mdrestore is the only tool built for that job. You will inspect a dump first, restore it to a file or device, restore from a pipeline, and supply a separate log device when a version 2 metadump contains an external log. The examples match the installed xfs_mdrestore from xfsprogs 6.6.0.

Allow about 15 minutes for the command itself, plus the time needed to copy the resulting image. You need an XFS metadump created by xfs_metadump, enough destination storage, and a shell. Root access is normally required when the destination is a block device. A regular file can be used for a safer inspection workflow.

1. Confirm the installed tool

Check the version before you rely on examples or compare results with another machine. The manual is upfront that this is a debugging tool, not a general filesystem migration command:

$ xfs_mdrestore -V
xfs_mdrestore version 6.6.0

2. Identify a disposable target

The source is the metadump image. The target is where the restored filesystem image will be written. It can be a regular file or a device. Do not point the target at a mounted filesystem, a disk containing useful data, or a device whose identity you have not checked.

$ lsblk -o NAME,PATH,SIZE,FSTYPE,MOUNTPOINTS
$ findmnt --source /dev/EXAMPLE_DEVICE

Replace /dev/EXAMPLE_DEVICE with the device you have independently confirmed. The second command should not show a mounted filesystem that you intend to keep using. Unmounting a live system is an operational change; arrange that separately and confirm the correct mount point before doing it.

3. Inspect the metadump before restoring it

Use -i with only the source when you want information without specifying a target:

$ xfs_mdrestore -i /srv/forensics/source.metadump

If the image contains descriptive information, it is printed on standard output and the command exits. Older metadumps may not contain that information, so an empty or limited report is not proof that the image is unusable. It is still worth keeping the source path and the inspection output with your recovery notes.

$ xfs_mdrestore -i /tmp/does-not-exist.metadump
xfs_mdrestore: cannot open source dump file
$ printf '%s\n' "$?"
1

4. Restore to a regular file

A regular file gives you a reversible destination choice: if it is wrong, remove that output file rather than damaging a block device. Use a path with enough available storage and do not use a file that already contains data you need:

$ xfs_mdrestore /srv/forensics/source.metadump /srv/forensics/restored-xfs.img
$ printf '%s\n' "$?"
0

A zero exit status means that all metadata was restored successfully. The command does not turn the image into a mounted filesystem for you. Keep the restored file separate while you decide how to examine it. If the command fails, preserve its diagnostic output and do not treat a partial target as a successful recovery.

For a long-running restore, add -g to show progress on standard output:

$ xfs_mdrestore -g /srv/forensics/source.metadump /srv/forensics/restored-xfs.img

Progress is intended for a person watching the terminal. If another program consumes standard output, account for that output rather than assuming it is quiet.

5. Restore from a compressed stream

Use a hyphen as the source when the metadump is arriving on standard input. This lets a decompressor feed xfs_mdrestore without creating an intermediate image:

$ gzip -dc /srv/forensics/source.metadump.gz | xfs_mdrestore - /srv/forensics/restored-xfs.img

Keep the target as the final argument. The pipeline's exit status can hide an early failure in some shells. In an automated recovery script, use a shell with pipeline failure handling and record the final status instead of assuming that a completed pipeline restored the image.

6. Handle an external log in a version 2 dump

A version 2 metadump can include metadata from an external log. In that case, supply -l and the device or file to which the log contents should be copied:

$ xfs_mdrestore -l /srv/forensics/restored-log /srv/forensics/source.metadump /srv/forensics/restored-xfs.img

The path after -l is a destination, not a label or a place to look up the original log. Treat it as destructive and verify it independently. Do not invent a log destination because the option is present; use the storage layout required by the filesystem image you are restoring.

If the dump does not use an external log, omit -l. If you are unsure which form was used, inspect it with -i and consult the notes from the person or process that created the metadump.

7. Check the result and clean up deliberately

Every successful restore returns status 0. Every error returns status 1. Capture that status immediately, before running another command:

$ xfs_mdrestore /srv/forensics/source.metadump /srv/forensics/restored-xfs.img
$ status=$?
$ printf 'xfs_mdrestore exit status: %s\n' "$status"
xfs_mdrestore exit status: 0

For further filesystem checks, use the XFS tools appropriate to your evidence-handling plan. Do not mount a recovered image read-write merely to see whether it looks right. If you created a disposable file and no longer need it, remove that exact file after confirming its path:

$ ls -l -- /srv/forensics/restored-xfs.img
$ rm -- /srv/forensics/restored-xfs.img