Liste de contrôle pour la migration VPS : sauvegardes, DNS, TLS et retour arrière
Une séquence de migration pratique pour une application auto-hébergée : inventaire, sauvegardes cohérentes, destination testée, écritures contrôlées, bascule DNS et chemin de restauration.
L’essentiel
Une migration VPS contrôlée recense les services et les données, crée une sauvegarde cohérente, vérifie une destination restaurée, teste le nom d'hôte et le routage TLS, coordonne les écritures finales et le DNS, et préserve un retour arrière tenant compte des données. Aucune liste de contrôle ne garantit à elle seule l'absence d'interruption.
Faites l'inventaire de l'application avant de la déplacer
Listez les services, versions, ports, tâches planifiées, bases de données, fichiers téléversés et configurations nécessaires au fonctionnement de l'application. Identifiez où se produisent les écritures et de quels services externes elle dépend. Un répertoire web copié ne constitue pas une migration complète lorsque les données se trouvent ailleurs.
Notez les noms DNS actuels, les enregistrements IPv4 actifs et les enregistrements IPv6, les méthodes de renouvellement des certificats et un chemin d'accès de récupération. Conservez les secrets dans vos outils de déploiement privés. Ne placez pas de mots de passe, de clés privées ou de vidages de base de données dans une racine de documents publique ou dans une liste de contrôle de migration partagée.
Créez une sauvegarde cohérente et prouvez qu'elle se restaure
Utilisez le mécanisme de sauvegarde pris en charge par la base de données plutôt que de copier des fichiers arbitraires pendant que les écritures se poursuivent. Pour SQLite, le Online Backup API crée un instantané cohérent de la base de données. En mode WAL, le fichier WAL participe à l'état persistant de la base de données, de sorte que la copie du seul fichier principal peut omettre des modifications validées.
Une sauvegarde de base de données cohérente n'est pas automatiquement cohérente avec des téléversements, des files d'attente ou des fichiers stockés séparément. Coordonnez leur capture avec votre application. Restaurez dans un emplacement de test séparé et vérifiez les enregistrements, les références de fichiers et le comportement de l'application avant de considérer la sauvegarde comme utilisable.
Préparez la destination avant de modifier DNS
Créez les utilisateurs, permissions, versions d'exécution, services et répertoires d'application prévus sur le nouveau serveur. Restaurez la sauvegarde de test dans son emplacement de données de destination, en dehors de la racine web publique lorsque c'est approprié. Vérifiez la propriété et l'accès à l'aide du compte de service qui exécutera réellement l'application.
Préservez les sites sans rapport sur un serveur partagé. Utilisez une racine de documents, un hôte virtuel et un environnement d'exécution dédiés, validez la configuration du serveur web et préparez un retour arrière qui ne restaure que les fichiers et la configuration concernés par ce changement.
Testez le nom d'hôte réel et le certificat sur le nouveau serveur
Une requête de navigateur vers une adresse IP nue ne reproduit ni le routage basé sur le nom d'hôte ni la validation du certificat. curl --resolve permet à un test d'utiliser le nom d'hôte prévu et une IP de destination choisie tout en conservant les vérifications normales du nom d'hôte et du TLS. Vérifiez aussi le statut HTTP et le contenu attendu de l'application. L'exemple utilise des valeurs réservées à la documentation ; remplacez-les par votre propre domaine et destination vérifiés.
Un certificat valide et un chemin réseau autorisé doivent déjà exister pour que ce test réussisse. Ne désactivez jamais la vérification du certificat pour déclarer la migration prête. La validation ACME basée sur DNS peut valider un domaine sans modifier l'adresse de son serveur web ; la validation basée sur HTTP a des exigences d'accessibilité différentes. Testez le renouvellement séparément de l'émission initiale.
curl --fail-with-body --show-error --resolve example.com:443:203.0.113.10 https://example.com/Choisissez un plan de contrôle des écritures et de synchronisation finale
Planifiez une courte période de maintenance ou un autre mécanisme de cohérence adapté à l'application. Arrêtez ou redirigez les écritures que vous avez identifiées, effectuez la sauvegarde finale cohérente de la base de données, synchronisez les fichiers modifiables correspondants et vérifiez le résultat. Les travailleurs de file d'attente, les webhooks et les tâches cron peuvent écrire même lorsque l'interface publique semble calme.
Faites un essai à blanc avant une synchronisation de fichiers. N'ajoutez pas d'options de suppression et ne copiez pas des répertoires système entiers comme raccourci. Gardez l'ancien service récupérable jusqu'à ce que vous ayez vérifié la nouvelle application et établi quel emplacement fait autorité pour les écritures.
Modifiez DNS, puis observez les deux familles d'adresses
Mettez à jour les enregistrements requis pour le service et tenez compte des caches de résolveurs existants. Vérifiez les réponses faisant autorité et plusieurs chemins clients normaux. Si un enregistrement AAAA obsolète reste actif, les clients IPv6 peuvent continuer d'atteindre l'ancien serveur tandis que les clients IPv4 atteignent le nouveau.
Testez la connexion, les lectures, les écritures, les téléversements, les tâches en arrière-plan et les rappels externes sur le nouveau service. Évitez d'exécuter deux copies inscriptibles indépendantes de la même application pendant la transition. Conservez une règle claire pour traiter le trafic qui atteint encore l'ancienne destination.
Faites du retour arrière une décision de données autant qu'une décision DNS
Définissez les conditions d'échec qui déclenchent un retour arrière et qui contrôle la bascule. Revenir sur DNS seul ne suffit pas après que de nouvelles écritures ont atteint la destination : vous devez préserver ou réconcilier ces données avant de revenir à une copie plus ancienne.
Conservez la source et les sauvegardes pendant une période de récupération appropriée. Supprimez les anciens accès et décommissionnez les ressources seulement après avoir vérifié la destination, les sauvegardes, le renouvellement et la surveillance. La conservation et la suppression doivent suivre la politique de service réelle, et non un nombre d'heures fixe générique.