On Wed, 2008-01-02 at 11:50 +0000, Mark Rogers wrote:
The server is only used internally but all the same I want to minimise downtime. The "normal" method I'd use would be to shut down the hardware, take an image of the drive, restore it into a virtual machine, boot it, fix any problems (eg driver issues) as necessary. Depending how long that last step takes this could mean the system is offline for quite a while.
It is a pity that vmware converter is a. only currently offering experimental support for linux source machines b. only currently works in offline mode on linux source machines and c. offline mode is afaik only available in the paid for version. Otherwise it would be the perfect tool for the job :)
I could create an empty VM, boot it to a live CD, and rsync the whole OS data from the old system to the new one, but I'm not sure which rsync options I'd need to use to make sure the user permissions copied across correctly (I assume that since /etc/passwd will be copied across it doesn't matter that the users don't exist initially), then make the VM's disk bootable, and take it from there; all of that I could do with the other system online and then fix the problems in the VM with the old system still online, ready to re-rsync later to catch up with any changes after shutting down all services like the database etc. But (a) I'm not sure how to make the VM boot and (b) I'm not sure what else would go wrong.
You could do that and then fix grub/lilo which *should* give you a bootable system. But personally if rebuilding the system from scratch isn't an option then I would do a minimal installation of RH9 and get it up to the same versions with respect to kernel updates and then do as you say with rsync but avoiding /boot.
I have produced perfectly functional DR twins of legacy unix and linux boxes by this method where modifications and customisation over time has been left undocumented, to prove that even without the documentation we could produce a complete and functional system from the backup tapes (which were archiving everything). However I would strongly consider building the system from scratch in your case as although you are trying to minimise downtime you can spend time getting a mirror system built before you migrate the data and this would equip you better with the knowledge to recreate it on a newer OS later on
Of course if the aim is just to minimise the time spent tinkering and you don't see value in turning this into more of a Disaster Recovery test then your proposed method may or may not save time depending on problems you encounter with different hardware, fixing the bootloader (in itself pretty easy) etc