Les recommandations de migration de Vultr insistent sur les tests avant la bascule DNS. Voici un parcours pour conserver la disponibilité pendant ce changement, sans supposer qu'une copie de fichiers synchronise aussi une base de données.
1. Préparer le nouveau serveur et le TTL
Inventoriez domaine, A et AAAA, versions du runtime, extensions, fichiers, base, tâches planifiées et stockage des sessions. Sauvegardez les données et conservez l'ancien VPS actif. Préparez sur le nouveau la même application, ses dépendances et son hôte virtuel.
Abaissez le TTL des enregistrements concernés, par exemple à 300 secondes si votre fournisseur l'autorise. Attendez au moins l'ancien TTL avant la bascule : sa diminution n'efface pas les réponses déjà en cache. Notez les anciennes valeurs DNS.
dig +noall +answer example.com Adig +noall +answer example.com AAAAChoisissez votre stratégie de données avant la copie :
- Site statique : suspendez les modifications de contenu jusqu'à la fin de la migration ; les visiteurs continuent à lire.
- Site dynamique : pour accepter des écritures en continu, les deux frontaux doivent utiliser un stockage cohérent commun, des sessions compatibles et des tâches non dupliquées. Préparez ce fonctionnement sur un réseau privé sécurisé.
- Si vous devez aussi déplacer une base locale, une réplication et sa bascule exigent une procédure propre au moteur. Sinon, prévoyez une pause des écritures avec export/import : ce n'est pas une migration totalement sans interruption.
2. Copier et tester sans changer le DNS public
Installez rsync sur les deux VPS. Les commandes suivantes partent de l'ancien : le compte local doit lire les fichiers, et deploy doit pouvoir écrire dans le dossier dédié /srv/site/ du nouveau serveur. Remplacez NEW_IP par son adresse et vérifiez sa clé SSH.
rsync -azn --itemize-changes /var/www/site/ \ deploy@NEW_IP:/srv/site/rsync -az /var/www/site/ deploy@NEW_IP:/srv/site/Le slash final copie le contenu du dossier. Configurez le nouveau serveur web pour lire cette destination, avec les propriétaires et permissions adaptés. Ne copiez pas le répertoire de données d'une base en fonctionnement.
Préparez un certificat valide pour le domaine sur la destination avant les tests HTTPS, par exemple avec un challenge DNS et un renouvellement automatisé.
Sur votre ordinateur, ajoutez temporairement au fichier hosts une ligne avec la nouvelle IP réelle :
203.0.113.20 example.comSous Linux/macOS : /etc/hosts. Sous Windows : C:\Windows\System32\drivers\etc\hosts, avec les droits administrateur. L'adresse ci-dessus est un exemple documentaire.
Testez HTTPS, pages, connexion, images et opérations métier. Pour un contrôle explicite qui évite les caches DNS :
curl --resolve example.com:443:203.0.113.20 \ -I https://example.com/N'utilisez pas -k : un certificat invalide doit faire échouer le test.
3. Synchroniser, basculer et observer
Après stabilisation des écritures selon votre stratégie, prévisualisez la synchronisation finale. --delete supprime les fichiers absents de la source : ne l'utilisez que sur cette destination dédiée et sauvegardée.
rsync -azn --delete --itemize-changes \ /var/www/site/ deploy@NEW_IP:/srv/site/rsync -az --delete \ /var/www/site/ deploy@NEW_IP:/srv/site/Modifiez A et, s'il existe, AAAA. Retirez la ligne hosts, contrôlez depuis un autre réseau, puis comparez erreurs et accès sur les deux VPS. Gardez l'ancien en service jusqu'à disparition du trafic résiduel observé ; 300 secondes ne garantissent pas une bascule universelle.
Erreurs courantes : AAAA oublié, cron exécuté deux fois, certificat non prêt ou retour DNS après divergence des données. Un retour aux anciennes IP n'est sûr que si l'ancien frontal peut encore servir les données actuelles. Après validation, remontez le TTL et retirez l'ancien serveur selon votre délai de conservation.
Sources : Vultr, préparation d'une migration, Vultr, test avant bascule.
Retrouvez-le dans nos publications
Les étapes clés de cet article, en carrousel. Suivez-nous pour découvrir les prochaines. Nos publications sont rédigées en anglais.