Migrate VPS data safely with rsync

Inventory before copying

List application files, ownership, ACLs, extended attributes, databases, secrets, scheduled jobs, services, firewall rules, DNS, certificates, and external storage. Confirm enough destination capacity and compatible users, filesystems, operating-system packages, and application versions. Reduce DNS TTL ahead of cutover only when that change fits your DNS plan; cached records can still outlive expectations.

Create and verify an independent backup of the source. Keep the source unchanged and available throughout the initial transfer. Define success checks and a rollback decision before announcing a maintenance window.

• Do not copy virtual filesystems such as /proc, /sys, /dev, or /run as ordinary data.
• Use native database backup, replication, or dump tools where appropriate.
• Never place private keys in command history or shared notes.

Stage application data with a dry run

For a directory such as /srv/app/, test the operation from the source with sudo rsync -aHAX --numeric-ids --info=progress2 --dry-run -e "ssh -i /root/.ssh/migration_key" /srv/app/ admin@DESTINATION:/srv/app/. Replace the user, key path, destination, and data paths. The trailing slash means copy the contents of the source directory rather than create an extra directory level.

Review every path and error. Ensure the remote account can write the destination safely; using root login is unnecessary and often disabled. When the dry-run output is correct, repeat the command without --dry-run. Do not add --delete merely to make directories identical: an incorrect source or destination could remove valuable data.

• Run the command inside a persistent terminal session for large transfers.
• Limit bandwidth if the copy could affect production traffic.
• Capture command options and tool versions in the migration record.

Quiesce writes and perform the final pass

Put the application into a documented maintenance or read-only state. Stop the exact writer services using their supported procedure, then take the final database backup or complete replication. Run the same rsync command again so only changed file data is transferred. Preserve the maintenance state until validation is complete.

Start services on the destination using the intended configuration, initially restrict public access if possible, and run health, login, write, queue, certificate, log, and dependency checks. Update DNS or routing only after those tests pass. Avoid changing both the application version and hosting location in the same window unless the combined risk is explicitly accepted.

• Record the final write-stop time and synchronization result.
• Validate file ownership and mandatory-access controls.
• Watch old and new endpoints during DNS transition.

Verify, observe, and retain rollback

For a deeper file comparison, run the original rsync command with --checksum --dry-run during a suitable window; checksumming reads both datasets and can be expensive. Prefer application-level integrity checks for databases and object stores. Monitor errors, latency, resource use, background jobs, and external callbacks after cutover.

Keep the source intact but prevent split-brain writes until the rollback window ends. Then follow the retention and secure-deletion plan. A migration is complete only when backups, monitoring, documentation, and recovery procedures refer to the destination.