[DigitalDaz]

Nothing is far fetched.

Back in the day and not with OVH, I had a dedicated server that I needed to put another OS on. I remember I did it by turning off the swap partition and installing a minimum linux system into the swap and then booting one time into it. That was a hairy day but I pulled it off. Good luck!

[gigabit]

Thanks for the replies!

I ended up getting a SSD based server instead, only £5 extra a month and raid0 produces 1.5GB/s reads. This presented the problem that I couldn't do an exact copy as the available space was considerably less.

However, it was still pretty easy!

I used the OVH manager to install the OS, but basically just using it to make my partitions/raid quickly - making them similar to old system. You could use a gparted live ISO with the KVM but that's not always reliable. (I use a RHEL based distro, but I think this can apply to nearly all others?)

I then had
/boot
/
/home

I put both servers into rescue so I could do the copy, I figured a non-live system would be easier. And for me I had two servers in a load-balanced setup so taking one offline isn't an issue. Leaving it online shouldn't be a problem but it would depend on your use case.

First you gotta note down the new systems UUIDs for the disks/raid! This is the only important step really. Log into the new system (not rescue) and perform:

ls -l /dev/disk/by-uuid

For example this produces:

lrwxrwxrwx 1 root root 9 Oct 10 18:07 8567dd7-5e06-4d2e-aa95-e5efc8990b6c -> ../../md2
lrwxrwxrwx 1 root root 9 Oct 10 18:07 9567c3b2-ff9e-4acb-b493-941e32484b3d -> ../../md3
lrwxrwxrwx 1 root root 9 Oct 10 18:07 9678471e-e172-4df4-aa2b-d95f63422ad7 -> ../../md1

If your system doesn't used UUIDs I believe regular /dev/sdX or /dev/mdX notation is used?

Then I left the /boot partition untouched since its got a kernel and all UUIDs for raids are already setup in grub etc (i dont use a custom kernel so didnt see any point touching this), but wiped / and /home which I then copied from original server.
Rsync was used so that different in disk size was not an issue, and it preserved file perms, works over ssh etc.

rsync -aAXv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} ./* :/mnt/raid2

Once you've copied a system only two things need changing, /etc/fstab and your network config.

/etc/fstab just needs to have its UUIDs updated to match those on the new system, otherwise none of your raids/disks will mount and you'll get a dracut shell.

Then update your network config to use the new servers IP, you only need to edit eth0/p4p1 if you move the rest of your IP failover with you. And if you're using VRACK i suggest you remove the old server and add the new one now, before you reboot.

In theory when you boot up everything should just work, the system has the same hostname, same internal IPs etc - it's nearly identical. As long as you got everything copied, made the changes, there's no reason why it won't work. For me I had no major issues, MySQL replication restarted no problems etc. Only problem I did have was gluster couldn't mount locally, but this was because it was doing a DNS (reverse)lookup on the ip/hostname which (thanks to DNS TTL) was still pointing to the old machine.


Hopefully this is clear enough for anyone else wanting to do something similar, apologies for my writing I know it's terrible...

Thanks all.

[heise]

Piece of cake with "dd". Look at https://pozzo-balbi.com/help/server-...ns/dd-over-ssh for my personal cheatsheet. Boot in rescue mode afterwards, chroot to your root partition and do the necessary adjustments.

This could give you an idea of what to look for:

From http://forum.kimsufi.com/showthread....l=1#post139256

chroot /mnt/md
update system, like grub, passwords, fstab, ip addresses, network mac, etc. and enjoy

Some things to look at (this is for CentOS 6):
cat /proc/mounts > /etc/mtab
grub
grub> root (hd0,0)
grub> setup (hd0)
grub> quit

passwd
passwd user

update /etc/resolv.conf
update /etc/hosts
update /etc/sysconfig/network
update /etc/sysconfig/keyboard
update /etc/sysconfig/iptables
update /etc/sysconfig/ip6tables
update /etc/sysconfig/i18n
update /etc/sysconfig/clock
ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime
update /etc/sysconfig/ifcfg-eth0
update /etc/sysconfig/ifcfg-br0
rm /etc/sshd/*key
rm /etc/sshd/*key.pub

chkconfig sshd on

List could be incomplete.

[Razakel]

This is quite far-fetched, but has anyone been able to use kvm/sysrescue etc to clone a servers drive entirely and copy to a new server? Same hardware, diff datacentre.

Let's say you have two servers in a cluster, but you ordered them so close together they're actually in the same rack which kind of defeats the point especially when OVH test their generators and it's possible for a whole room to be taken out (happened a few months ago). So you think you should get an EG-32 in GRA to replace one of the two you have in RBX, and obviously there's no issue doing this but it'd be a lot more convenient if cloning the drives was possible, especially where the set-up has evolved quite a lot from a standard web stack.

If not I'll probably experiment myself when I can find the time!

Cheers

I don't see any reason you couldn't do it using something like dd | gzip | netcat on either end, provided the drives are the same size. Boot into rescue mode, fix network config and you should be laughing.

[marks]

This possibility has not developed at OVH as reinstalling a server from scratch is quite a straight forward unattended process, and a type of cloning procedure would have too many things that could go wrong (different hardware, different number of drives, raid configurations, ...).

well, I'm not aware of customers that have managed to do a proper clone, though some definitely used the KVM to install their own OSes.

Also, I believe, the rescue mode could be another way to do images of running drives.

[gigabit]

This is quite far-fetched, but has anyone been able to use kvm/sysrescue etc to clone a servers drive entirely and copy to a new server? Same hardware, diff datacentre.

Let's say you have two servers in a cluster, but you ordered them so close together they're actually in the same rack which kind of defeats the point especially when OVH test their generators and it's possible for a whole room to be taken out (happened a few months ago). So you think you should get an EG-32 in GRA to replace one of the two you have in RBX, and obviously there's no issue doing this but it'd be a lot more convenient if cloning the drives was possible, especially where the set-up has evolved quite a lot from a standard web stack.

If not I'll probably experiment myself when I can find the time!

Cheers