You are not logged in.
I currently run a server that contains 4 hard drives, where two are 2 TB and two are 3TB (and were bought together). These drives are encrypted and merged into a 10TB LVM single-partition data storage and backup drive.
Here is my current setup: All four drives are encrypted individually and together are joined into one volume group that allocates all its memory to a single parition which then stores all my data. The problem with the current setup is, that, in case of a hardware failure, all my data will be lost. I am currently considering to fix this problem by building a RAID5 but before I even go ahead and spend money on this, I'd like to hear from someone who has RAID experience if my approach is sane or if I should take another way.
Here's what I'd attempt: I want to buy two more drives, one 2TB and one 3TB and then join each drive with the other two of the same size. Then I would have two RAID5 drives, one consisting of 3 2TB drives and one consisting of 3 3TB drives. These drives will then be encrypted and joined into an LVM. So currently, I plan this order: RAID -> LUKS -> LVM. Does this seem to be the correct order? (Note: I want LVM after encryption to be able to add more drives if needed).
The next thing would then be the question if RAID5 is the right choice. From what I read I understand that RAID5 would use any number of drives for storage extension and a single drive as a fallback storing the combined parity of all drives (in reality the parities seem to be shared between the drives).
So what are your thoughts on this approach? I have read a few articles and it seems that this is a good way.
Thanks in advance.
P.S.: I plan to make the migration a two-step process where I use the drives that are not being upgraded to hold the data of the other ones (using pvmove), additionally using some external storage. Since I can split it up this way, I should be able to accomplish the whole thing without data loss (or the risk thereof).
Last edited by javex (2014-01-11 03:55:18)
Offline