rsync, dd and then add to RAID 1, could cause database corrupted?

Question

Firstly I have a HDD which has been setup as RAID, type Volume, not RAID 0 or RAID 1 ... and I wanna add one more HDD to setup a RAID 1 array. These bellow steps are what I've done.

• Detach from Server and dd whole disk from the old HDD to the new one: ``dd if=/dev/sda of=/dev/sdb conv=noerror,sync bs=2048`

• Reseat the old HDD back to Server to use for one day. Thur, there is something has been changed in data on this HDD.

• Then, I detach the old HDD from Server one more time. And rsync -aruv from the old HDD to new one. Not dd this time: rsync -aruv /data/ /data-2/

• Attack both the two HDD to Server and setup new RAID 1 array.

At this time, every thing on the (both those) disk (RAID 1) has been erased (As noticed when setup new RAID array). Just likely, because I think the Partition Table is the only thing has been erased.

Some infor:

• My Server is a System X 3400 which is using ServeRAID 8-i Controller

• Installed Windows Server 2008 R and running MSSQL

• This (these) disk store(s) the database for MSSQL. A data volum/partition on Server

• FS is NTFS.

• I dont wanna use a third HDD to backup data from the old HDD and then copy back after setup RAID array and re-create new Partition Table on the 1st (old) and 2nd (newer) HDD. That is why I had dd the 1st to 2nd, rsync data one these disk because there is something has been changed after a day of using the old HDD, and recovery the Partition Table on this (these) (pair) disk(s) when completed setup new RAID 1 array. I mean the new RAID array (contains two these disk). I'm too lazy!

• ReBoot-up the Server for last time. Everything seems working fine. Whoa, I have not to re-create new Partition Table and copy data back from the third HDD (if there is). No more re-check, I go to bed.

But:

At next morning, MSSQL client popped up a diaglog error with msg: ... cannot connect to the default database... And this also is what I got in MSSQL log.

Re-check data, one of MSSQL database files is 0kB. OMG. This is the largest file and had been rsync succeeded before.

The problem:

• MSSQL database file is at zero size. I don't know why.

Questions:

• The way that I did do, and those steps that I've done could cause data corruprted? And it should not be the way to complete tasks like mine?

• Is there any thing can make the database file be a zero size file, MSSQL behaviors or whatever?

I'm completely new on Server-side.

Every help is welcom! Thank you!

Answer 1

TO be honest - I think You did it completely wrong.

When You create a RAID it needs some space to allocate metadata describing what kind of RAID sits on that disk. The disk is initialized by the controller when it becomes a raid member/spare disk.

it should be something like this:
if the controller allows it You could create a degraded mirror with one drive missing:
1. initialize the new drive and create RAID1 array in controller bios with one drive missing.
2. stop all disk activities Rsync: old disk -> new disk
3. unmount old disk, mount the new array in the place where the old disk was before.
4. verify that everything works fine.
5. go to controller bios and initialize old disk and add is as spare. raid should rebuild.

If the controller bios does not allow to create degraded raid array then the most secure would be to dump all data to another disk/server and then create the raid array.

what could go wrong in Your procedure:
- doing that kind of risky operation without backup is a bad choice.
- did You stop all disk activities before rsync? this is why the file may be zero lenght because it was locked by the database engine
- You must check in Your controller documentation that conversion from regular drive to a array member is possible. I myself always threat making a disk an array member like a format.
- DD one disk to another is not a good idea here. You replicate everything even partitions GUIDs. It will maybe be a good choice to replicate a broken hdd and replace it.