Good morning all, in today’s episode of “What I learned during work hours”…
I was playing around with wxHexEditor and realised that if something catastrophic happened, I would really struggle with any data recovery if I lost the inode tables for any drive.
A quick duckle pointed me to e2image, which says in the man:
It is a very good idea to create image files for all file systems on a system and save the partition layout (which can be generated using the fdisk -l command) at regular intervals — at boot time, and/or every week or so.
I couldn’t find any prebuilt solutions for this online, so I wrote a systemd service and timer to do this for me. I save the fdisk to a text file, run e2image on a couple drives, and compress it all together in a dated 7z that can get uploaded via rsync or Mega or Dropbox etc.
The metadata image from a 500gb drive is 8gb, but compresses down to 40mb. Backup takes a couple minutes.
Unfortunately this does not work with my raid drives, but they are RAID1 so already resilient.
Apparently I was being a derp somehow. …Anyways,
My RAID drives are 16TB, e2image of this is 125gb, and 7z’d it comes down to just 63mb.
I’ll post the service, timer, and backup script in a comment, let me know if you can spot anywhere for improvements!
How important this is will depend on your file system of choice.
testdiskcan 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 -Sif 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.ext4will 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
ddand 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!).
Great tips, thanks!
I’m using ext4 across everything I think.
Can you enable superblocks after you’ve already formatted the drive?
Fdisk saves the offsets so keeping a record of that at least sounds like a good idea.
There’s a good chance you have plenty of backup superblocks already.
Try running
sudo dumpe2fs /dev/your-partition-hereor, lacking thatmke2fs -n /dev/your-partition-here(make sure to specify -n so you don’t overwrite your filesystem) and look for backup superblock offsets in the output. There’s a good chance you have a whole bunch of them spread throughout the disk.This is why I love having luks covering my entire system disk. If I want to upgrade the system with a new drive or move the drive to a different pc or sell it or dispose of it I just dd the first couple of gigs to obliterate the luks header.
It’s obviously essential to have a backup strategy, of course, but full disk encryption is the only way to go for me.