[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: a pseudo-"clone" facility for migrating to new hardware?



Robert P. J. Day wrote:
  into the final stages of my debian upgrade adventure, and here's the
final phase.  at the moment, i have a couple more upgrade steps to get
the existing server (old dell P4 system) up to a fully-upgraded lenny
system, and make sure all the software still works properly (web
server, mail server, etc.).  and this is on a system where there is a
single root filesystem (/dev/sda1), so it's a very simple partitioning
layout.

  once that upgrade is done, i want to pick up the entire install, and
move it to a new dual-drive poweredge server, obviously keeping
everything in place.  but i want to format the new system with LVM and
multiple filesystems for robustness.  so what's the best way to do
that?

  the obvious solution is to take the running server offline, reboot
to a rescue CD, and copy the entire rootfs verbatim to a backup
device, connect that backup device to the new server, and restore with
a directory-oriented restoration which will honour the new LVM layout.
but that suggests that the new server already has a debian install on
it, so that restoration will obviously end up writing over top of an
existing install.  is that safe?

  i find it hard to believe that would work cleanly as the old log
files (dpkg, aptitude and so on) would overwrite the ones on the new
server, and i'm betting i'd end up with all sorts of inconsistencies.
the only way i can think of avoiding that kind of grief would be for
me to do the barest install on the new server, where the packages i
installed there would be an absolute subset of the ones on the old
server.  or, better yet, just arrange for empty filesystems to be
sitting there, waiting to be filled.

  is there, perhaps, a utility for this sort of thing?  after all,
this has to be a fairly common occurrence -- moving a working debian
system from an aging, old system to a newer one.  thoughts?


Not that I know of. My advice would be to grit your teeth and install a completely new system, based on your existing packages. Then copy the data and as much configuration information as possible. Sorry.

Upgrading isn't a totally clean job: I upgraded from etch to lenny, and there were a few hiccups. If you use exim4, and you haven't upgraded it yet, the configuration model is a bit different, and if you tell it to use the existing configuration, it will die horribly. It won't accept any debconf directives, and once the daemon is installed, it can't be configured, and it won't allow either the installation to complete or for the broken bit to be removed. Not even with the more brutal options of dpkg. I had to resort to manually deleting files to clean that up. Just one example, though to be fair it was the worst. Apache/php is also very slightly different, and I still have a couple of minor quirks I haven't tracked down yet. Unavoidable whichever way you go.

As you're also changing hardware and moving to LVM, I'd think there are enough potential gotchas to do a clean install. That way, you also get to bring it up in parallel, and can fix some problems with reference to a running system. I was in almost exactly the same position, having upgraded old hardware to lenny prior to moving, and the experience of the upgrade led me to do a clean install and data migration, which wasn't difficult.

There is also the point that an upgraded system is not identical to a clean install. Some things will end up slightly different, particularly configurations, as some shortcuts will clearly be possible if there's no existing system to stay compatible with. My etch was already an upgrade from sarge, which may have complicated things. I'm sure it is possible to just keep upgrading, and that a number of people will jump in and tell me they have done this from potato or earlier, but I run a live mail server with no backup and I really don't want it to be down for more than a couple of hours. Parallel running was very attractive.
--
Joe


Reply to: