Migrer entre juridictions
Réponse
Migrez entre juridictions en provisionnant d'abord la cible, en synchronisant les données avec rsync ou un réplica de base de données, en abaissant le TTL DNS 48 heures à l'avance, en basculant pendant une période de faible trafic, et en vérifiant avant de détruire la source. Attendez-vous à des minutes d'arrêt, pas des heures.
Abaissez le TTL d'abord, et faites-le tôt
Quarante-huit heures avant le déménagement, réduisez vos enregistrements DNS à un TTL de 300 secondes. Les résolveurs mettent en cache de manière agressive et un enregistrement avec un TTL de 24 heures continuera d'envoyer du trafic vers l'ancienne adresse bien après votre migration.
C'est l'étape que tout le monde saute et regrette ensuite. Elle ne coûte rien et transforme une journée de retardataires en cinq minutes.
Synchronisez en deux passes
Effectuez un rsync complet pendant que la source est encore en ligne et active. Cela prend le temps nécessaire et rien n'est perturbé. Ensuite, arrêtez l'application, lancez un deuxième rsync qui transfère uniquement ce qui a changé depuis le premier, puis basculez. La deuxième passe ne dure généralement que quelques secondes.
Pour les bases de données, utilisez la réplication plutôt qu'une copie de fichiers : configurez le nouveau serveur comme réplica, laissez-le rattraper son retard, puis promouvez-le. Copier les fichiers d'une base de données depuis un serveur en production produit assez souvent une copie corrompue pour que le risque ne vaille pas la peine.
- T-48h — TTL DNS à 300 secondes
- T-2h — rsync complet, source encore en ligne
- T-30m — réplica de base de données à jour
- T-0 — arrêt de l'application, rsync final, promotion du réplica
- T+5m — DNS mis à jour, vérification depuis plusieurs réseaux
- T+72h — vérification, puis destruction de la source
À vérifier avant de tout détruire
Attendez au moins soixante-douze heures. Surveillez les journaux de l'ancien serveur pour tout trafic arrivant encore — cela vous indique quels résolveurs ou clients codés en dur n'ont pas encore basculé. Vérifiez que vos sauvegardes se restaurent depuis le nouvel emplacement, pas seulement qu'elles s'exécutent.
Vérifiez tout ce qui référençait l'ancienne adresse IP directement : les listes blanches de pare-feu sur des services tiers, les listes blanches API, les contrôles de supervision et tout enregistrement DNS que vous avez oublié. Il y en a toujours un.
Le cas particulier d'un changement de juridiction
Si la raison du déménagement est légale plutôt que technique, l'ancien disque compte. Demandez-nous de l'effacer plutôt que de simplement résilier le serveur — nous effectuons un écrasement multipasses sur demande et confirmons une fois terminé. Sur un volume chiffré, détruire l'en-tête LUKS est plus rapide et tout aussi efficace.
Vérifiez également tout ce qui code un pays en dur : les certificats TLS sont sans problème, mais les API tierces restreintes géographiquement, les intégrations de paiement et les attestations de conformité peuvent ne pas l'être. Mieux vaut le découvrir avant la bascule qu'après.
Questions fréquentes
01 Quelle durée d'indisponibilité dois-je prévoir ?
Quelques minutes, si vous réduisez le TTL 48 heures à l'avance et synchronisez en deux passes. Le rsync final sur un jeu de données déjà synchronisé ne prend généralement que quelques secondes ; la propagation DNS avec un TTL de 300 secondes prend cinq minutes.
02 Pouvez-vous migrer le serveur pour moi ?
Nous pouvons déplacer les images disque entre nos propres emplacements sur demande, ce qui évite toute re-synchronisation. La bascule au niveau de l'application vous revient, car vous seul savez quand elle est sûre.
03 Qu'advient-il de l'ancien disque ?
Les volumes résiliés sont effacés lors de la réallocation par défaut. Si le déménagement est motivé par des raisons légales, demandez un écrasement multipasses et nous confirmons quand il se termine. Sur les volumes LUKS, détruire l'en-tête est plus rapide et tout aussi définitif.
Liés