I moved away from software RAID due to all the hassle it brings. After an OS reinstall, I am left with only one drive. I ordered a hardware RAID controller today, and when the controller arrives, I'd like to plug in the identical drives into the RAID controller and set up RAID 1 WITHOUT losing any data or needing to reinstall the OS (Debian Jessie x86_64).

Output of lsblk:

sda                 8:0    0 931.5G  0 disk
├─sda1              8:1    0   953M  0 part /boot
├─sda2              8:2    0  29.8G  0 part [SWAP]
└─sda3              8:3    0 900.8G  0 part
  ├─vgmain-lvroot 254:0    0 621.4G  0 lvm  /
  ├─vgmain-lvmail 254:1    0  93.1G  0 lvm  /var/vmail
  ├─vgmain-lvhome 254:2    0  93.1G  0 lvm  /home
  ├─vgmain-lvtmp  254:3    0  18.6G  0 lvm  /tmp
  └─vgmain-lvvar  254:4    0  74.5G  0 lvm  /var
sdb                 8:16   0 931.5G  0 disk

Can I do this somehow by dding the existing data to the clean drive while having it plugged into the RAID controller and set up as RAID 1? To clarify, let's say sda is the drive with my data, sdb is the drive which is not in use.

  • Plug sda into the mobo sata controller
  • Plug sdb into the RAID controller
  • Define sdb as RAID 1 drive
  • Boot from liveCD and dd contents of sda → sdb
  • Plug sda into RAID controller, define as RAID1
  • RAID controller syncs the drives, (copies over sdb to sda) (?)
  • Boot without problems?

Will dd copy the drive in a way that mbr/partitions/etc. are preserved? Am I thinking in a completely stupid way of doing this?

I contacted the RAID controller manufacturer and asked if it has some kind of utility to convert a drive into 2 drives in RAID1, but they said no. If it's relevant in any way, the specific controller is a HighPoint RocketRAID 620 PCI-Express 2.0 x1 SATA III RAID card.

  • 3
    If you think software raid is a hassle, just wait until you get to experience the "joy" of hardware raid. – cas Jun 14 '16 at 8:08
  • @cas what do you mean? A HW RAID cannot be broken by the OS in a way a software RAID can easily be misconfigured, and upon reboot the system will fail to load (forcing me to drive 80km and fixing the server on spot instead of ssh'ing as I always do). – Axel Latvala Jun 14 '16 at 11:22
  • 1
    Yes, it can (and when it does, it'll be much harder to fix). It can also break in other fun and exciting ways - you'll absolutely love discovering that when your HW RAID controller dies, you can't just replace it with any other controller, often not even one from the same manufacturer....and the model you need hasn't been made for years. There's only one good reason to use HW RAID - and that's so you can have non-volatile write-cache for RAID5 or RAID6. If R5/R6 is not a requirement, HW RAID is a waste of money. And if you need the capacity of R5/R6, you're still better off with ZFS. – cas Jun 14 '16 at 14:40
  • IMO, the simplest and best thing for you to do is partition sbd exactly the same as sda, make sdb1 a degraded RAID1 (with either LVM or mdadm), rsync /boot to it, unmount /boot, add sda1 to the RAID1, and remount it as /boot. Don't forget to run update-grub. and grub-install /dev/sdb to install the grub boot-loader in the 2nd drive's MBR. sdb2 could be a second swap partition (don't bother with RAID0 for swap, linux already stripes swap devices that have the same priority). And add sdb3 as a mirror (i.e. RAID1) to the existing LVM volume group (currently consisting of only sda3). – cas Jun 14 '16 at 14:50

Your procedure is correct. Your terminology could use small detail work though.

You want to declare the second,new disk to be a member of a new degraded RAID1 array.

Then boot with a liveCD, dd the Data over, and then declare the first,older disk to be a mirror of the above array.

Depending on how exactly GRUB locates the RootFS, you may need to edit your GRUB config, or run update-grub.

One thing to check: The RAID-Header may be on-disk, so maybe your RAID will be slightly smaller than the underlying physical drives

  • Don't use dd for cloning disks, that's one of the slowest, least flexible way of doing it (for example, it will waste time copying unused disk space). Use Clonezilla. or DIY with rsync. – cas Jun 14 '16 at 8:06
  • 1
    @cas: Clonezilla uses partimage, which in turn needs to understand each specific filesystem block device layout. And rsync only copies filesystem content as files. Depending on your use-case, one/both of these may make you have to use dd. – Alex Stragies Jun 14 '16 at 8:31
  • Both of those facts are features not problems, and are exactly why I recommended using clonezilla or rsync. bit-for-bit copies of the OS disk may be required for primitive OSes like Windows, but not for Linux. Linux does not care where on the disk any file is, so a file copy will work without a problem. In fact, a file copy will automatically and completely defrag the files as it copies them to the target fs. – cas Jun 14 '16 at 8:34
  • @cas : You and I, and many others here, know that. But a new user might not. That new user will then wonder, why part-image wont efficiently transfer only the used space of -say- an encrypted blockdevice, or why the rsync-copy of a Windows-FS fails to boot. So dd in this case is the slower, but "safer" (=less to explain/understand) method – Alex Stragies Jun 14 '16 at 8:37
  • The OP was asking about linux filesystems, there was no mention of windows. a novice user is unlikely to even notice the issue with an encrypted device, and an experienced user will understand why. There's also no good reason to point novices at tools like dd (which are easy to make data-destroying mistakes with) rather than superior, safer tools like Clonezilla. or rsync (or cp -af or tar ... | tar ...) – cas Jun 14 '16 at 8:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.