Because these are RAID boxes I think I would rather do the partitoning manually and copy over the network. The main problem with this is time, because it's very boring at the colo ;). Also if I make several partitions on the destination and mount them (/usr /var /home etc.) will rsync or cp have a problem with doing it all at one shot, or am I better off doing each partition separately On Mon, 8 Aug 2005 22:17:28 -0700 David Thomas <[EMAIL PROTECTED]> wrote:
> I'm with Carl on this. Particularly if you're on a Red Hat-distributed > kernel (and it's associated modules), you should have very little > trouble. > > Are the disks the same size too, or are the new ones a tiny bit larger? > If you want them to be truly identical, by far the easiest thing is to > follow this procedure: > > Mount both hard drives on the same system. Boot from a live CD (is > that what Knoppix does? I dunno, I know Gentoo will work like a charm). > > Don't mount either disk. Then run: > dd if=[src disk] of=[dest disk] bs=1024 > ex: > dd if=/dev/hda of=/dev/hdb bs=1024 > > This will copy every byte of data on the src to the dest. Don't think > you even need to set the active / bootable flag on the destination boot > partition since MBR and all are the same. > > In this scenarion, _EVERYTHING_ is mirrored, even inode access > timestamps are preserved, this can be useful for forensics. > > The only limitation is that the partitions will not match the natural > cylinder boundary. If you're highly dependent on disk performance and > the original disk is carefully laid out according to disk zones and > their application (nobody I know does this), you might notice. > > Lots of other approaches, lemme know if you want me to elaborate, you > might even get when they're root mounted. : > * Create your existing partition sizes using fdisk and use software > mirroring to make a duplicate, then break the mirror. Not sure if > you want to do this if you got an old linux. This is handy if you > want to ultimately end up with mirrored disks, also the more disks > you need to copy, the duplication time shrinks exponentially. > * The traditional thing to do is to mount everything then 'cp -ax' or > 'rsync -av'. > > On Mon, Aug 08, 2005 at 09:05:56PM -0700, Carl Lowenstein ([EMAIL PROTECTED]) > wrote: > Subject: Re: cloning servers > Message ID: <[EMAIL PROTECTED]> > > > On 8/8/05, Todd Walton <[EMAIL PROTECTED]> wrote: > > > On 8/8/05, Dovber Shapiro <[EMAIL PROTECTED]> wrote: > > > > I have a few RedHat servers that I want to clone to new machines. > > > > > > Are they identical machines? Does each have the same exact hardware? > > > The installed OS assumes certain hardware, and if you transplant it to > > > a new machine with different hardware, it may go schizo. I'm not sure > > > how well udev/kudzu would handle this. > > > > I think you will find that Linux is much more tolerant of hardware > > differences than some other unmentionable x86-biased OS's. I have > > transplanted a disk from Pentium II to AMD K6-3 with no trouble, > > vintage RedHat 7.2. Also more recently from the same K6-3 to Athlon > > with no trouble, vintage Fedora 3. Have not tried K6-3 to Pentium 4. > > > > Much of the hardware discovery process is done at boot time, rather > > than being built in when the software is first installed. > > > > carl > > -- > > carl lowenstein marine physical lab u.c. san diego > > [EMAIL PROTECTED] > > > > > > -- > > [email protected] > > http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list > > > -- > [email protected] > http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
