LinuxQuestions.org - Draft data loss mitigation method for spanned LVM (would like suggestions)

I have an LVM volume that is made up of two 500GB HDDs because I like the ability to add to a volume as it expands. Unfortunately, since there is zero redundancy if a drive fails catastrophic data loss will occur. This stems from the fact that the LVM and LUKS metadata are stored on the original drive in the volume group, and that FS Journals such as ext4 move around as space is used. After having some questions answered on reddit.com/r/linux and some googling, I've drafted a dataloss resistant mitigation method for LVM/ext4 (and LUKS).

You'll need at least 4 seperate storage block devices. I'm using a 256MB SD (lvmsd), a 4GB SD (jrnlsd), and two 500GB HDDs (sda & sdb).

First create your Physical Volumes:

Code:

#pvcreate /dev/lvmsd1

#pvcreate /dev/sda1

#pvcreate /dev/sda2

Then create your volume group:

Code:

#vgcreate array /dev/lvmsd1 -s 4M

#vgextend array /dev/sda1

#vgextend array /dev/sdb1

#lvcreate array /dev/lvmsd1 -l 100%FREE -n storage

#lvextend /dev/array/storage /dev/sda1 -l 100%FREE

#lvextend /dev/array/storage /dev/sdb1 -l 100%FREE

(Optional) Create a LUKS volume on top of LVM

Code:

#vgchange -ay array

#cryptsetup  --verify-passphrase --key-size 256 luksFormat /dev/array/storage

#cryptsetup luksOpen /dev/array/storage luks-storage

\\If you do create a LUKS volume, use /dev/mapper/luks-storage instead of /dev/array/storage for the remaining steps

Next, create an external journal, and filesystem

Code:

#vgchange -ay array

#mkfs.ext4 -O journal_dev /dev/jrnlsd1

#ls -l /dev/disk/by-uuid/

\\Find the symbolic link that points to your external journal device

#mkfs.ext4 /dev/array/storage -L storage -J device=UUID=h3xuu1dt-0y0u-rd3v1c3

Finally, close everything and backup your lvmsd

Code:

(Optional)#cryptsetup luksClose luks-storage

#vgchange -an array

dd if=/dev/lvmsd of=/root/lvmsd.bak bs=512

\\You should do this every time you change the volume group

_____________

I don't make any guarantees to the reliability to this method, and as I said, it's only a draft method and still doesn't replace regular back ups (you do that right?)

The advantage of this method, is that if one of the secondary physical drives fail, the journal is external, so you can mount the volume read-only and backup what you need (Possibly still use the volume until the failed drive is recovered, but I wouldn't recommend it). It also protects against the metadata being lost or corrupted, because you should have a regular backup of the primary physical drive (and maybe even the journal drive) and can quickly make a clone and drop in a replacement.
____________

I still have some questions that would make this method more effective:

What is a decent size for a journal drive? What would be a safe minimum for say a 4TB ext4 volume?

What would be the best way to set ext4 to not store anything in the first 256MB? I know the reserved file space can be changed from 5%, but is that 5% of the originally created file system, or does it increase if the filesystem is extended?

If the first 256MB can be blocked off, what negative effects would be a problem during normal use if the "lock" switch on the SD was turned on? I can tell that the lock would have to be disabled to add LVM PVs, but other than that, what would need to write to it?