[SATLUG] RAID5 Recovery - Reassembly questions

Don Wright satlug at sbcglobal.net
Wed Aug 26 13:28:51 CDT 2009

On Wed, 26 Aug 2009 09:36:36 -0700 (PDT), David Labens
<adlabens at swbell.net> wrote:

>3. I can now install a PCI SATA2 controller card ... and the 1 tb drive 
>that I bought for my 1st backup, and can attempt to copy the datasets 
>from the drives and force it to reassemble from the single 1 tb HDD 
>rather than from the individual drives.  
>I believe Option 3 is the best - meaning I'd not lose the original 
>datasets if something assembles wrong.  However, I am unsure how to 
>proceed with this method.  

The backup/safety copy is a good thought. Rebuilding from the new 1TB
drive, however, is less than optimal. (But it shows good devious
computer thinking.) Unless you want to torture-test your new drive, this
would take much longer and strain the mechanism as it seeks to four
widespread places on the drive for each block of data. (Remember head
movement [seeking] is the slowest thing a drive does in normal
operation, and produces much heat.)

>What commands would I issue to make the system copy from the individual physical HDDs to the single HDD with what would be virtual drives?

Create three or four partitions on the 1TB ("Big Drive") and use dd (or
ddrescue) to copy the RAID partitions from the two "good" drives, the
ddrescue data from the new RAID drive, and optionally the data from the
low-event-count drive, into their own partitions on the Big Drive.

The partitions need to be at least as big as the original data. Some
(most?) partition tools will round the requested space up to a magic
value. That, combined with marketing numbers for drive size means you
might not be able to fit all four 250GB partitions on a single 1TB

The Big Drive partitions should be created as type DA (Non-FS data)
instead of the usual 83 (Linux) or FD (RAID autodetect). We're trying to
hide these from mdadm and the RAID kernel modules. Type 83 is OK if your
preferred partitioner doesn't have DA as a choice.

When finished, disconnect the Big Drive data cable (preferably with
power off) so these copies aren't accidentally seen by mdadm and confuse
things. Then proceed with option 2 (modified) as mentioned below. We'll
cover that in detail when you're ready.

>Or, am I trying too hard and doing either Option 1 or Option 2 be the right way to go?

If you didn't have the third choice we would use Option 2 (and omit the
low-event-count drive from the mdadm --assemble command.) Extra safety
is seldom a bad thing.  --Don

Price slightly higher west of the Rockies.

More information about the SATLUG mailing list