For the purpose of disaster recovery we do wish to backup:

  1. GPT partition table,
  2. disk geometry (to restore to different sizes drives)
  3. and the corresponding file system type and file system settings of each partition.

For example rsync can do the remaining file and folder backup and restore part. The five partitions on a GPT partitioned disk and its FAT and RAID-1 style BTRFS file systems need to be back-upped too.

Sgdisk doesn't restore file system

There are sgdisk drive backup and restore commands. That does only backup and restore the partition configuration, without having the file systems restored on the corresponding partitions.

File does output many file system details

# file -sL /dev/sda?
/dev/sda1: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "mkfs.fat", sectors/cluster 8, Media descriptor 0xf8, sectors/track 32, heads 64, hidden sectors 8192, sectors 2097152 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 2048, reserved 0x1, serial number 0x7181b420, unlabeled
/dev/sda2: BTRFS Filesystem label "root", sectorsize 4096, nodesize 16384, leafsize 16384, UUID=b81e9d42-c0a2-4a1e-8197-f6775419f654, 3018244096/20971520000 bytes used, 1 devices
/dev/sda3: BTRFS Filesystem label "home", sectorsize 4096, nodesize 16384, leafsize 16384, UUID=2cf4e529-b242-4913-b283-fd18df73316a, 194707456/9965666304 bytes used, 1 devices

There is potential for a backup of the file -sL output, still missing how to restore this part.

Online backup

We need an online (not having to take the system down to make a backup) "clone" command that does not backup the folder and files themselves. In other words all the drive configuration before files and folders can be restored (with a different tool).


Which command(s) do(es) take care of drive disaster recovery before files and folders?

Note: A one-liner is rewarded as a better answer over having to enter multiple commands.

2 Answers 2


Considering only the GPT partition table you should bet a sensible backup with

export DISK=/dev/sda
echo -e "b\n/tmp/gpt-backup-"${DISK##*/}"\nq\n" | gdisk $DISK

But this backup is in binary format.

For my purposes I always prefer a simple gdisk -l /dev/sda. Unless you need to restore to exactly the same device a textual backup is the better choice, as you need to adjust anyway.

In my personal experience I always needed to restore the contents, but the filesystem type itself is usually irrelevant. You can restore from from e.g. a rsync based backup as long as the target mount point fits the data you want to restore and offers the same features as before (ACLs, extended attributes, hardlinks).

In general the guideline is to backup the relevant data, not the precise layout on disk. This keeps the process simple, easy to verify and independent of specifics not needed in praxis.

  • I see purpose for having a textual output, especially when the output is a script itself. Then the one-line command to restore is to run that script to re-create the partitions and file systems, optionally after some adaptations to the script.
    – Pro Backup
    Commented Feb 20, 2017 at 18:17
  • A simpler version of the backup command above is sgdisk -b ${DISK##*/} $DISK. Commented Feb 20, 2017 at 19:09

The partition table was already covered in another answer.

For disks larger than about 128 GiB (or exactly 2^28 blocks) on (S)ATA and about 8 GiB on SCSI, the old C/H/S style disk geometry is obsolete and irrelevant: the only thing the disk really cares about is the LBA block number. The actual physical geometry on the disk is more complicated than C/H/S: for example, to achieve the necessary storage density, the outer tracks will have more sectors than inner tracks.

Unless you use some very old filesystem type that attempts geometry-based performance optimizations, the disk geometry should have no impact to filesystem contents at all.

Normally I would understand "backing up a filesystem" to mean backing up the files and directories within them. However, you've already done that, and you're looking at backing up filesystem configuration settings and other filesystem-level metadata. This is unfortunately filesystem-type-specific, so there cannot be one command for all filesystems. Sometimes some of those things cannot be changed after the filesystem has been created, so you should think in terms of recreating rather than restoring the configuration of the filesystem before restoring its files and directories.

The output of commands lsblk -f or blkid will tell you the filesystem labels, UUIDs (or "volume serial numbers" as VFAT filesystem ID is not a real UUID). You may wish to record those and explicitly specify them when re-creating the filesystems in a disaster recovery context.

So, the ultimate answer would be: record the commands used to create the filesystems, and re-use the same commands (possibly modified to account for on-line capacity extensions etc.) to re-create them in a recovery scenario. If you have a standardized/automated procedure for deploying new systems, perhaps you can re-use (parts of) that in disaster recovery too?

But since you are using BTRFS, you should know that having multiple mounted filesystems with the same UUID can be dangerous, as the BTRFS driver can assume that they're just multiple paths to access the same filesystem content, and may corrupt the contents as a result. Some protection against this has been added in recent years I think, but I would not assume it's perfect yet. Any procedure that creates (the appearance of) on-disk copies of BTRFS filesystems must make sure that the UUID of the copy is replaced with an unique one before any attempt is made to mount the the copy in the same system that uses the original. This includes not only disk image backups, but also SAN-based filesystem snapshots.

Any snapshots created within BTRFS itself are fine; the filesystem knows about them by definition. The problem arises when an apparent clone is created by means external to BTRFS: splitting a RAID1 set, cloning a disk, or telling a SAN storage system to snapshot a particular LUN and present the snapshot as a new LUN can be risky unless there is a clear procedure in place to change the filesystem UUID in the new snapshot/copy before actually mounting it.

At work, we have a customer that uses SAN-level snapshot and clone procedures extensively: they might make a clone of a production filesystem for testing an application update, then present the clone to the production system once it's been tested and found good. It was just a matter of time before they had two filesystems that had originated as a cloned pair (but had had very different lives since then) presented to the same host. Then they started to get various kinds of "duplicate UUID" errors and I got involved to fix it. Once the appropriate UUIDs were changed to make the UUIDs unique again, all was well. And then we went through their procedures and added in the missing steps to change the UUIDs after any step that clones a disk, just in case both halves of the cloned pair will later be presented to the same system.

Fortunately they weren't using BTRFS... but they did use LVM, which has surprisingly strong protections against things like this. Whenever you get multiple LVM PVs with the same UUID, LVM tools complain loudly and essentially force you to figure out what is going on and fix it before doing anything else. If new LVM PVs are hot-plugged in, LVM will only enable them automatically if there is no ambiguity at all.

(LVM expects that any multipathing should be already handled by device-mapper-multipath or similar before LVM gets to see the disks. Like ZFS, BTRFS seems to integrate LVM-like functionality too.)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .