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.

  • 4
    If you think software raid is a hassle, just wait until you get to experience the "joy" of hardware raid.
    – cas
    Jun 14, 2016 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). Jun 14, 2016 at 11:22
  • 2
    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, 2016 at 14:40
  • 1
    Hardware RAID is a very problematic solution. Apart from what @cas has said, you may find that not all controllers are created equal and some of them are really some hard/soft hybrid. There is nothing that prevents you from creating a softraid for all your partitions and install grub on both of the disks. Just avoid using UUIDs for partition references in grub and fstab. This way, if your #1 disk fails, it will boot from the #2 and it will reassemble the soft RAID1 set with just the second disk.
    – Panos
    Jun 14, 2021 at 19:07
  • 1
    @Panos yes, that's exactly how I manage my current servers. RAID1 with LVM on top of them, and LVM is able to scan the disks, I have only logical names in fstab, And grub installed on all RAID1 members. But thanks anyway five years from asking the question :D Jun 15, 2021 at 16:00

1 Answer 1


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, 2016 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. Jun 14, 2016 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, 2016 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 Jun 14, 2016 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, 2016 at 8:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .