On Mon, Jul 28, 2003 at 12:53:27PM -0700, Bill Moseley wrote: > I need to clone a disk. The source is a 3ware hardware RAID 1 array. > >From Linux it looks like /dev/sda > > $ mount > /dev/sda2 on / type xfs (rw) > proc on /proc type proc (rw) > devpts on /dev/pts type devpts (rw,gid=5,mode=620) > /dev/sda5 on /tmp type xfs (rw) > /dev/sda6 on /usr type xfs (rw) > /dev/sda7 on /var type xfs (rw) > /dev/sda8 on /usr/local type xfs (rw) > /dev/sda9 on /home type xfs (rw) > > The destination is /dev/hda > > Can I build a new bare metal drive on /dev/hda using dd > > dd if=/dev/sda of=/dev/hda > > Will that work with the hardware RAID array? If so will it also copy > the MBR?
Yep. Yep. > The destination drive will NOT be used in a RAID array. Also, the > drives in the RAID array cannot be used outside of the array due to the > meta data written by 3ware card. I take objection to the term "cannot be used": As "harddisk-recovery.com" we'll make them work if neccesary, but that's not really relevant now. > Is there a better way to clone the data on my RAID array for use in a > stand-alone (non-raid) machine? This is the "one command that does the job easily". - Make sure the destination drive is large enough. - It might boot, it might not. - Modify the /etc/fstab and /etc/lilo.conf files before rebooting. - Add device=/dev/hda bios=0x80 to Lilo.conf, mount the hda disk on /mnt and then run lilo -r /mnt (Mount at least the / and /boot partitions! Hmm. you don't have /boot, so "/" would have to do.... ) Note that I'm recommending you run lilo while you're concerned about the MBR. It might work, but running LILO again gives you a bigger chance to get it to work.... I recently cloned a drive this way. Copying over the 80G took quite some time. It would have been faster to just mount both sides and perform an rsync. Note that rsync is a great tool for stuff like this: <partition hda to your liking> mk<???>fs /dev/hda2 mount /dev/hda2 /mnt rsync -vax / /mnt should do the trick for one parttion. Oh, Note that you'd be copying a LIVE partition. A logging filesystem like ext3 or XFS will take care in writing stuff to the drive in the right order. You're screwing that up by just copying over the raw drive. (the OS might write onto some block that you've already passed in your "dd", and THEN write a block that you haven't. So the copied filesystem will have the second write, but not the first. That's bad if that was a required ordering. I've done this lots of times without trouble on an ext2 filesystem, and the resulting fsck never found any trouble. I've done it once on an ext3 filesystem, and DID get into trouble. So be careful: It's obviously better to remount everything readonly before doing this.... mount -n -o remount,ro / mount -n -o remount,ro /tmp mount -n -o remount,ro /var ... Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * I didn't say it was your fault. I said I was going to blame it on you. * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]