On 06/04/2016 04:11 AM, Mark Fletcher wrote:
I assume you've implemented backup, restore, imaging, archiving, etc..
dd'ing the 500 GB onto the second SSD should work.
But, if it were my box:
1. Buy a 16+ GB SSD to use as the i7-920 system drive, install and
connect to motherboard SATA-0 port (dev/sda), and do a fresh install
with MBR and three partitions -- ext4 boot, LUKS random key swap, and
LUKS btrfs root.
2. Install the two 960 GB SSD's. Set up each with GPT partition table,
one large partition, and LUKS. Put RAID1 copy-on-write (COW) file
system on top -- mdadm RAID1 plus btrfs, LVM RAID1 plus btrfs, btrfs
with RAID1 (if supported), or ZFS on Linux (ZOL) mirror.
3. If you choose ZOL, leave space on the system drive, add a fourth
partition with LUKS, and use it for the L2ARC.
4. If you're going to use this as a headless SOHO file server, a USB 3.0
flash drive could work as your system drive. If you do this and also
choose ZOL, it would be best to use another USB 3.0 flash drive for the
L2ARC.
Thanks all for the comments. So I have one vote for fresh install, one vote for copy, and one vote for do something completely different and turn the box into something else because.. RAID. I think.
The box is my main desktop system, and yes it would p*ss me off something chronic if it went down for any length of time, but it wouldn't be critical, no revenue loss etc. So backups are good enough. My critical, revenue-affecting machines are all outside my home. So I don't think I'll bother going RAID at this time. Also if I understand correctly, this option would end up reducing my available space from 1.5TB in HDD land to 1TB (or 960GB) in SSD land, which is also a disadvantage.
The LVM idea is useful, and may allow me to put the extra space on the first disk to good use by potentially combining it with space from the second disk. I will look into that. Could do that even if I were doing a fresh install. Thanks for that idea!
I am then faced with the choice of the "Fresh install to new SSD followed by copy" option or the "cp -a" option. I assume I'd need to have not booted from the main disk in the latter case because if I had, for example, /dev would contain ton of stuff I don't want to / can't copy, ditto /proc etc. In other words it would be harder to separate what is actually on the old disk as opposed to in the Linux file system. Whereas if the disk was mounted somewhere like /mnt copying what is actually on the disk becomes easier.
I think both these options have one potential pitfall, which is file ownership after the copy over of stuff I want to salvage from the outgoing HDD. If I do a fresh install, no guarantee that user IDs will be the same on the new system as I of course don't remember now what order I installed stuff in. My regular user ID created during install will no doubt get the same ID (although even that is not guaranteed as this machine started life as etch, if I remember rightly, then was upgraded to squeeze, then to wheezy, and finally to Jessie). And I don't remember exactly when I installed, for example, mysql in relation to other stuff. So I could have some fun and games copying stuff over from the old disk to the new from that perspective. Any clever ploys to deal with that? I suppose avoid the install and copy from new to old having booted from old is one way, but then how do I copy only what's actually on the disk eg avoid virtual filesystems?
The big advantage of the fresh install though is that the install will take care of grub which is a plus. I could do that manually but would be afraid of effing it up.
Hmmmm, much to ponder. Thanks all for your thoughts.
Mark