Transférer son VPS en un seul coup avec rsync : guide de migration complet

Pourquoi migrer un VPS avec rsync ?

Quand on change d'hébergeur, qu'on monte en gamme ou qu'on déplace une infrastructure, l'idée de tout réinstaller — paquets, configurations, certificats, données applicatives — fait peur. Heureusement, rsync permet de cloner un système Linux quasiment à l'identique vers une nouvelle machine, en une seule opération, sans devoir refaire les configurations à la main.

L'astuce consiste à copier l'ensemble du système de fichiers sauf les éléments propres au matériel et au noyau du serveur cible (boot, modules, fstab, interfaces réseau…). Le résultat : un nouveau VPS qui se réveille avec les mêmes services, les mêmes utilisateurs, les mêmes données que l'ancien.

1. Vérifier la compatibilité des deux serveurs

Avant tout, les deux machines doivent tourner sur la même distribution et la même version majeure. Migrer une Debian 11 vers une Debian 12 fonctionnera dans la plupart des cas, mais migrer une Ubuntu vers une CentOS posera des problèmes de chemins, de gestionnaires de paquets et de bibliothèques système.

Pour vérifier la version, voici les commandes selon la distribution :

Ubuntu

cat /etc/lsb-release

Debian

cat /etc/issue

RHEL / Fedora / CentOS / Rocky / AlmaLinux

cat /etc/redhat-release

openSUSE

cat /etc/SuSE-release

Slackware

cat /etc/slackware-version

Vérifiez aussi que l'architecture est identique (x86_64, arm64…) avec uname -m. Cloner un x86_64 sur un arm64 ne fonctionnera pas — les binaires sont incompatibles.

2. Installer rsync sur les deux serveurs

Sur Debian/Ubuntu :

apt-get install rsync -y

Sur RHEL/Fedora/CentOS :

dnf install rsync -y

Profitez-en pour vous assurer que SSH est bien actif sur le nouveau serveur et que vous pouvez vous y connecter en root depuis l'ancien (clé SSH ou mot de passe).

3. Préparer la liste des exclusions

Certains fichiers ne doivent jamais être copiés depuis l'ancien serveur, car ils sont propres au matériel, au boot ou au réseau du nouveau. Les copier casserait le démarrage du nouveau VPS.

Sur le serveur source, créez le fichier /tmp/exclude.txt avec le contenu suivant :

/tmp
/boot
/lib/modules
/etc/blkid
/etc/mtab
/etc/lvm
/etc/fstab
/etc/udev
/etc/inittab
/dev
/proc
/etc/network/interfaces
/sys
/run
/var/lock
/etc/mdadm.conf
/etc/resolv.conf
/etc/conf.d/net
/etc/networks
/etc/sysconfig/network*
/etc/sysconfig/hwconf
/etc/sysconfig/ip6tables-config
/etc/sysconfig/kernel
/etc/hostname
/etc/HOSTNAME
/etc/hosts
/etc/modprobe*
/etc/modules
/net
/etc/rc.conf
/usr/share/nova-agent*
/usr/sbin/nova-agent*
/etc/init.d/nova-agent*

Ces exclusions couvrent :

• Les répertoires virtuels (/proc, /sys, /dev) qui ne doivent jamais être copiés.

• Le boot et les modules noyau, propres au kernel du nouveau VPS.

• Les configurations réseau et hostname du nouveau serveur (sinon il perd sa connectivité au reboot).

• Les fichiers temporaires (/tmp, /run, /var/lock).

• Les agents propriétaires de certains hébergeurs (nova-agent par exemple).

4. Lancer la migration avec rsync

Sur le serveur source, lancez la commande suivante en remplaçant NOUVELLEIP par l'adresse IP de votre nouveau VPS :

rsync -avrz -H -X --one-file-system --numeric-ids \
  --exclude-from=/tmp/exclude.txt \
  -e ssh / root@NOUVELLEIP:/

Décortiquons les options :

• -a : mode archive (préserve permissions, propriétaires, timestamps, liens symboliques).

• -v : verbose, pour suivre la progression.

• -r : récursif (déjà inclus dans -a, mais explicite).

• -z : compression à la volée (utile sur lien WAN, inutile en LAN rapide).

• -H : préserve les hard links.

• -X : préserve les attributs étendus (xattr) — important pour SELinux, ACL POSIX.

• --one-file-system : ne traverse pas les points de montage (évite de copier des disques externes).

• --numeric-ids : conserve les UID/GID numériques au lieu de remapper les noms.

• --exclude-from : applique la liste d'exclusions.

• -e ssh : transfert chiffré via SSH.

Selon la taille des données et la qualité du lien réseau, comptez de quelques minutes à plusieurs heures. Pour un transfert long, lancez la commande dans un screen ou un tmux pour qu'elle survive à une déconnexion SSH :

screen -S migration
# puis lancez rsync
# Ctrl+A puis D pour détacher

5. Redémarrer et valider le nouveau serveur

Une fois rsync terminé, redémarrez le nouveau serveur :

reboot

⚠️ Attention au mot de passe SSH : si l'ancien VPS et le nouveau n'avaient pas le même mot de passe root, c'est désormais celui de l'ancien qui s'applique au reboot, puisque /etc/shadow a été copié. Notez-le bien avant la migration.

Au redémarrage, vérifiez :

• Que la machine répond toujours en SSH.

• Que vos services critiques (web, base de données, mail…) ont bien démarré : systemctl status.

• Que les logs ne hurlent pas : journalctl -p err -b.

• Que le hostname et l'IP sont corrects (ils doivent rester ceux du nouveau serveur grâce aux exclusions).

Cas particuliers à anticiper

Docker

Si votre serveur utilise Docker, demandez à votre support / hébergeur d'activer Docker sur le nouveau VPS avant la migration (templates kernel, modules nécessaires). Sinon les conteneurs ne démarreront pas après reboot.

Bases de données

Pour MySQL, PostgreSQL ou MongoDB, la copie à chaud avec rsync peut produire des fichiers incohérents. Bonnes pratiques :

• Faire un dump propre avant migration (mysqldump, pg_dump) et le restaurer après.

• Ou arrêter le service le temps du dernier rsync (mode "delta final").

Stratégie de bascule (cutover)

Pour minimiser le downtime sur un service en production :

1. Lancez un premier rsync pendant que l'ancien serveur tourne (le gros du transfert).

2. Coupez les services applicatifs sur l'ancien.

3. Faites un second rsync incrémentiel — il ne synchronise que les changements.

4. Basculez le DNS vers la nouvelle IP.

5. Rebootez le nouveau serveur.

Le second rsync est rapide car rsync compare les checksums et ne transfère que les blocs modifiés.

Conclusion

rsync est l'outil le plus simple et le plus robuste pour cloner un VPS Linux. Avec une bonne liste d'exclusions, une vérification de compatibilité préalable et une stratégie de cutover propre, on peut migrer une infrastructure complète en limitant la coupure à quelques minutes.

Chez RDG-NETWORK, nos VPS sont prêts à recevoir ce type de migration : Debian/Ubuntu à jour, accès root, SSH par clé, et un support qui peut activer Docker ou les modules noyau spécifiques sur demande avant transfert.