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.)