Déménager votre VPS chez un nouvel hébergeur sans interruption

Toutes les histoires d'horreur de migration ont le même milieu : quelqu'un a changé le DNS d'abord, puis a commencé à copier. L'interruption pendant un déménagement ne vient presque jamais d'une copie trop lente. Elle vient d'étapes faites dans le mauvais ordre.

Voici l'ordre qui marche, que vous quittiez un autre hébergeur ou que vous passiez d'une de nos offres à une autre.

1. Deux jours avant : baissez le TTL

Repérez les enregistrements DNS que vous allez modifier (en général A, AAAA et les CNAME qui pointent dessus) et baissez leur TTL à 300 secondes. Puis attendez au moins la durée de l'ancien TTL. Un enregistrement avec un TTL d'une journée signifie que certains résolveurs continueront à servir l'ancienne adresse un jour après le changement, et rien de ce que vous ferez sur le serveur n'y changera quoi que ce soit.

C'est l'étape que tout le monde saute, et c'est elle qui transforme une bascule de cinq minutes en une journée où la moitié des utilisateurs voient l'ancien serveur.

2. Faites l'inventaire de l'ancien serveur

Vous allez reconstruire cette machine ailleurs, alors notez ce qu'elle fait réellement. Pas ce dont vous vous souvenez. Ce qu'elle fait :

ss -tlnp                                # what is listening, and which process
crontab -l; ls /etc/cron.d              # scheduled jobs
systemctl list-timers --all             # the scheduled jobs people forget
systemctl list-units --type=service --state=running

Ajoutez à la liste : les certificats TLS et la façon dont ils se renouvellent, les fichiers d'environnement contenant des secrets, les règles de pare-feu, les utilisateurs et leurs clés SSH, la base de données et sa taille, et tout ce qui parle au serveur par son adresse IP. Ce dernier groupe est le plus sournois : la liste d'autorisation d'un partenaire, les réglages de webhook d'un prestataire de paiement, une sonde de supervision.

3. Montez le nouveau serveur à côté de l'ancien

Commandez le nouveau serveur et laissez l'ancien tranquille. Choisissez une offre dans la liste des VPS avec autant ou plus de disque que ce que vous utilisez vraiment, pas que ce qu'on vous a vendu. Si l'ancienne machine reçoit le moindre trafic entrant (un site, des webhooks, une API), la nouvelle a besoin de sa propre IPv4. Une offre NAT n'accepte les connexions entrantes que sur son port SSH, et ce qu'un seul port redirigé peut faire explique pourquoi c'est important.

Connectez-vous, installez les mêmes paquets, recréez les utilisateurs et le pare-feu. Le guide de connexion couvre les clés et la première connexion.

4. Synchronisez les fichiers deux fois

La première synchronisation copie tout pendant que l'ancien serveur continue de tourner. Elle peut prendre des heures ; ce n'est pas grave.

rsync -aHAX --numeric-ids --info=progress2 /var/www/ root@203.0.113.10:/var/www/

--numeric-ids conserve les propriétaires de fichiers par numéro, ce qui évite la surprise classique du « tout appartient au mauvais utilisateur » quand les deux systèmes ont créé leurs utilisateurs dans un ordre différent. Si vous n'avez jamais utilisé rsync via SSH, transférer des fichiers vers un VPS vous guide pas à pas.

La seconde synchronisation, juste avant la bascule, ne copie que ce qui a changé depuis la première. Elle prend en général quelques secondes.

5. Déménagez la base de données délibérément

Les fichiers, c'est facile. Une base qui reçoit des écritures est le seul endroit où « sans interruption » demande soit un petit compromis, soit plus de travail.

La voie simple : faire un dump et une restauration une fois pour tester, puis au moment de la bascule arrêter les écritures une minute (passer l'application en lecture seule ou l'arrêter), refaire un dump frais, le restaurer sur le nouveau serveur et y démarrer l'application. Pour la plupart des petits projets, c'est une pause d'une ou deux minutes, annoncée à l'avance.

La voie sans pause : mettre en place une réplication de l'ancienne base vers la nouvelle, la laisser rattraper son retard, puis promouvoir la nouvelle au moment de la bascule. Plus de mise en place, et ça vaut le coup quand même une minute d'écritures perdues est inacceptable.

6. Testez le nouveau serveur avant que quiconque le voie

Le DNS pointe toujours vers l'ancien serveur, vous pouvez donc tester le nouveau en privé. Envoyez une requête pour votre vrai domaine vers la nouvelle adresse :

curl --resolve example.com:443:203.0.113.10 https://example.com/health

Si le certificat n'est pas encore là, testez de la même façon en HTTP, ou ajoutez une ligne temporaire à votre fichier hosts et parcourez le site dans un navigateur. Vérifiez les connexions, les envois de fichiers, les tâches de fond et le mail sortant. C'est le moment le moins cher pour découvrir une extension PHP manquante.

7. Basculez, et gardez l'ancien serveur allumé

Faites la synchronisation finale des fichiers et l'étape de la base, puis modifiez les enregistrements DNS. Avec un TTL de 300 secondes, l'essentiel du trafic bascule en quelques minutes. Surveillez le journal d'accès de l'ancien serveur : il recevra encore un filet de requêtes de résolveurs et de clients qui ignorent le TTL. Laissez-le tourner, inchangé, quelques jours. Mettez ensuite à jour tout ce qui pointe vers l'ancienne IP : listes d'autorisation des partenaires, URL de webhooks et, pour le mail, le DNS inverse de la nouvelle adresse (sur nos offres avec IP dédiée, vous le définissez vous-même, voir DNS inverse) ainsi que votre enregistrement SPF.

Ce qui casse le plus souvent

À peu près dans l'ordre de fréquence où nous le voyons : un timer systemd que personne n'a listé, un fichier de config avec l'ancienne IP en dur, des fichiers appartenant au mauvais utilisateur, un pare-feu qui bloque le propre port de l'application, un certificat qui se renouvelle sur l'ancien serveur mais pas sur le nouveau, et des mails qui finissent en spam parce que la nouvelle adresse n'a pas encore de DNS inverse.

Là où cette checklist ne convient pas

Une base très sollicitée en écriture, sans aucune tolérance à la pause, a besoin d'une vraie réplication et d'une répétition générale, pas d'une checklist de blog. Les serveurs Windows déménagent avec d'autres outils que rsync. Et si le déménagement est en réalité une question de taille, lisez ceci d'abord : ici, les offres grandissent sur place. Passer à une offre plus grande du même type de réseau ajoute vCPU, RAM et disque en un redémarrage, sans aucune migration. Seule la réduction exige un nouveau serveur. Si vous déménagez parce que vous n'êtes pas sûr que la machine soit assez grosse, quand il vous faut vraiment 64 GB de RAM vous épargnera peut-être le voyage, et VPS, mutualisé, dédié ou cloud vous aidera si vous doutez qu'un VPS soit le bon toit.