Copy a VPS to Another Account or Provider: Safe Migration Guide

This guide walks you through copying a virtual private server (VPS) to a different account or provider without losing data, breaking configurations, or exposing sensitive information. You’ll learn how to create a full backup, transfer it safely, restore it on the new host, and verify everything works before switching over.

What You’ll Need

• SSH access to the source VPS (root or sudo privileges)
• SSH access to the destination VPS (root or sudo privileges)
• Credentials for both hosting accounts (or the ability to create a new server)
• Enough free disk space on the destination to hold the backup
• A stable internet connection for the transfer

Step-by-Step

1. Inventory your source VPS. Log in via SSH and run df -h to see disk usage, free -h for memory, and cat /etc/os-release for the OS version. Note the exact OS, architecture (x86_64, arm64), and any custom kernel modules.
2. Create a full backup using tar. On the source, run:

   sudo tar -czpvf /backup/backup.tar.gz --exclude=/backup --exclude=/proc --exclude=/sys --exclude=/dev --exclude=/run --exclude=/tmp --exclude=/lost+found /

   This creates a compressed archive of the entire filesystem, preserving permissions and ownership. Adjust the exclude list if you have other mount points (e.g., /mnt/data).

3. Copy the backup to your local machine or directly to the destination. For a direct transfer, use rsync or scp:

   scp /backup/backup.tar.gz user@destination:/backup/

   If the destination isn’t ready yet, download it locally with scp and upload later.

4. Prepare the destination VPS. Provision a new VPS with the same OS version and architecture as the source. Ensure it has at least as much disk space as the source used. Do not start any services that might conflict; a fresh install is fine.
5. Stop services on the destination (if any). If the destination is already running, stop web servers, databases, and other services to avoid data corruption during the restore.
6. Restore the backup on the destination. Extract the archive to the root filesystem:

   sudo tar -xzpvf /backup/backup.tar.gz -C /

   This overwrites existing files. If you want to avoid overwriting, restore to a temporary directory and copy files selectively.

7. Recreate missing directories and fix permissions. After extraction, ensure essential directories exist:

   sudo mkdir -p /proc /sys /dev /run /tmp
   sudo chmod 1777 /tmp

   Then run sudo chown -R root:root /etc /usr /var (adjust as needed) to fix any ownership issues.

8. Update network and boot configuration. Edit /etc/network/interfaces (Debian/Ubuntu) or /etc/sysconfig/network-scripts/ifcfg-eth0 (CentOS) to use the destination’s IP address, gateway, and DNS. Update /etc/hosts and /etc/hostname.
9. Reinstall the bootloader (if necessary). On a new VPS, the bootloader (GRUB) is usually installed by the provider. If you restored over a fresh install, it should be fine. If not, run sudo grub-install /dev/vda (or your disk device) and sudo update-grub.
10. Reboot the destination. Run sudo reboot and wait for it to come back up. If it doesn’t, use the provider’s console (VNC/HTML5) to see boot errors.
11. Verify services and data. After boot, check that all services start: sudo systemctl list-units --failed. Test web, database, and any custom applications. Compare file integrity with a checksum on a few key files.
12. Update DNS and cut over. Change DNS records to point to the new VPS’s IP. Keep the old VPS running for a few days to handle any lingering connections or missed data.

Common Mistakes

• Forgetting to exclude virtual filesystems. Including /proc, /sys, /dev, or /run in the tar creates errors and bloats the backup.
• Mismatched OS or architecture. Restoring a CentOS 7 backup onto an Ubuntu 20.04 VPS will fail. Always match the OS and architecture.
• Overwriting the destination’s network config. The backup includes the source’s network settings, which will have the wrong IP and gateway. You must edit them before rebooting.
• Skipping the bootloader reinstall. On some providers, the bootloader is tied to the disk image; if you replace the entire disk, GRUB may be missing.
• Not testing the backup. A backup that hasn’t been restored is not a backup. Always test on a temporary VPS first.

Tips

• Use rsync for incremental backups. Instead of a full tar every time, use rsync -avz --delete / user@destination:/ to sync changes after the initial copy. This reduces downtime.
• Compress with a higher level. tar -czpf uses gzip; for better compression, use tar -cjpf (bzip2) or tar -cJpf (xz). It takes longer but saves bandwidth.
• Snapshot the disk first. Many providers offer disk snapshots. Take one before migrating so you can roll back instantly if something goes wrong.
• Keep the source running during the copy. For databases, use mysqldump or pg_dump to get a consistent snapshot, then copy the dump separately.
• Document your configuration. Write down all custom settings, cron jobs, and firewall rules. This helps you reconfigure the new server if needed.

Troubleshooting

Server doesn’t boot. Use the provider’s console to see the boot log. Common causes: missing bootloader, wrong fstab entries, or kernel panic. Boot into rescue mode, chroot into your filesystem, and fix the issue.

Network is down after boot. Check ip addr and ip route. Ensure the interface name matches (e.g., eth0 vs ens3). Edit the network config to use the correct interface and IP.

Services fail to start. Run journalctl -u service.name to see logs. Often it’s a permission issue or a missing configuration file. Compare with the source server’s /etc directory.

Database corruption. If you copied a live database without dumping, the files may be inconsistent. Restore from a logical dump instead. If you already restored, you may need to repair the database using its tools (e.g., mysqlcheck).

SSL certificates not working. Certificates are tied to domain names, not IPs. If you’re using the same domain, they should work. If not, reissue them.

Frequently Asked Questions

Can I migrate between different hosting providers?

Yes, as long as you have SSH access and the new provider allows custom ISO or full disk restore. The steps are identical.

Do I need to reinstall software after restoring?

No, the backup includes all installed packages and binaries. However, kernel modules may need recompilation if the kernel version differs.

How long does the migration take?

It depends on the size of the VPS and your internet speed. A 20GB VPS with a 100Mbps connection takes about 30 minutes to transfer, plus restore time.

Can I test the new VPS before switching DNS?

Yes, you can edit your local hosts file to point the domain to the new IP and test. Or use a temporary subdomain.

What if I don’t have root access on the source?

You need at least sudo access. If you don’t have it, contact your provider for a full backup or ask them to migrate for you.

Is it safe to keep the old VPS running after migration?

Yes, it’s recommended. Keep it for at least 48 hours to ensure no data is missed and to allow DNS propagation.

Related

• Samsung Note 7 Users: Was There an Extra $100 Phone Offer?
• Ollama Performance Tuning for Faster Local LLMs
• Evaluate AI-Generated Code Fixes Before Merging