Teach me how to backup a layered volume

submitted by
they/them edited

In this economy, I somehow managed to get my hands on a brand new 18TB IronWolf Pro HDD for $500.

I have four 4TB SSDs on top of which I have made a logical volume with lvm, which in turn I encrypted with LUKS. Now, I want to backup everything inside that LUKS container, but I’m a little but unsure of which “layer” to copy or to clone.

  1. Just cp/dd the contents of the LUKS container like I would any other file?
  2. dd the LUKS container itself - in other words, close the container and copy/clone the mapped volume, which is encrypted?
  3. dd the logical LVM volume - in other words, close/"unmap"/whatever the logical volume and dd?
  4. dd the underlying raw disks? Although I don’t see how that would be recoverable/usable/readable on the backup HDD.

The data is not critical. It’s just some Linux ISOs that would be nice to have backed up so that I don’t have to download them again.

Edit: the HDD is to be installed on the same system as the SSDs. The HDD is also going to be encrypted, but without a logical volume, since it has enough space on its own.

Please advise. 😊

2
7

Log in to comment

Hot Top New Old

Biggest factor I can think of is your recovery strategy, if downtime is OK data and simplicity is key I’d honestly take option 1 and copy the files and directories directly to the new drive (with xfs or something on it).

Dd’ing anything else a la option 2 and 3 (LUKS container/LVM LV) will increase the size of your backups, because all empty blocks will be copied exactly as they are (even more so in the encrypted version as they become almost uncompressible).

That being said, its possible to “qemu-img convert” the entire 16TB LVM LV into a Qcow2 file, so you could later clone/attach it if a disked failed with the added benefit of qcow compressing those annoying zeros (but still doesn’t beat the space efficiency of just copying the files cause non-zero but empty blocks probably exist).

I’d avoid option 4 and dd’ing the LVM physical volumes, because it can get a bit annoying dealing with duplicate PV UUID’s. I could only seeing this being a choice if you are handling consistency somehow and want to be able to replace SSD’s without much down time.

All that being said damn I’m jelly, you have as much storage in 5 drives as I do in like 20.

 reply
3
they/them OP

Thank you so much for these insights! Exactly what I was looking for. 😊 The HDD is arriving tomorrow, so your comment was greatly timed too! 🤣

I’ll definitely go with option #1, copying the individual files and directories, using either dd or rsync, for the reason you mentioned (=to avoid cloning unused space). Since this will be my first ever backup, I guess it doesn’t really matter what utility I use, expect for dd having the conv=fsync option, which makes it a bit safer, as data is synced continuously per block (autocorrect wanted to type “per bacon").

Yeah, I got my hands on them 4TB Samsung 870 EVOs when they were still around $350 a piece. Now they cost more than $1000. Freaking data centers…

 reply
3
Insert image