Migrating a server to Synteq

Systems Administration

Migrating a server to Synteq

Updated

Move a whole VPS to a new Synteq server by copying its disk, byte for byte, over SSH. Nothing gets reinstalled and nothing gets restored from a backup, so there's no software stack to match up on the other side. What boots on the new server is exactly what was on the old one.

This is the right guide if you want your existing OS, packages, config and data to carry over as-is. If you only need a handful of files, a fresh install plus rsync is quicker.

Before you start

  • Order the new server from the portal first.
  • The new disk must be at least as big as the old one. Bigger is fine, but smaller won't work.
  • Both servers are offline while the copy runs. The old server boots into rescue mode and the new server boots from a rescue ISO, so plan for downtime. The copy runs as fast as the link between the two locations allows.
  • Read the disk names twice. dd does exactly what you tell it. Pointing it at the wrong disk destroys data with no confirmation prompt, so the "check your disks" step is not optional.
  • The new server has a new IP address. Your copied OS will boot with the old network config. Most images pick up the new address automatically on first boot; if yours doesn't, the console is there to fix it (step 7).
  • Have these to hand: the legacy server's rescue-mode password (the legacy panel shows it), and the new server's IP, netmask and gateway from its Network tab.
Info: This works between any two KVM servers, which covers every legacy VPS and every new Synteq VPS or VDS.

1. Put the legacy server into rescue mode

  1. Back on your legacy server's page, click Open to sign in to the legacy panel.
Screenshot 2026-09-18 at 4.29.20 PM.png
  1. Shut the server down, then start rescue mode.
Screenshot 2026-09-18 at 4.35.25 PM.png
Screenshot 2026-09-18 at 4.37.13 PM.png
Warning: Don't skip the shutdown. Copying a disk while the OS is still writing to it gives you a corrupt copy.
  1. You'll receive an email with the rescue password login. Use this to SSH into your VPS
Screenshot 2026-09-18 at 4.40.23 PM.png

3. Boot the new server from a rescue ISO

  1. Open the new server and click the Settings tab.
  2. Under ISO Media, click Add ISO, paste the GRML-FULL download URL https://download.grml.org/grml-full-2026.09-amd64.iso and start the download. Grml includes everything used in this guide, GParted included.
Screenshot 2026-09-18 at 4.43.38 PM.png
  1. When the download finishes, mount it and restart the server. It boots from the ISO before the disk.
  2. Click Console. You'll land on a root shell inside Grml.
Screenshot 2026-09-18 at 6.55.20 PM.png

4. Give the rescue system a network connection

Grml doesn't know the new server's IP yet. In the console, set it by hand using the values from the Network tab:

iplink

You'll see lo and one other interface - on Synteq servers it's usually ens18. Use that name in place of ens18 below if yours is different:

ip link set ens18 up
ip addr add NEW_IP/PREFIX dev ens18
ip route add default via GATEWAY
ping -c 2 LEGACY_IP

All three values are on the new server's Network tab. Each row in the IP Addresses card shows the address, then a small pill like /26 (that's the prefix), then a pill like GW 203.0.113.1 (that's the gateway). Put the address and prefix together with no space - for example 203.0.113.10/26 - and use the GW value for GATEWAY. The prefix matters: without it the gateway is unreachable and the ping fails. If the ping comes back, you're connected.

Screenshot 2026-09-18 at 7.07.06 PM.png
Screenshot 2026-09-18 at 7.10.40 PM.png

5. Check which disk is which

Rescue systems add a RAM disk and sometimes shuffle device names, so don't assume. Run lsblk on both sides and match by size.

On the legacy server (over SSH):

lsblk

The disk you want is the one that matches your legacy plan's size. On legacy servers it's almost always /dev/vda.

Screenshot 2026-09-18 at 7.14.36 PM.png

On the new server (in the console):

lsblk

New Synteq servers present their disk as /dev/sda. It'll be the same size as the legacy disk or bigger.

Screenshot 2026-09-18 at 7.14.51 PM.png
Warning: Write both names down before you continue. Everything below assumes /dev/vda on the legacy side and /dev/sda on the new side - swap them for whatever lsblk actually showed you.

6. Copy the disk

Run this in the new server's console. It pulls the legacy disk over SSH and writes it straight onto the new disk:

ssh root@LEGACY_IP "dd if=/dev/vda bs=32M" | dd of=/dev/sda bs=32M status=progress

Rather than typing it, copy the command with your real addresses filled in and use the Paste button in the console toolbar - one wrong character in a dd command is the difference between a migration and a wipe. Type the rescue password when asked.

Here's what each part does:

  • ssh root@LEGACY_IP "..." runs the quoted command on the legacy server and streams its output back.
  • dd if=/dev/vda bs=32M reads the whole legacy disk, 32 MB at a time.
  • | hands everything that comes out of the left side to the right side.
  • dd of=/dev/sda bs=32M writes those bytes onto the new disk, in the same order.
  • status=progress shows bytes copied and speed while it runs. Without it you get nothing until the end.

The progress line updates once a second.

Screenshot 2026-09-18 at 7.16.52 PM.png

When the copy finishes you'll see a summary of bytes copied and how long it took. Run sync afterwards to make sure everything's flushed to disk.

Info: A 20 GB disk over a good link takes roughly 10 to 20 minutes. Large disks over long distances take a while - leave the console open and let it run.

7. Boot the new server from its disk

  1. Back in the Settings tab, unmount the ISO.
  2. Restart the server. It now boots the copied OS.
  3. Open the Console and watch it come up. Once you see a login prompt, try ssh root@NEW_IP from your own machine.

If SSH connects, you're done with the copy. If it doesn't, the OS is probably still configured for the old IP address. Sign in on the console and set the new address, netmask and gateway wherever your OS keeps its network config (netplan on Ubuntu, /etc/network/interfaces on Debian, /etc/sysconfig/network-scripts on Alma and Rocky), then restart networking.

8. Check it over, then retire the legacy server

  1. Confirm your services are running and reachable on the new IP.
  2. Update any DNS records that point at the old IP.
  3. If everything checks out, you can let the scheduled shutdown happen, or open the legacy server's page and click Terminate now to stop paying for it early.

Growing into a bigger disk

If the new disk is bigger than the old one, the extra space isn't available yet - the copied partition table still thinks the disk is the old size.

  • Easy way: boot from the grml ISO again (step 3), run grml-x fluxbox in the console, then gparted in the terminal that opens. Right-click the last partition, choose Resize/Move, drag it to fill the disk and apply.
  • From the command line: on a plain partition layout, growpart /dev/sda 1 followed by resize2fs /dev/sda1 (or xfs_growfs / for XFS). If growpart isn't there, parted /dev/sda resizepart 1 100% does the same job. If you're on LVM, grow the partition first, then pvresize, lvextend -l +100%FREE and resize2fs on the logical volume.