Linux Server Migration

This guide copies application data, databases, and service configuration from your current Linux server to an Arct Cloud server. Read the migration overview first.

Copy application data and configuration, not the whole root filesystem. See why a clean target beats a disk clone.

Stop or pause any service that writes while you copy its data. Anything written after the copy starts is left behind, and the gap is easy to miss until the new server is already live.

Deploy the Target Server

Deploy a Linux server with at least the disk and memory the source server uses. See Deploy a Server, then connect over SSH. Match the source distribution and major version where you can. Moving Ubuntu 22.04 to Ubuntu 24.04 works, but expect config changes in nginx, PHP, and systemd unit paths.

Set Up Access Between Servers

Generate a dedicated key on the Arct Cloud server and pull data from the source. Pulling means the source never needs credentials for the new machine.

sudo ssh-keygen -t ed25519 -N "" -f /root/.ssh/migration
sudo cat /root/.ssh/migration.pub

Add that public key to ~/.ssh/authorized_keys for the root user on the source server, then confirm the connection:

sudo ssh -i /root/.ssh/migration root@SOURCE_IP hostname

Delete /root/.ssh/migration and remove the key from the source server once the migration is done.

Capture the System State

Application files are the obvious half. The other half is the account, key, and rule state your app depends on. Bundle it on the source server in one pass so nothing is missed:

sudo tar -czf /tmp/system-state.tar.gz \
  /etc/passwd /etc/group /etc/shadow /etc/gshadow \
  /etc/ssh/sshd_config /root/.ssh /home/*/.ssh \
  /etc/crontab /etc/cron.d /var/spool/cron

Firewall rules are readable rather than file-based, so export them alongside, still on the source server:

sudo ufw status numbered > /tmp/ufw-rules.txt

Copy both to the new server and unpack the bundle somewhere safe to read from. Do not overwrite the new server’s own /etc/passwd or /etc/shadow with the old ones; use them as the reference when you recreate accounts:

sudo scp -i /root/.ssh/migration \
  root@SOURCE_IP:/tmp/{system-state.tar.gz,ufw-rules.txt} /tmp/
sudo mkdir -p /tmp/old-state
sudo tar -xzf /tmp/system-state.tar.gz -C /tmp/old-state

Install the Same Packages

On the source server, list the packages you installed by hand:

apt-mark showmanual > /tmp/packages.list

Copy the list over and install it on the Arct Cloud server:

sudo scp -i /root/.ssh/migration root@SOURCE_IP:/tmp/packages.list /tmp/
sudo apt-get update
xargs -a /tmp/packages.list sudo apt-get install -y

On RHEL, AlmaLinux, or Rocky, use dnf repoquery --userinstalled --qf '%{name}' and dnf install.

Copy Application Data

Use rsync for each directory that matters. Run it as often as you like; only changed files transfer.

sudo rsync -aAXH --numeric-ids --info=progress2 \
  -e "ssh -i /root/.ssh/migration" \
  root@SOURCE_IP:/var/www/ /var/www/

Flag	Why
`-a`	Preserves permissions, timestamps, symlinks
`-A -X`	Keeps ACLs and extended attributes
`-H`	Preserves hard links
`--numeric-ids`	Copies numeric UID and GID instead of remapping by name

Repeat for the rest: /etc/nginx/, /opt/, /home/, /srv/, and any application-specific paths.

The trailing slash on the source path matters. /var/www/ copies the contents; /var/www copies the directory itself into the target.

Move Databases

Never rsync a running database’s data directory. Dump it instead, or stop the database first.

MySQL or MariaDB

On the source server:

mysqldump --single-transaction --routines --triggers \
  --all-databases > /tmp/mysql-dump.sql

On the Arct Cloud server:

sudo scp -i /root/.ssh/migration root@SOURCE_IP:/tmp/mysql-dump.sql /tmp/
sudo mysql < /tmp/mysql-dump.sql
sudo systemctl restart mysql

Application users and grants come across with --all-databases. Verify with SHOW GRANTS FOR 'appuser'@'localhost';.

PostgreSQL

On the source server:

sudo -u postgres pg_dumpall > /tmp/pg-dump.sql

On the Arct Cloud server:

sudo scp -i /root/.ssh/migration root@SOURCE_IP:/tmp/pg-dump.sql /tmp/
sudo -u postgres psql -f /tmp/pg-dump.sql postgres

pg_dumpall includes roles and passwords. Match the major PostgreSQL version on both sides.

MongoDB

mongodump --out /tmp/mongo-dump

Copy the directory across, then restore:

mongorestore /tmp/mongo-dump

Redis

Trigger a save on the source, copy /var/lib/redis/dump.rdb while Redis is stopped on the target, then start it:

redis-cli SAVE

Recreate Services and Schedules

Copy your unit files, then reload:

sudo rsync -a -e "ssh -i /root/.ssh/migration" \
  root@SOURCE_IP:/etc/systemd/system/ /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable --now your-service

Recreate local users with the same UID before copying files they own. Read the original UID out of the captured /tmp/old-state/etc/passwd:

sudo useradd -u 1001 -m -s /bin/bash appuser

Restore each user’s crontab from the captured state, then check /tmp/old-state/etc/cron.d for system-level jobs:

sudo crontab -u appuser /tmp/old-state/var/spool/cron/crontabs/appuser

Reapply the Firewall

Read the rules you exported to /tmp/ufw-rules.txt, then recreate them:

sudo ufw allow OpenSSH
sudo ufw allow 80,443/tcp
sudo ufw enable

On firewalld, use firewall-cmd --list-all and firewall-cmd --permanent --add-service=.

Verify Before DNS

Point your own machine at the new server without touching public DNS. Add a line to your local hosts file, /etc/hosts on Linux and macOS or C:\Windows\System32\drivers\etc\hosts on Windows:

NEW_SERVER_IP example.com www.example.com

Load the site, sign in, submit a form, and check the logs:

sudo journalctl -u your-service -n 100 --no-pager

Remove the hosts entry when you are done testing.

Cut Over

Stop Writes on the Source

Put the application in maintenance mode or stop its service so no new data lands on the old server.

Run a Final Sync

Repeat the rsync commands and re-dump the database. This pass is fast because only recent changes transfer.

Update DNS

Change the A and AAAA records to the new IP. See Website and DNS Migration for record-level detail.

Watch the New Server

Follow the logs and the CPU, memory, and network graphs on the server detail page for the first hour.

Decommission the Source

Keep the old server for a few days, then run the checks before you delete it.

Troubleshooting

Permission denied (publickey) when pulling from the source

Confirm the public key is in the source’s /root/.ssh/authorized_keys, that the file is chmod 600, and that PermitRootLogin allows key auth in the source’s /etc/ssh/sshd_config.

Files arrive owned by the wrong user

You omitted --numeric-ids, so rsync remapped ownership by name. Recreate the users with matching UIDs, then re-run the sync with the flag.

The application starts but cannot reach its database

Check the connection host in your app config. localhost on the old server may have meant a socket path that differs on the new distribution version. Confirm the database is listening with ss -lntp.

rsync fails with 'No space left on device'

Run df -h on the target. If the plan disk is smaller than the source’s used space, resize before continuing.

SELinux blocks the web server after copying files

On RHEL-family systems, restore the file contexts: sudo restorecon -Rv /var/www.

Getting Started

Virtual Machines

Migrations

Billing & Payments

Account

Linux Server Migration

Deploy the Target Server

Set Up Access Between Servers

Capture the System State

Install the Same Packages

Copy Application Data

Move Databases

Recreate Services and Schedules

Reapply the Firewall

Verify Before DNS

Cut Over

Troubleshooting

​Deploy the Target Server

​Set Up Access Between Servers

​Capture the System State

​Install the Same Packages

​Copy Application Data

​Move Databases

​Recreate Services and Schedules

​Reapply the Firewall

​Verify Before DNS

​Cut Over

​Troubleshooting

Deploy the Target Server

Set Up Access Between Servers

Capture the System State

Install the Same Packages

Copy Application Data

Move Databases

Recreate Services and Schedules

Reapply the Firewall

Verify Before DNS

Cut Over

Troubleshooting