reloca.toby XServer

reloca.to/Guides

Moving a server to another hosting provider

The move most people mean when they say “we should move”: the server is at one provider, it should be at another, and nobody wants to rebuild it from memory. This is the procedure, end to end.

What this does, and what it does not

The whole installed system travels: the partitions, md RAID and LVM, the filesystems with their UUIDs, every package, every config file, the cron jobs, the certificates, the scripts somebody left in /opt three years ago. Nothing is reinstalled and no list of software has to be written.

What does not travel is the address. The new server lives in another network and has its own IP, so DNS has to be switched after the move. Licences tied to a MAC address or a machine id also need attention: the migrated system keeps its machine id, but the network card is new.

What you need

  • The new server, booted into a Live OS. At XServer that is the boot menu in the panel; the tool runs there, on the new machine.
  • The old server, reachable over ssh as root. It can keep running its own system, or be booted into the Live as well. The tool detects which.
  • Network between them. Anything from a 100 Mbit link upwards works; the faster it is, the shorter the whole thing.

You do not need access to the old provider's panel, a backup, or an agreement with anybody. Reading a disk over ssh is all the old side is asked for.

The move, step by step

Log in to the new server and install the tool. It fetches the packages it needs by itself.

ssh -A root@NEW-SERVER
curl -fsSL reloca.to | bash

Look at the plan first. The dry run reads both machines, prints what it would do, and changes nothing on either of them.

reloca.to -n root@OLD-IP

The plan is a text file you can read and edit: the layout of the new disk, which volume is copied block by block and which file by file, which UUIDs are kept, what is changed in fstab and in the network configuration. If it says something you did not expect, that is the moment to find out, not after the disk is written.

When it looks right, run the move.

reloca.to root@OLD-IP

Before the first write the tool prints what is on the target disk right now and asks you to type its name and size from the screen. A reflex “yes” cannot wipe the wrong disk. After that it partitions, copies, fixes the copy up in a chroot and runs dozens of checks; only a green verify lets it reboot.

While it copies

The tool lives in a tmux session, so a dropped ssh costs nothing: log back in and run reloca.to -s attach. Progress and an estimate are printed per volume, and a volume that fails can be retried on its own with -o redo=4 -s transfer.

How long it takes is the data divided by the link. Half an hour for a small server on a fast link, a few hours for a terabyte over a slow one. The old server keeps serving its users the whole time if you chose the on-line mode.

The switch, and the way back

The last phase takes the old server off the network and boots the new one into the migrated system. Keep the new server's console open: the first boot is only visible there.

If anything is wrong, the way back is the old server. It was only ever read, never written to, so it still has everything it had before. Start it, point DNS back, and nothing is lost. That is also why the tool refuses to reboot after a failed verify: exit code 3 means the disk is written but the system would not come up, so fix the cause and run reloca.to -s verify again.

After the move

  • Switch DNS to the new address. Lower the TTL a day in advance and the switch takes minutes.
  • Check what was bound to the old IP: firewall rules elsewhere, allow-lists at payment providers, mail reputation.
  • Keep the old server for a few days. It costs one more invoice and buys a rollback that needs no restore.

Every option of the tool, with its default and what it does, is in the option reference.

Try it on your own move

The tool is free, the dry run changes nothing, and the old server is only ever read.

curl -fsSL reloca.to | bash

All options