CentOS - Jun 2012 - 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.com
ReaR 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