Emmanuel Noobadmin
2012-Jun-08 16:33 UTC
[CentOS] Best way to duplicate a live Centos 5 server?
I've got a CentOS 5 server that I want to migrate over into a virtualized instance. The problem is I need to minimize downtime so was trying to figure out a way to "live" clone the original. Initially, I thought I could do this via exporting an iSCSI target from the virtual host, create a MD raid 1 array on the C5 server, wait for it to sync, then shutdown the physical server and switch to the virtual one. But after getting iSCSI working... I realize I could not create a md device on a mounted disk. Unfortunately this old C5 wasn't setup with md raid 1 originally so I can't just add a the iSCSI target as an additional member for a triplicate. So I remembered DRBD was supposed to be used for replication. But after getting things set up, running the drbd-admin create-md command gave me this scary warning it will destroy data on the disk. Apparently because drbd writes meta data to the drive. So that appears to be a no go too. Am I missing something glaringly obvious here, or is the only way I'm going be able to migrate is to shutdown the C5 server for a few hours while duping the old drives? Would greatly appreciate any pointers how best to do this.
on 6/8/2012 9:33 AM Emmanuel Noobadmin spake the following:> I've got a CentOS 5 server that I want to migrate over into a > virtualized instance. > The problem is I need to minimize downtime so was trying to figure out > a way to "live" clone the original. > > Initially, I thought I could do this via exporting an iSCSI target > from the virtual host, create a MD raid 1 array on the C5 server, wait > for it to sync, then shutdown the physical server and switch to the > virtual one. > > But after getting iSCSI working... I realize I could not create a md > device on a mounted disk. Unfortunately this old C5 wasn't setup with > md raid 1 originally so I can't just add a the iSCSI target as an > additional member for a triplicate. > > So I remembered DRBD was supposed to be used for replication. > > But after getting things set up, running the drbd-admin create-md > command gave me this scary warning it will destroy data on the disk. > Apparently because drbd writes meta data to the drive. So that appears > to be a no go too. > > Am I missing something glaringly obvious here, or is the only way I'm > going be able to migrate is to shutdown the C5 server for a few hours > while duping the old drives? Would greatly appreciate any pointers how > best to do this.You could always rsync the old server to the new one... a few runs will get 99% of the files, and a quick run after the shutdown can get the rest... Have a tar file ready of the needed config changes ready and untar it and start up the new system...
On 08/06/2012 17:33, Emmanuel Noobadmin wrote:> I've got a CentOS 5 server that I want to migrate over into a > virtualized instance. > The problem is I need to minimize downtime so was trying to figure out > a way to "live" clone the original. > > Initially, I thought I could do this via exporting an iSCSI target > from the virtual host, create a MD raid 1 array on the C5 server, wait > for it to sync, then shutdown the physical server and switch to the > virtual one. > > But after getting iSCSI working... I realize I could not create a md > device on a mounted disk. Unfortunately this old C5 wasn't setup with > md raid 1 originally so I can't just add a the iSCSI target as an > additional member for a triplicate. > > So I remembered DRBD was supposed to be used for replication. > > But after getting things set up, running the drbd-admin create-md > command gave me this scary warning it will destroy data on the disk. > Apparently because drbd writes meta data to the drive. So that appears > to be a no go too. > > Am I missing something glaringly obvious here, or is the only way I'm > going be able to migrate is to shutdown the C5 server for a few hours > while duping the old drives? Would greatly appreciate any pointers how > best to do this. >You don't say what virtualisation platform you are using is, but if it's VMware, then you can use VMware converter to do the migration. This can, if you want, clone the physical computer into VMware, shut down the physical computer and bring up the new virtual instance. All whilst the physical remained up. I've used it for a few Linux boxes, where I've wanted a quick dev version of an existing server and its been fine. I guess, you could try pulling it into an ESXi host, and then exporting that in a format whatever virtualisation program it is you use supports... Regards, Tris ************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmaster at bgfl.org The views expressed within this email are those of the individual, and not necessarily those of the organisation *************************************************************
From: Les Mikesell <lesmikesell at gmail.com> Subject: Re: [CentOS] Best way to duplicate a live Centos 5 server? To: CentOS mailing list <centos at centos.org> On Fri, Jun 8, 2012 at 12:04 PM, Scott Silva <ssilva at sgvwater.com> wrote:>> Am I missing something glaringly obvious here, or is the only way I'm >> going be able to migrate is to shutdown the C5 server for a few hours >> while duping the old drives? Would greatly appreciate any pointers how >> best to do this. > You could always rsync the old server to the new one... a few runs will get > 99% of the files, and a quick run after the shutdown can get the rest... Have > a tar file ready of the needed config changes ready and untar it and start up > the new system...An interesting variation on this is to use 'ReaR' to back up and restore the machine, essentially cloning it but give the copy a different IP address as you bring it up. Then when the clone is close to ready to take over, shut down your apps for the time it takes a final rsync to fix up the differences (in the data areas only - avoid /etc/, (etc.), then switch the IP. ReaR is in active development now and is very usable. It is a set of shell scripts designed to run live backups that are capable of restoring to bare metal. It makes a new boot iso with tools from the running system to reconstruct the filesystem (including lvm/raid, etc.) and restore on top of that. Several backup methods are supported but tar to an nfs location is probably the easiest to set up. With a small amount of extra work you can tweak the filesystem layout, etc. if you don't want an exact clone. With hardware differences you might need to tweak modules and build a new initrd, too. ReaR is packaged in EPEL as rear. ReaR has suddenly become very interesting to me, probably explaining why it utterly fails to work properly (for me).I'm using 1.13 to pull a USB-based recovery image, but there's an error in the backup/NETFS/default/50_make_backup.sh script that doesn't mount the USB device after the mkrecovery step, so subsequent tar fails on write to the non-existent mountpoint. I fixed that, but on recovery it fails to mount the necessary directories on the restore drive as well, so "rear recover" quickly bombs out. Is anyone having any success actually using ReaR on CentOS 6.x? - csawyer
Subject: Re: [CentOS] Best way to duplicate a live Centos 5 server? To: CentOS mailing list <centos at centos.org> On Mon, Jun 18, 2012 at 11:21 AM, Cal Sawyer <cal-s at blue-bolt.com> wrote:>> > >> > ReaR has suddenly become very interesting to me, probably explaining why >> > it utterly fails to work properly (for me).I'm using 1.13 to pull a >> > USB-based recovery image, but there's an error in the >> > backup/NETFS/default/50_make_backup.sh script that doesn't mount the USB >> > device after the mkrecovery step, so subsequent tar fails on write to >> > the non-existent mountpoint. I fixed that, but on recovery it fails to >> > mount the necessary directories on the restore drive as well, so "rear >> > recover" quickly bombs out. Is anyone having any success actually using >> > ReaR on CentOS 6.x? - csawyer > It intentionally doesn't deal with drives the kernel has marked as > removable. I had trouble with that with the main drives on a SAS > hotswap backplane in an earlier version but I think that is fixed now. > > I'd recommend asking how to override this on the ReaR mail list. > While the code seems usable (and yes, I have succeeded in using it on > Centos 6x.), the documentation either doesn't exist yet or is very out > of date. But, the authors are very responsive and it would be good > to let them know about any bugs or usability problems. The mail list > is still at sourceforge although the code has been moved to github and > there is talk of moving the list elsewhere. > > -- Les Mikesell lesmikesell at gmail.comReaR hasn't posed any insurmountable problems with USB removable media but i can see SATA/SAS needing some massaging in the device detection dep't. Yes, i've gotten myself on the ReaR mailing list now. You're right - documentation is pretty dire. Guess i'm not alone in hating doing it. USB backup is broken due to the order in which path variables get set - sure is lot of fun trawling through the scripts to find out what gets set when. Hope the ReaR maintainers are interested in this and haven't gotten themselves mired in tape archive integration - i would have thought USB backup was the winner in terms of getting broad acceptance as a bare-metal DR solution. However, when it works - wow. Just restored an HP dl360 w/HWRAID to a Presario desktop machine and it lives! No network, but that's small beans compared to the larger win. - csawyer
On Wed, Jul 11, 2012 at 9:06 AM, Steve Clark <sclark at netwolves.com> wrote:> I think it is more the fact the Oracle seems to be two faced in their > dealings with foss as > opposed to IBM.Since the Sun acquisition, and despite the LO-OpenOffice spat (which btw the 'community' forkers destroyed the future of the former Sun StarOffice, in the name of freedom, of course), most of the former Sun FOSS projects -at least the mainstream ones- have been doing well: Virtualbox, GPL Java SE (OpenJDK), NetBeans, Glassfish J2EE server, MySQL, even while Oracle had other proprietary products in its arsenal that would overlap (ie JDeveloper freeware overlaped with NetBeans, yet Oracle continued with Netbeans development nevertheless, with v7.2 just released and extended for better PHP/C++ support). Having said that, I wouldn't touch Oracle's propietary offerings even with the proverbial 20ft pole -mostly because I cannot afford any and there are worthy alternatives which are totally free- but Sun's FOSS projects I care about are alive and doing well (even OO under Apache's). I recorded some of the doom and gloom predictions (ie "MySQL will die") vs the reality on a news story last year http://news.techeye.net/software/despite-anti-oracle-hysteria-firm-is-an-open-source-powerhouse After that they even complied with their promise of starting to open source JavaFX 2.0 http://openjdk.java.net/projects/openjfx/ OK, now let's concentrate on CentOS... :) FC -- During times of Universal Deceit, telling the truth becomes a revolutionary act - George Orwell