Linux host to host migration

Question

I need to migrate my CentOS server onto another with an identical system distribution. I don't know yet how different is hardware the besides amount of memory and GHz (posted separate question about that)

I've been compiling lot's of libraries by hand on my original server, installing them to standard location and did not keep a record :). (there is no one to fire me for this - I only lose time and money here and hopefully - learn something)

Migration will also involve moving user stuff, setting permissions, file ACLs. (here is question on moving user accounts, but there's nothing about facl)

Is there anything in the world that can help me re-create the beast on the new host?

Are there any tools that allow such migrations in a more orderly fashion? (preventive or more active tools)

Obviosuly I'm no sysadmin - but I hope to learn more. Thanks.

There was a similar question about migrating windows server - in my case it's linux.

Answer 1

The SystemRescueCD (http://www.sysresccd.org) now includes both partimage and fsarchiver. Either of these can do a disk-to-disk, partition-to-partition, or disk-to-image-to-disk duplication (like Symantec Ghost). fsarchiver is a bit newer and has some nicer features, but is commandline only. partimage has a curses-based gui, has a few warts, and doesn't seem to be currently maintained, but still works well. This will basically allow you to transfer a full disk image from the old disk to the new one.

If you are wanting to move your configs and data from the old server to a new clean one, you'll probably want anything you've edited in /etc, get dumps from any databases, and any other app data. /etc/passwd, /etc/shadow, and /etc/group should transfer without too much trouble. User homedirs should also transfer with relative ease. If your ACLs are in ldap, I imagine you should be able to sync from one server to the other. I don't know about facl, I've never looked at it.

If you are just doing the disk imaging method, you'll need to make sure the kernel from the old machine will work on the new one. You may need to boot to a livecd (like the sysresccd) to modify and build it before it will boot.

Answer 2

If the target disk is at least as big as the origin disk, then you can hook them both up on the same system. then do dd /dev/sda /dev/sdb, assuming sda is the origin and sdb is the target.

If not, then pop a live CD into the destination system and set up filesystems to be identical to how they are on the origin host. If the systems are on the same network and you trust that noone's going to snoop, then use FTP to copy every file onto the new host, otherwise use SFTP or SCP. One thing you're going to want to check is /etc/fstab to make sure that any disk labels mentioned can be referenced by label.

Answer 3

Normally I look at using either DD over Netcat or Partimage to image systems, but you left a comment saying that you don't have physical access to the box. This complicates things as you can't image anything without risking data inconsistency (unless you have all the data in a separate partition that can be unmounted).

One possibility is to try turning it into a virtual machine. The VMWare Converter will create an image of a running Linux system without any trouble (from when I converted a bulletin board system to a virtual machine on an ESXi system). I just had to adjust the network system (Ubuntu) after converting.

As a virtual machine, though, you get more flexibility in copying and re-deploying your system later on if you wish to do more with it down the road.

Answer 4

There's always the tried and true method of tarballing partitions, making partitions on the new box, starting up from a live disk on the new server, mounting partitions, scp'ing the tarballs, and untarring them on their new respective partitions. Or if you're really feeling lucky, tar directly into ssh and untar on the fly on the other side.

Answer 5

I've been imaging desktops with Clonezilla, but there's absolutely nothing that would prevent it from working on any machine.

The trick would be to get either attached or network storage with enough space to hold the system image. If it were me, I would use an NFS on the local subnet to store the image.

The way the process works is that you power down the machine, and insert the Clonezilla Live CD (this is assuming you don't have a clonezilla server, which seems likely given that you wouldn't have asked the question if you had). Clonezilla boots and then gives you the option of selecting whether you want to image a partition or entire disk. You'll probably want to do entire disk, since the source and destination are identical. It will ask where you want to store the image, so select NFS server, and then it should set up the networking and ask for the server and directory. Give it that, and it will copy the image across the network to the NFS server.

When the time comes to image the new server, just do the same thing as before, except tell Clonezilla that you want to restore an image, and follow the instructions as above.

Answer 6

reimaging the server to the new hardware is definitely the way to go here, but before you do that, I would also run sys-unconfig. In short - it's a sysprep for RHEL derivative Linux distros.