I'll second the recommendation of Mondo Rescue. I used to use it to recover Linux systems to our D/R site for tests before we had a hot-site. It worked very well!
Kevin From: [email protected] [mailto:[email protected]] On Behalf Of Stephen Sanderlin Sent: Monday, August 03, 2009 10:00 AM To: [email protected] Subject: [rhelv5-list] Re: rhelv5-list Digest, Vol 30, Issue 2 I've had good results doing migrations using a utility called Mondo Rescue - http://www.mondorescue.org/ . I usually make an iso on a local drive, then scp it over to a workstation where I can burn a DVD, but you have many options - CD's, DVD, tape, nfs, SMB... It's especially good at restoring to similar or identical hardware, but in a pinch I've taken an image from an HP DL380 and restored it to a blade. It may balk when partitioning the new drive, but it gives you access to a command line so that you can manually partition drives, fix DM-Multipath issues and such. Another advantage is that you can retain the media for future restoration or take and restore an image of a system at any point in time. We use Cristie's CBMR/TBMR for bare metal restore of our production systems, but I use Mondo a lot in our lab environment. We have mondo images of SUSE 9 /10, RHEL 4.6 / 5.3 that we can pop onto one of our a servers in about 10 minutes for whatever the next project is going to be. Regards, Steve Sanderlin Message: 1 Date: Mon, 3 Aug 2009 09:03:55 -0600 From: Scott Robertson <[email protected]> Subject: Re: [rhelv5-list] OT: migrating RHEL hosts To: "Red Hat Enterprise Linux 5 (Tikanga) discussion mailing-list" <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset="iso-8859-1" Copying the bits over the network seems to work. I have copied the bits remotely to and from a disk image, rather than from the actual device on the original server, but I don't see why copying directly from one host to another would be a problem. We use the same size SAN presentations on both sides. It would probably be convenient to run a Fedora live CD on both the server being copied to and from, so the disks aren't mounted on either side. Once you get the network set up on both sides, you can run a command like the following on the new server: $ ssh u...@original_host dd if=/dev/sda | dd of=/dev/sda I've not had much success lately trying to use the multipathed devices from the live CDs, but I've not had a problem copying to just on of the paths (e.g. /dev/sda). This will replace the partition table and everything on your new drive, and replace it with the exact image that was on your old server. You might have trouble booting the new server because the multipath uuid seems to get placed in the init script in the initrd. Since the multipath uuid will likely be different on the new server than it was on the old, you may have to unpack your initrd, edit the init script (I would just have it run multipath with no uuid arguments), and package it back up. You might want to delete the /var/lib/multipath/bindings file in both the initrd and in the real var filesystem as well. If you try this approach and run into any problems, let me know what you find. Good Luck! Scott On Fri, Jul 31, 2009 at 9:50 PM, Vanco Backup <[email protected]>wrote: > I was hoping to get some input on methods best suited to migrate a > series of RHEL(5U3) hosts. > > The environment is straight-forward - Sites A and B are both home to > IBM Blades and an IBM SAN. The Blades are the same, but the SANs > differ slightly (Site B being newer) > > The Blades boot from SAN - no local disk. > > There is a 1Gb IP link between them. I assume it's routed. > > > I've thought about trying to make a Live CD for either site that has > DRBD installed (via CentOS packages) and using the SAN LUN as the > device to be replicated. > > I've thought about trying to use cobbler to basically bare metal > restore the remote site. > > > Has anyone done anything similar? Obviously, looking for the easiest way > out :) > > TIA > Don > > _______________________________________________ > rhelv5-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/rhelv5-list >
_______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
