How important this is will depend on your file system of choice. testdisk can recover many broken partition tables, and most file systems keep multiple copies of the necessary tables on disk just in case something goes wrong.

There’s a good chance you can recover an ext4 partition with mkfs.ext4 -S if you know the offset on disk (and didn’t specify any alternative options). It’ll recreate the file system structure on disk but it’ll leave most data intact. I’ve had to resort to doing this and it took a little finetuning of the options (make backups of the drives you recover!), but the data came back as if nothing ever happened.

If you’re afraid of data loss, mkfs.ext4 will allow you to enable up to two backups of the superblock as well, right in the middle of the file system.

Other filesystems like btrfs and NTFS also have backup superblocks of course. Things become more complicated when you start spreading your filesystem across drives (in a non-redundant fashion) but all in all I don’t think taking snapshots of a drive’s structure is that important, as long as you have your normal backup procedures.

Now, your LUKS headers, those you may want to back up! If you fat finger a dd and overwrite the LUKS header, there’s basically no recovering that data. If the system is still running you could dump the key and try to manually reconstruct the header, but if you turn your computer off after clobbering the LUKS header there’s no getting your data back, no matter how many recovery phrases and key files you may have saved!

This can also be used to your advantage, i.e. by storing the LUKS header on a removable drive so that there is no way to decrypt your drive even if someone knows your password (and neither can you if you lose the flash drive!).

Fantastic. I’m following!

The script takes the drives as arguments:

$ pwd
/usr/lib/systemd/system
$ cat drive_backup.service 
[Unit]
Description=backup fdisk + e2image
Wants=drive_backup.timer

[Service]
Type=oneshot
ExecStart=/usr/bin/backup_meta_data.sh /dev/sdc1 /dev/sdb1

[Install]
WantedBy=multi-user.target

Set to run at 3:40am every day, but probably could be once weekly really.

$ cat drive_backup.timer 
[Unit]
Description=timer to run drive backup
Requires=drive_backup.service

[Timer]
Unit=drive_backup.service
OnCalendar=*-*-* 03:40:00

[Install]
WantedBy=timers.target

Should be fairly self-explanatory.

$ cat /usr/bin/backup_meta_data.sh
#!/bin/bash

working_dir=/home/st/drive_recovery/working
backup_dir=/home/st/drive_recovery
backup_date=$(date +%Y%m%d-%H%M)

mkdir -p $working_dir

sudo fdisk -x > $working_dir/$backup_date.fdisk

for var in "$@"
do
	clean=$(echo $var | sed 's;/;-;g')
	sudo e2image $var $working_dir/$backup_date.$clean
done

sudo 7z a $backup_dir/$backup_date.archive $working_dir/"$backup_date"*
sudo rm $working_dir/"$backup_date"*

May I point out that all a RAID1 does is sync the blocks between two drives. It won’t protect against writing something dumb that would mess up the filesystem, it will just dutifully sync it.

You should be able to back up ext data from a filesystem on a RAID array, unless I’m confused about what e2image actually does. Are you trying to use it on the underlying drive devices by any chance? You have to point it at the RAID device on top of them, something like /dev/md1 rather than /dev/sda1.

This sounds like a good extra backup to have but don’t let it lull you into a false sense of security. It may help recover from a very specific kind of mistake but the recovery may be very specific as well. It’s not file backup.

I’m really curious as to why go to all this trouble instead of using a proper file level backup and restore solution.

e2image

There’s a good reason for the 2 in the name.

Today we have ext4, and ZFS of course.