Move an instance to another site

There is no live migration between cities

Anyone offering you one is copying memory pages across a path with a hundred milliseconds of latency, and what arrives will be slower than what left. We do the honest version: stop, copy the disk, start it at the other end. Between two European sites a two-hundred-gigabyte disk is usually done inside ten minutes. Across an ocean, budget the same again.

Copies run over our own backbone and do not count against your fair-use figure.

The sequence

1. Lower the TTL on any DNS record pointing at the instance, at least a day ahead. Sixty seconds is right while you are moving.
2. Take a snapshot. It stays at the old site until you delete it, and it is what you fall back to.
3. Request the move, naming the destination site code.
4. The instance stops, the disk copies, and it starts at the destination with a new IPv4 and a new /64.
5. Update the A and AAAA records, set reverse DNS on the new addresses, and hunt down anything that hard-codes an address.
6. Raise the TTL again once you are happy.

curl -s -X POST https://paragonvps.com/api/v1/instances/<instance-id>/migrate -H "Authorization: Bearer $Paragon_TOKEN" -H "Content-Type: application/json" -d '{"site":"FRA-01"}'

curl -s https://paragonvps.com/api/v1/jobs/<job-id> -H "Authorization: Bearer $Paragon_TOKEN" | jq -r .state

The old address

Held for seventy-two hours after the move, so you can leave a redirect on it and catch whatever still points there. Then it returns to the pool. Tell us before the move if you need it longer and we will keep it.

The near-zero-downtime alternative

Where ten minutes of stop is unacceptable, build the destination first and copy while the original is still serving:

rsync -aHAX --numeric-ids --info=progress2 --exclude=/proc --exclude=/sys --exclude=/dev --exclude=/run /srv/ deploy@<new-ipv4>:/srv/

Run it twice: once with the service up, once after stopping it, so the second pass carries only the delta. Cut DNS between the two passes. This is more work and more risk than a disk copy, and it is the right answer for a database with a replica and the wrong answer for a web server that can be down for the length of a coffee.

Choosing where to go

Latency medians from our own probes are on the locations page. Jurisdiction is the other half of the decision and, for a good share of our customers, the larger half — the site you pick decides whose law your disk sits under, and no support ticket changes that afterwards.

Stock matters too. A site marked low will take the order and then take its time filling it, and a pre-order site is not somewhere to move a running service.

What breaks

• Windows licences activate against hardware and address. Expect to reactivate.
• Anything pinned by address on somebody else’s firewall. Ask them before the move, not after the phone rings.
• Hard-coded addresses in your own configuration. grep -r the config directory while the old instance is still running, because that is when the answers are easy to check.