Migrer vers un nouveau VPS sans interruption : bascule, DNS et retour en arrière

La copie est la partie facile — ce qui cause vraiment l'interruption

Demandez à quelqu'un combien de temps prendra sa migration, il estimera le transfert. Deux cents gigaoctets sur une liaison gigabit, disons quarante minutes, ajoutez une heure de marge. Ce chiffre est généralement juste, et ce n'est presque jamais le chiffre qui compte, parce que le transfert a lieu pendant que l'ancien serveur répond encore aux requêtes. Personne n'est indisponible pendant la copie. L'indisponibilité survient pendant l'intervalle entre la nouvelle machine est correcte et Internet est d'accord, et la durée de cet intervalle est fixée par des caches que vous ne contrôlez pas.

Quatre modes de défaillance expliquent la plupart des vraies pannes de migration, et la bande passante n'en fait partie d'aucun. Un enregistrement DNS dont la durée de vie était encore d'un jour quand vous l'avez modifié, si bien qu'une part non négligeable du monde continue de se connecter à une machine que vous avez déjà éteinte. Une base de données qui a accepté des écritures après la prise du dump, si bien que le nouvel hôte commence sa vie avec une copie discrètement obsolète, et vous découvrez quelles vingt minutes manquent à l'occasion d'une réclamation client. Un certificat TLS et sa clé de compte ACME qui n'existaient que sur l'ancien disque, si bien que le nouvel hôte présente à chaque navigateur un nom qui ne correspond pas. Et une intégration sortante — un prestataire de paiement, un point de dépôt SFTP bancaire, une API partenaire, une base de données chez un tiers — mise sur liste blanche par adresse IP, qui échoue silencieusement, au pire moment possible, loin du changement qui en est la cause.

Autant être direct sur l'expression que tout le monde emploie. « Migration zéro interruption » signifie presque toujours quelques secondes de connexions refusées que personne n'a remarquées, et c'est un objectif tout à fait valable à viser. Un zéro véritable exige que les deux machines servent correctement en même temps, ce qui exige une application qui tolère d'être deux machines à la fois : aucun état de session local, aucun répertoire d'upload local que seul un côté possède, et une base de données qui soit se réplique, soit vit ailleurs entièrement. La plupart des architectures auto-hébergées n'atteignent pas cette barre, et le plan honnête est un gel court, maîtrisé et répété, plutôt qu'un projet d'architecture que vous n'aviez pas l'intention de lancer.

La forme d'une bonne migration n'a donc rien de malin. Construisez la nouvelle machine tôt et prouvez qu'elle fonctionne pendant que l'ancienne porte la charge. Réduisez la partie irréversible à quelques minutes de commandes scriptées. Changez une seule chose à la fois. Et gardez la possibilité de revenir en arrière, avec une date à partir de laquelle vous arrêtez d'en payer le prix.

Inventaire : les parties d'un serveur qui ne sont pas dans votre dépôt

Votre dépôt de déploiement décrit l'application. Il ne décrit pas la machine. Quelque part entre le premier apt install et aujourd'hui, un serveur accumule une couche qu'aucun contrôle de version n'a jamais vue : des paquets installés à la main pour corriger un problème, une unité systemd que quelqu'un a écrite dans l'urgence, une tâche cron sous un compte de service, des règles de pare-feu, un réglage sysctl, une locale, un fuseau horaire, un fichier swap, des certificats TLS, des clés d'hôte SSH, des rôles et privilèges de base de données, et un répertoire de médias qui n'est pas dans le dépôt précisément parce que ce sont les utilisateurs qui l'y ont mis. Migrer signifie reproduire cette couche délibérément, et la seule façon de le faire délibérément est de commencer par tout noter.

Cinq commandes en couvrent l'essentiel. dpkg --get-selections sur Debian et Ubuntu, ou dnf repoquery --userinstalled sur Rocky et Alma, vous donne le jeu de paquets. systemctl list-unit-files --state=enabled vous donne tout ce qui est configuré pour démarrer au boot, ce qui est une meilleure question que « qu'est-ce qui tourne » car cela inclut ce qui est actuellement planté. crontab -l -u pour chaque compte dans /etc/passwd, plus le contenu de /etc/cron.d et de chaque unité .timer, vous donne le travail planifié. nft list ruleset ou ufw status numbered vous donne le pare-feu. Et ss -tulpn vous donne ce qui écoute réellement, ce qui permet de découvrir le service que vous aviez oublié. Écrivez ces cinq résultats dans des fichiers et copiez-les hors de la machine, pas dessus.

Vient ensuite l'inventaire que personne ne note, celui qui mord des semaines plus tard : tout, où que ce soit, qui fait confiance à votre adresse IP actuelle. Des passerelles de paiement avec des listes blanches IP. Une base de données gérée chez un autre fournisseur dont les règles d'accès nomment l'ancienne adresse. Un relais SMTP qui authentifie par le réseau. Un service de supervision, un émetteur de webhooks qui ne publie qu'à des adresses connues, le pare-feu d'un collègue. Recherchez l'ancienne adresse dans votre propre configuration et documentation avec grep, puis vérifiez le panneau de contrôle de chaque service tiers que vous payez. Ces intégrations cassent après la bascule, de façon asynchrone, au moment où elles s'exécutent ensuite — ce qui explique pourquoi on diagnostique si souvent cela comme « autre chose s'est mal passé au même moment ».

Enfin, capturez la zone DNS elle-même. Exportez-la, ou au minimum notez chaque type d'enregistrement, sa valeur et son TTL, parce qu'une migration est exactement le moment où quelqu'un remarque un enregistrement faux depuis deux ans et le corrige serviablement au milieu de tout le reste.

Abaissez d'abord le TTL DNS — et comprenez pourquoi il faut le faire des jours à l'avance

Un résolveur récursif met en cache une réponse pour la durée de vie qui lui a été indiquée, et rien ne l'oblige à redemander avant son expiration. Cela a une conséquence qui piège presque tout le monde la première fois : abaisser le TTL d'un enregistrement de 86400 à 300 ne change strictement rien pour un résolveur qui a mis l'ancienne réponse en cache dix minutes plus tôt. Ce résolveur conserve la réponse valable une journée pendant encore vingt-trois heures et cinquante minutes, et n'apprend l'existence de votre nouveau TTL de cinq minutes qu'à ce moment-là. Le TTL bas doit donc être publié au moins un TTL complet de l'ancienne valeur avant que vous comptiez déplacer quoi que ce soit. Si vos enregistrements sont sur un TTL d'un jour, la première action de la migration a lieu deux jours avant la bascule, et c'est un changement d'une seule ligne.

Faites-le pour chaque enregistrement qui pointe vers la machine, pas seulement celui que vous avez en tête. L'enregistrement A et l'enregistrement AAAA — une adresse IPv6 laissée pointée vers l'ancien hôte est un bug magnifiquement déroutant, parce que les clients dual-stack la préféreront silencieusement et que seule une partie de vos utilisateurs sera affectée. Les enregistrements MX. Tout CNAME devant eux, en gardant à l'esprit qu'un client qui suit une chaîne est soumis au TTL de chacun de ses maillons, si bien qu'un enregistrement A à cinq minutes derrière un CNAME à un jour reste, dans les faits, à un jour. Et si vous changez aussi de fournisseur DNS, ne le faites pas la même semaine : la délégation de serveurs de noms et les enregistrements glue sont mis en cache par la zone parente selon son propre calendrier, et combiner les deux changements signifie que, si quelque chose casse, vous ne saurez pas lequel des deux en est la cause.

Vérifiez plutôt que de supposer. dig +noall +answer example.com A vous montre ce qu'un résolveur détient actuellement et le compte à rebours qu'il lui reste ; interroger directement votre serveur faisant autorité avec dig @ns1.example.net example.com A montre ce que vous avez réellement publié. Si les deux ne concordent pas, c'est le cache que vous regardez, et le nombre à côté de l'enregistrement est exactement le temps qu'il vous reste à attendre.

Deux nuances méritent d'être budgétées. Certains résolveurs plafonnent : une fraction des forwarders de FAI et d'entreprise imposent un TTL minimal quel que soit ce que vous publiez, ce qui est techniquement déconseillé mais bien réel. Et selon la RFC 8767, un résolveur peut délibérément servir une réponse périmée quand il ne peut pas joindre vos serveurs faisant autorité — excellent comportement pour la résilience, gênant le jour où vous voulez qu'un changement se propage. Entre les deux, prévoyez une longue traîne mesurée en heures, parfois en un jour, une fois l'essentiel du trafic déplacé. Cette traîne n'est pas un problème tant que l'ancienne machine continue de répondre correctement, ce qui est précisément pourquoi elle reste allumée. La RFC 2181 est la référence sur la façon dont les TTL sont censés se comporter quand les implémentations divergent.

Répétez sur la nouvelle machine pendant que l'ancienne sert encore

L'habitude la plus rentable de tout ce processus, c'est que la nouvelle machine existe et fonctionne des jours avant que cela ne compte vraiment. Un VPS est, en pratique, une location à l'heure : sur nos offres, un serveur est en ligne environ soixante secondes après la confirmation du paiement, il n'y a ni frais de mise en service ni contrat, donc une répétition de trois jours sur une offre à $8.50 coûte environ un dollar. C'est un moyen remarquablement bon marché de transformer chaque inconnue de votre migration en certitude avant que l'horloge ne tourne.

Testez-la par nom d'hôte, pas par IP. Naviguer vers l'adresse du nouveau serveur vous donne l'hôte virtuel par défaut, aucune correspondance SNI, un avertissement de certificat et un jeu de routes qui peut ne ressembler en rien à la production — et cela vous convaincra volontiers que quelque chose fonctionne alors que ce n'est pas le cas. Le bon outil est un contournement de résolveur. curl --resolve épingle un nom d'hôte à une adresse pour une seule commande, si bien que curl --resolve example.com:443:203.0.113.10 https://example.com/ sollicite le vrai nom, la vraie négociation TLS et le vrai hôte virtuel sur la nouvelle machine, pendant que le reste du monde continue de joindre l'ancienne. Pour des tests interactifs, une ligne dans le fichier hosts de votre poste de travail fait le même travail pour un navigateur.

Ce que la répétition détecte de façon fiable, c'est la couche non documentée accumulée dont parlait la section précédente. Un démon qui tourne depuis avant le dernier redémarrage et qui n'est en réalité pas activé. Une tâche cron qui dépend d'un transport mail local pour signaler ses échecs. Une propriété de fichiers qui a survécu à la copie sous forme de nombres, mais qui signifie autre chose sur une machine dont le /etc/passwd est différent. Une adresse codée en dur dans un fichier de configuration. Une base de données créée avec un jeu de caractères sur une version dont le défaut était différent. Une version mineure de Python ou de PHP qui a déprécié quelque chose que vous utilisez. Chacun de ces cas coûte dix minutes à corriger pendant une répétition, et une heure à diagnostiquer pendant la bascule.

Un test vaut plus que tous les autres : construisez la nouvelle machine deux fois. Reconstruisez-la de zéro en n'utilisant que votre inventaire et votre sauvegarde, sans regarder l'ancien serveur. Si elle redémarre correctement la seconde fois, votre inventaire est réel et votre runbook est exécutable. Sinon, vous venez de trouver la lacune dans une situation où la trouver ne coûte rien. Prenez un instantané une fois qu'elle est correcte — les instantanés horaires avec sept jours de rétention sont inclus sur chaque offre, et une restauration prend environ trente secondes — afin que toute expérience ultérieure sur la nouvelle machine soit, elle aussi, réversible.

rsync deux fois : une longue passe pendant que ça tourne, une courte dans la fenêtre

C'est le motif en deux passes qui garde la fenêtre de maintenance courte. La première passe s'exécute avec le service pleinement en ligne et peut prendre le temps qu'il faut — des heures, toute la nuit, sur tout un week-end. La seconde passe s'exécute pendant le gel et ne transfère que ce qui a changé depuis la première, ce qui, sur une charge normale, représente une petite fraction des données et un nombre de minutes prévisible. Vous échangez une longue copie sans surveillance contre une courte copie surveillée, et cet échange en vaut presque toujours la peine.

Les options comptent plus qu'on ne le pense. rsync -aHAX --numeric-ids est la base : -a pour le mode archive, -H pour préserver les hardlinks — ce qui compte énormément pour les stores Maildir et pour les arbres de sauvegarde dédupliqués, où les perdre peut multiplier votre usage disque — -A pour les ACL POSIX, -X pour les attributs étendus tels que les labels SELinux et les capabilities de fichiers, et --numeric-ids afin qu'un identifiant utilisateur soit copié comme un nombre plutôt que d'être résolu via la base d'utilisateurs de la source puis re-résolu via une base différente sur la destination. Ajoutez --info=progress2 pour une seule ligne de progression sensée, et --partial pour qu'un transfert interrompu reprenne au lieu de redémarrer. Laissez -z désactivé sauf si le lien est vraiment lent : compresser des médias déjà compressés et des archives chiffrées ne fait que déplacer le goulot d'étranglement vers le CPU.

N'utilisez --delete que sur la seconde passe. Sur la première, c'est se tirer une balle dans le pied sans aucun bénéfice, puisqu'il n'y a rien sur la destination qui ait besoin d'être supprimé. Sur la seconde, c'est indispensable : sans cette option, un fichier que vous avez supprimé sur l'ancien serveur entre les deux passes survit pour toujours sur le nouveau, et c'est ainsi qu'une migration finit par servir un contenu qui avait été délibérément retiré.

Ce qu'il ne faut pas faire, c'est lancer un rsync de tout le système de fichiers racine. C'est un raccourci populaire, et il produit une machine sur laquelle personne ne peut raisonner. Même en excluant /proc, /sys, /dev, /run et /tmp, vous vous retrouvez avec un système dont le noyau et l'initramfs viennent d'un hôte, dont le nommage des interfaces réseau a été dérivé d'un matériel différent, dont /etc/machine-id est désormais dupliqué sur deux machines vivantes, et dont vous venez de payer pour préserver cinq années accumulées de dérive de configuration. Migrez les données et la configuration que vous avez inventoriées ; installez le système d'exploitation à neuf depuis un template. Cela prend une heure de plus, cela vous donne une base moderne et propre, et cela signifie que le nouveau serveur est une machine que vous comprenez, plutôt qu'une copie d'une machine que vous ne compreniez pas.

Vérifiez la copie plutôt que de faire confiance au code de sortie. Après les deux passes, relancez la même commande avec -n --checksum --itemize-changes : un dry run qui compare le contenu plutôt que les horodatages, et affiche une ligne par différence. Le silence est le résultat que vous voulez, et c'est une preuve bien plus forte qu'un du -s identique des deux côtés.

La base de données, c'est la partie où rsync ne peut rien pour vous

Copier au niveau fichier le répertoire d'une base de données en production vous donne une copie déchirée : certaines pages écrites, d'autres non, aucune garantie que l'ensemble forme une frontière de transaction cohérente. InnoDB peut très bien s'en remettre et sembler en bonne santé, ce qui est pire qu'un échec franc, parce que vous ne le découvrirez que le jour où la récupération ne fonctionnera pas. Il existe exactement deux stratégies honnêtes — prendre un dump transactionnellement cohérent, ou répliquer — et choisir entre les deux revient à choisir combien d'interruption vous achetez.

Pour la voie du dump sur MySQL et MariaDB, mysqldump --single-transaction --routines --triggers --events donne un instantané cohérent sans verrouiller tout le serveur, avec deux réserves à connaître : ce n'est cohérent que pour les tables transactionnelles, donc une seule table MyISAM héritée casse discrètement la garantie, et toute instruction DDL exécutée pendant le dump la casse également. Sur PostgreSQL, pg_dump -Fc traite chaque base de données, et pg_dumpall --globals-only traite la moitié qu'on oublie — les rôles, mots de passe, privilèges et tablespaces vivent au niveau du cluster, pas à l'intérieur d'une base de données unique, si bien qu'une restauration sans eux produit des données parfaites auxquelles l'application ne peut pas s'authentifier.

Le chiffre qui détermine votre fenêtre n'est pas la taille du dump, c'est dump plus transfert plus restauration plus reconstruction des index, et c'est généralement ce dernier poste qui est le plus lourd. Mesurez-le pendant la répétition sur le vrai jeu de données, plutôt que de l'estimer. Quelques gigaoctets, ce sont des minutes ; cent gigaoctets avec une indexation conséquente peuvent représenter des heures, et à ce stade, la voie du dump cesse d'être viable pour un service en production, et la réplication devient la réponse plutôt qu'une simple optimisation.

La voie de la réplication inverse le coût : vous faites le travail à l'avance, et la bascule devient triviale. Mettez en place une réplique sur le nouvel hôte plusieurs jours à l'avance — réplication basée sur GTID pour MySQL et MariaDB, pg_basebackup et un standby en streaming pour PostgreSQL, ou réplication logique si vous changez aussi de version majeure. Laissez-la rattraper son retard et rester à jour. La bascule devient alors : arrêter les écritures sur le primaire, attendre que la réplique signale un retard nul, la promouvoir, pointer l'application vers elle. Cela prend quelques secondes, et c'est la seule approche qui mérite honnêtement l'expression interruption quasi nulle.

N'oubliez pas l'état qui ne se trouve pas dans la base de données. Redis, Valkey et Memcached détiennent des sessions, des compteurs de limitation de débit et des files d'attente ; un index de recherche dans Elasticsearch, OpenSearch ou Meilisearch détient une copie dérivée de vos données. Pour chacun, décidez explicitement s'il faut le migrer ou le reconstruire. Une instance Redis qui détient des sessions mérite d'être déplacée avec un BGSAVE et une copie du fichier résultant, à moins que vous n'acceptiez de déconnecter tout le monde. Un index de recherche est presque toujours plus rapide à réindexer sur le nouvel hôte qu'à transférer — mais la réindexation prend du temps, alors démarrez-la pendant la répétition, pas pendant le gel.

Certificats TLS, clés d'hôte SSH et les identités qu'on ne peut pas simplement réémettre

L'émission de certificats a un problème de l'œuf et de la poule au pire moment possible. Le challenge HTTP-01 prouve le contrôle d'un nom en récupérant un fichier via ce nom, ce qui exige que le nom résolve déjà vers la machine en cours de validation — et avant la bascule, ce n'est pas le cas. Il existe trois issues, et vous devez en choisir une délibérément. Copier le répertoire de certificats tel quel, ce qui fonctionne immédiatement et est entièrement légitime puisque c'est votre clé. Utiliser plutôt le challenge DNS-01, qui valide en publiant un enregistrement TXT et fonctionne donc sur une machine vers laquelle rien ne pointe encore, et qui est de toute façon la seule option pour un certificat wildcard. Ou accepter une courte fenêtre après la bascule DNS pendant laquelle le nouvel hôte demande son propre certificat, ce qui convient pour un site personnel mais pas pour quoi que ce soit avec des utilisateurs.

Si vous copiez, copiez tout. Les certificats et les clés privées sont la partie évidente ; la clé de compte ACME est la partie qu'on laisse derrière soi, et sans elle, le client sur le nouvel hôte enregistre un compte flambant neuf dès le premier renouvellement. Tout semble fonctionner, et vous avez silencieusement perdu l'historique du compte et tout état propre à ce compte. Préservez aussi la propriété et les permissions — les clés privées en 600, le répertoire d'archive en 700 — parce qu'une copie qui élargit les permissions d'une clé est un résultat pire que la migration dont vous vous inquiétiez.

Ne prévoyez pas de réémettre à répétition pour voir ce qui se passe. Les limites de débit de Let's Encrypt plafonnent les certificats en double pour un même jeu de noms d'hôte par semaine, et deux répétitions ratées plus une émission réelle sont un moyen étonnamment facile d'atteindre ce plafond le jour précis où vous ne pouvez pas vous permettre d'attendre. Pointez vos répétitions vers l'environnement de staging ; réservez l'endpoint de production pour l'opération réelle.

Les clés d'hôte SSH sont l'autre identité en jeu, et ici, la bonne réponse dépend vraiment de la raison de votre déménagement. Copier /etc/ssh/ssh_host_* rend la migration invisible : le known_hosts de chaque client correspond toujours, et aucune automatisation ne s'arrête sur un avertissement d'empreinte. C'est pratique, et c'est le bon choix pour un déplacement de routine entre fournisseurs en qui vous avez confiance. C'est le mauvais choix si la raison de votre départ est que vous ne faites plus confiance à l'ancien hôte ou à l'ancien fournisseur — quiconque a eu accès à ce disque a eu votre clé privée d'hôte, et l'emporter vers le nouveau serveur emporte le problème avec elle. Dans ce cas, générez des clés neuves, publiez la nouvelle empreinte via un canal qui n'est pas le serveur, et faites exécuter à vos clients ssh-keygen -R contre l'ancienne entrée. Consultez le manuel sshd d'OpenSSH pour savoir où vivent les clés et comment elles sont sélectionnées.

Une règle est absolue dans les deux cas : ne faites jamais tourner les deux machines simultanément avec la même clé d'hôte et le même nom d'hôte résolvant vers les deux. C'est une configuration dans laquelle un client ne peut pas savoir quel serveur il a réellement atteint, ce qui est précisément la propriété que les clés d'hôte existent pour empêcher. Pendant la fenêtre de recouvrement, soit l'ancien hôte garde son identité et le nouveau a la sienne propre, soit le nom de l'ancien hôte est retiré au moment précis où le nouveau adopte sa clé.

La bascule : les dix minutes qui exigent un ordre écrit

Jusqu'ici, tout était réversible et sans urgence. La bascule n'est ni l'un ni l'autre, ce qui est tout l'argument pour la rédiger à l'avance : c'est l'improvisation sous pression temporelle qui transforme une fenêtre de cinq minutes en incident de deux heures. Le runbook doit être des commandes littérales, dans l'ordre, avec la sortie attendue à côté de chacune, de sorte que l'exécuter exige de lire plutôt que de réfléchir.

L'ordre qui fonctionne. D'abord, arrêtez les écritures sur l'ancien hôte — une page de maintenance, un drapeau lecture seule, ou simplement l'arrêt de l'application pendant que le serveur web continue de répondre avec une page d'attente. Ensuite, lancez la passe rsync finale avec --delete. Puis, terminez l'étape base de données : soit le dump-transfert-restauration que vous avez mesuré, soit l'arrêt des écritures sur le primaire, la confirmation d'un retard de réplication nul, et la promotion de la réplique. Quatrièmement, démarrez les services sur le nouvel hôte et laissez-leur un moment pour se stabiliser — les pools de connexions, les workers de file d'attente et le chargement des certificats prennent tous plus de temps qu'on ne s'en souvient lors d'un démarrage à froid. Cinquièmement, vérifiez. Sixièmement, et seulement après que la vérification a réussi, changez les enregistrements DNS. Septièmement, laissez tourner l'ancien hôte.

La vérification doit vouloir dire quelque chose. Récupérer la page d'accueil prouve que le serveur web est en ligne, et rien d'autre. Utilisez curl --resolve contre le vrai nom d'hôte, sur une route qui touche la base de données et renvoie quelque chose que vous pouvez vérifier par assertion — un endpoint de santé qui contrôle la connectivité à la base de données, la connectivité au cache et l'espace disque libre mérite d'être écrit rien que pour cette raison. Lisez ensuite le journal d'accès du nouvel hôte et confirmez que votre requête s'y trouve. Cette dernière étape paraît pointilleuse, et c'est elle qui détecte le cas où votre contournement de résolveur n'a pas pris effet et où vous venez de soigneusement vérifier l'ancien serveur.

Après la bascule DNS, surveillez les deux journaux d'accès côte à côte. Le trafic sur le nouvel hôte grimpe ; le trafic sur l'ancien hôte décroît à mesure que les caches expirent, et cette courbe de décroissance est la seule mesure honnête de la longueur réelle de la traîne. Quand le journal de l'ancien hôte s'aplatit près de zéro, la migration est terminée. Jusque-là, l'ancienne machine doit continuer à se comporter correctement pour les utilisateurs qui l'atteignent encore — c'est pourquoi elle reste allumée et en lecture seule plutôt que d'être éteinte dans un élan d'enthousiasme. Si l'application ne peut pas être mise en lecture seule, l'ancien hôte servant des données périmées pendant quelques heures représente généralement un moindre mal que l'ancien hôte renvoyant une connexion refusée — mais c'est un jugement à porter à l'avance, pas sur le moment.

Changez une seule chose. Pas la version majeure du système d'exploitation en même temps que l'hôte. Pas le fournisseur DNS en même temps que les enregistrements. Pas la version de PHP en même temps que la machine. Chaque changement simultané multiplie les hypothèses que vous devrez tester quand quelque chose se comportera mal à trois heures du matin, et la mise à jour que vous étiez tenté de glisser dans le lot sera toujours là la semaine prochaine, sur une machine vers laquelle vous pouvez désormais revenir en arrière.

Mail, rDNS et la réputation qui ne voyage pas avec vous

Si le serveur envoie du mail, la migration a une seconde moitié qui n'a rien à voir avec la migration elle-même. Une adresse IP porte une réputation d'envoi, cette réputation se construit sur des semaines, et elle ne vous suit pas. C'est la façon la plus courante dont une migration techniquement irréprochable produit une semaine de réclamations d'utilisateurs, et toutes les mesures d'atténuation doivent commencer avant la bascule, pas après.

Le premier enregistrement à casser est le SPF. Une politique contenant un mécanisme ip4: nommant l'ancienne adresse commence à échouer dès l'instant où vous envoyez depuis la nouvelle, et comme les politiques RFC 7208 sont des enregistrements DNS, elles ont leur propre TTL à prendre en compte. Ajoutez la nouvelle adresse au SPF avant la bascule, gardez les deux listées pendant le recouvrement, et retirez l'ancienne au moment du décommissionnement. Le DKIM voyage sans problème tant que vous copiez la clé privée avec le reste de la configuration, puisque la moitié publique est déjà publiée. Le DMARC n'exige aucun changement, mais il vaut la peine de confirmer que l'adresse de reporting existe encore sur une machine sur le point d'être détruite.

Le DNS inverse n'est pas optionnel pour un hôte qui envoie du mail. L'enregistrement PTR sur la nouvelle adresse doit exister et doit correspondre au nom que le serveur annonce dans son HELO ou son EHLO, sans quoi une large part des destinataires rejettera sur ce seul critère. Sur nos offres, le PTR est modifiable depuis le panneau, donc c'est une case à cocher plutôt qu'un ticket — configurez-le pendant la répétition, vérifiez qu'il résout, et confirmez que l'enregistrement direct correspond en retour. Vérifiez ensuite la nouvelle adresse par rapport aux principales listes noires avant d'envoyer quoi que ce soit : des adresses recyclées arrivent parfois déjà répertoriées, et le découvrir via votre propre message de test ne coûte rien, alors que le découvrir via un client coûte cher. Spamhaus est celle qui compte le plus.

Pour la réception, gardez les deux hôtes joignables. Ajoutez le nouveau serveur comme MX de priorité 10 et laissez l'ancien en priorité 20 pendant une semaine plutôt que de le supprimer : les expéditeurs réessaient, certains ont mis votre enregistrement MX en cache, et un serveur mail qui accepte encore discrètement sur l'ancien hôte vaut bien mieux qu'un rejet. Ensuite, avant de détruire l'ancienne machine, videz et purgez sa file d'attente — postqueue -f pour forcer une tentative de livraison, et mailq pour confirmer que le résultat est vide. Les messages qui attendent dans une file sur un serveur que vous êtes sur le point de supprimer ne sont pas retardés. Ils sont perdus. Le guide du serveur mail auto-hébergé couvre en détail le volet délivrabilité.

Quand l'ancien fournisseur a déjà éteint la machine

Toutes les migrations ne sont pas planifiées. Une suspension après une plainte pour abus, une carte expirée, un compte verrouillé pour une raison que personne n'expliquera — le point commun, c'est que vous migrez désormais depuis une machine sur laquelle vous ne pouvez plus vous connecter, et le confortable ordre des opérations décrit plus haut ne s'applique plus. Cela vaut la peine de savoir à l'avance ce qui reste généralement possible, parce que la fenêtre pendant laquelle c'est possible est souvent courte.

Tant qu'une instance est suspendue mais pas encore supprimée, trois voies restent fréquemment ouvertes, par ordre décroissant d'utilité. Le panneau de contrôle peut encore proposer un instantané ou un téléchargement de sauvegarde, ce qui résout tout le problème en une seule étape. Un mode de secours ou de récupération peut encore démarrer une image live avec votre disque attaché, vous permettant de monter le système de fichiers et d'en extraire par le réseau ce qui compte. Et la console d'urgence peut encore s'attacher même quand le réseau est désactivé, ce qui suffit à lire des fichiers de configuration, récupérer une clé, ou noter ce qui était installé — mais ce n'est pas une voie possible pour une base de données, donc ne comptez pas dessus pour ça. Essayez-les dans cet ordre, et essayez-les immédiatement : la rétention après suspension est une politique, pas un droit, et elle se mesure souvent en jours.

Il existe une limite qu'aucun ticket de support ne résout, et cela vaut la peine de le dire clairement, parce que c'est une conséquence directe du modèle que ce site vend. Sur un hébergeur qui n'a jamais collecté d'identité — celui-ci y compris — il n'existe aucun moyen de prouver que vous êtes le titulaire du compte, en dehors de la possession des identifiants du compte. C'est tout l'intérêt de l'hébergement no-KYC, et c'en est aussi la facture : personne ne peut vous restaurer l'accès sur la foi d'une photo de passeport, parce qu'aucun passeport n'a jamais été rattaché à quoi que ce soit. Le guide sur l'hébergement no-KYC couvre ce compromis en détail ; la conséquence opérationnelle, c'est simplement que votre plan de récupération ne peut passer par la bonne volonté de personne d'autre.

La séquence d'urgence, c'est la séquence planifiée à laquelle on a retiré le recouvrement. Faites démarrer le nouvel hôte à partir de votre sauvegarde hors machine. Vérifiez-le correctement par nom d'hôte, parce que la tentation de sauter la vérification est la plus forte précisément quand vous êtes déjà en panne. Basculez ensuite le DNS immédiatement — la discipline du TTL s'applique toujours, sauf que vous payez désormais la traîne du cache sous forme de panne plutôt que de la dépenser sous forme de recouvrement, ce qui est l'argument le plus clair en faveur de TTL modestes en politique permanente plutôt qu'en étape de migration. Attendez-vous à un mail dégradé pendant un moment, et prévenez les gens tôt plutôt que de leur expliquer plus tard.

La leçon dépasse cette seule mauvaise journée. Une sauvegarde qui vit sur le serveur n'est pas une sauvegarde ; c'est une seconde copie de ce que vous êtes sur le point de perdre. Ce qui compte, c'est que la copie soit ailleurs, chiffrée avant de quitter la machine, en append-only pour qu'un hôte compromis ou suspendu ne puisse pas supprimer son propre historique, et — la partie que tout le monde saute — effectivement restaurée une fois, dans une instance jetable, pour que vous sachiez que la restauration fonctionne. La checklist de durcissement couvre la mise en place de tout cela sur une nouvelle machine ; si vous lisez cette section parce qu'il est déjà trop tard, mettez-la en place sur la machine vers laquelle vous migrez, aujourd'hui, avant toute autre chose.

Retour en arrière : définissez le déclencheur, et donnez-lui une date d'expiration

Presque tout le monde dit avoir un plan de retour en arrière, et presque personne n'a noté ce qui le déclencherait. Sans déclencheur, la décision se prend au pire moment, par la personne la plus fatiguée, et l'issue habituelle est que personne ne revient en arrière, parce qu'on a toujours l'impression que le problème actuel sera résolu dans cinq minutes. Décidez à l'avance : un taux d'erreur au-dessus d'un certain seuil pendant une certaine durée, une fonction précise cassée, ou simplement une heure fixée d'avance au-delà de laquelle vous arrêtez de déboguer et vous revenez en arrière.

La contrainte qui détermine ce que signifie vraiment un retour en arrière, ce sont les écritures. À partir du moment où le nouvel hôte accepte sa première écriture, revenir en arrière signifie soit abandonner ces écritures, soit les rejouer sur l'ancienne machine. Vous choisissez donc en réalité entre deux produits différents. Un retour en arrière effectué avant la première écriture est un changement DNS et prend quelques minutes. Un retour en arrière effectué après une journée de trafic de production est une migration en sens inverse, avec toutes les mêmes étapes, et prend aussi longtemps que ce que décrit ce guide. Sachez à tout moment lequel des deux vous avez sous la main, et notez que le second type est bien plus facile si vous avez gardé la base de données de l'ancienne machine capable de recevoir une restauration, plutôt que de réaffecter la machine à autre chose.

Gardez l'ancien serveur environ une semaine : allumé, en lecture seule, TTL DNS toujours bas, supervision toujours pointée dessus. Sur la plus petite offre, cette assurance coûte environ deux dollars, ce qui n'est pas un chiffre qui devrait entrer dans la décision. Ce qui devrait y entrer, c'est qu'une semaine est suffisamment longue pour que les tâches cron hebdomadaires, les rapports à peu près mensuels et l'intégration qui ne se déclenche que le vendredi aient chacun tourné au moins une fois sur le nouvel hôte — ce sont exactement les échecs qu'une fenêtre de deux jours manque entièrement.

Décommissionnez ensuite, délibérément. Confirmez que le journal d'accès de l'ancien hôte est resté plat pendant une journée entière. Prenez-en une dernière sauvegarde et gardez-la plus longtemps que vous ne pensez en avoir besoin. Révoquez tout ce qu'il détenait : clés API, clés de déploiement, utilisateurs de base de données, ses entrées dans les listes blanches IP d'autrui, ses contrôles de supervision, son entrée SPF, son enregistrement MX. Détruisez l'instance. Et enfin, remettez les TTL DNS à une valeur raisonnable — un TTL permanent de 300 secondes signifie que les résolveurs revalident vingt fois par heure pour le reste de la vie du site, ce qui ne vous rapporte plus rien une fois la migration terminée et coûte un peu de latence à chaque recherche à froid. Une heure est une valeur permanente raisonnable ; un jour convient pour des enregistrements que vous ne prévoyez jamais de changer rapidement.

La migration, dans l'ordre à suivre

Une semaine avant, inventoriez l'ancienne machine et rédigez le runbook : paquets, unités activées, crontabs, pare-feu, sockets en écoute, rôles de base de données, et chaque tiers ayant mis l'ancienne adresse sur liste blanche. Trois jours avant, provisionnez le nouveau VPS, restaurez dessus, et répétez l'ensemble par nom d'hôte avec un contournement de résolveur — puis reconstruisez-le une fois à partir du seul inventaire pour prouver que cet inventaire est réel. Deux jours avant, abaissez les TTL de A, AAAA et MX à 300, afin qu'un TTL complet de l'ancienne valeur s'écoule avant que vous n'ayez besoin qu'ils soient bas.

Un jour avant, lancez la première passe rsync avec -aHAX --numeric-ids pendant que la production continue, et montez la réplication de la base de données ou mesurez la fenêtre du dump sur le vrai jeu de données. Réglez les certificats dans la même passe — copiez le répertoire de certificats, clé de compte ACME comprise, ou basculez vers DNS-01 — et configurez l'enregistrement PTR et la nouvelle entrée SPF sur la nouvelle adresse avant que quoi que ce soit n'envoie du mail depuis elle.

Pendant la fenêtre : gelez les écritures, rsync final avec --delete, terminez la base de données, démarrez les services, vérifiez contre le vrai nom d'hôte sur une route qui touche la base de données, confirmez que la requête est arrivée dans le journal du nouvel hôte, et alors seulement basculez le DNS. Laissez l'ancien hôte allumé et en lecture seule. Surveillez les deux journaux d'accès jusqu'à ce que celui de l'ancien s'aplatisse.

Une semaine plus tard : confirmez que les tâches hebdomadaires ont tourné sur le nouvel hôte, prenez une dernière sauvegarde de l'ancien, révoquez ses clés et ses entrées sur liste blanche partout, détruisez-le, et remontez les TTL. Si vous voulez que la nouvelle machine soit meilleure que celle que vous avez quittée, et pas seulement plus récente, les quinze premières minutes de durcissement sont l'étape naturelle suivante, et c'est bien plus facile à faire sur un serveur qui n'a pas encore accumulé sa propre couche non documentée. Si vous hésitez encore sur votre destination, le guide du choix de juridiction couvre ce qui différencie vraiment l'Islande, les Pays-Bas, la Roumanie et la Suisse — et vous pouvez avoir la machine cible opérationnelle en une minute environ pour démarrer la répétition dès aujourd'hui.