Préparez et testez d'abord le nouveau serveur, copiez les données avec une méthode de cohérence prise en charge par l'application, définissez une fenêtre de basculement et conservez l'ancien environnement. Le retour arrière doit tenir compte des écritures acceptées sur le nouveau serveur, et pas seulement d'un changement DNS.
Inventoriez le service avant de déplacer la machine
Une migration comprend plus que les fichiers de l'application. Listez les bases de données, les fichiers téléversés, les tâches planifiées, les workers de file d'attente, les certificats, les domaines, les secrets et les intégrations sortantes. Consignez les versions logicielles et les hypothèses d'exploitation qui comptent, comme les permissions de fichiers et les chemins de stockage. Un nouveau serveur dédié peut révéler une dépendance oubliée qui avait été installée discrètement des années plus tôt sur l'ancien environnement.
Désignez un responsable de la décision de basculement et définissez ce que signifie la réussite. Incluez des contrôles visibles par l'utilisateur, la cohérence des données et la capacité à récupérer l'accès. Confirmez que la nouvelle configuration est livrée et utilisable avant d'annoncer une date de migration. Une confirmation de commande ou une spécification matérielle listée n'équivaut pas à une destination fonctionnelle prête à recevoir des données de production.
Construisez la destination comme un environnement séparé
Installez la pile requise, établissez l'administration et configurez le pare-feu prévu. Gardez les secrets privés et définissez délibérément les permissions des services. Vérifiez le nom d'hôte attendu par l'application et le comportement des certificats avant le déplacement du trafic public. La documentation des hôtes virtuels d'Apache illustre pourquoi le routage par nom d'hôte est une décision de configuration distincte de l'adresse du serveur. Une page par défaut fonctionnelle ne prouve pas que le bon hôte applicatif est configuré.
Utilisez un jeu de données restauré représentatif pour la répétition, avec les e-mails sortants, les paiements et les tâches planifiées désactivés ou redirigés vers des systèmes de test sûrs. Cela évite que l'environnement de test agisse sur de vrais utilisateurs. Exercez la connexion, les téléversements, le travail en arrière-plan et la restauration. Consignez la procédure et sa durée afin que la fenêtre réelle repose sur un processus observé plutôt que sur de l'optimisme.
Choisissez une frontière de données cohérente
Utilisez une méthode de sauvegarde ou de réplication prise en charge par la base de données et l'application. PostgreSQL distingue les dumps SQL, les sauvegardes de système de fichiers et l'archivage continu, chacun ayant ses propres hypothèses. Ses recommandations sur les dumps indiquent que les dumps de base de données peuvent être cohérents en interne, tandis que les rôles à l'échelle du cluster et d'autres détails nécessitent un traitement séparé. Lisez les exigences du système exact que vous exploitez plutôt que de copier des fichiers de données ouverts sans discernement.
Planifiez la relation entre la base de données, les téléversements et l'état de la file d'attente. Si un enregistrement pointe vers un fichier copié à un autre moment, l'application restaurée peut être incomplète même si les deux copies ont réussi individuellement. Décidez s'il faut suspendre brièvement les écritures, utiliser un dispositif de réplication testé ou effectuer un export spécifique à l'application. Gardez cette décision de cohérence explicite dans le runbook.
| Étape | Preuve requise | Décision |
|---|---|---|
| Répétition | L'application et les données restaurées passent les contrôles | La destination peut être envisagée pour le basculement |
| Synchronisation finale | Point de récupération cohérent défini | Poursuivre uniquement avec les changements restants compris |
| Bascule du trafic | Routage et comportement des certificats corrects | Surveiller les deux destinations |
| Retour arrière | Emplacement de toutes les écritures nouvellement acceptées | Réconcilier les données avant de rétablir le trafic |
Préparez le routage du trafic sans promettre de changements instantanés
Le temps de vie DNS contrôle la durée de mise en cache des enregistrements, comme expliqué dans la documentation DNS de Cloudflare. Examinez le TTL suffisamment tôt si DNS fait partie de la migration, et laissez les enregistrements déjà en cache expirer selon leur paramètre précédent. Modifier la valeur au moment du basculement ne peut pas raccourcir rétroactivement toutes les réponses mises en cache. Différents clients peuvent atteindre différentes destinations pendant la transition.
Gardez l'ancien environnement disponible pendant que les changements de routage se stabilisent, avec une politique délibérée sur sa capacité à accepter encore des écritures. Évitez d'exécuter des consommateurs de file d'attente ou des tâches planifiées en double, sauf si l'application est conçue pour cela. Surveillez les requêtes des deux côtés et confirmez le nom d'hôte prévu, le certificat TLS et la version de l'application depuis des clients indépendants.
Définissez le retour arrière après le début des écritures
Avant que le nouveau système accepte des changements, le rétablissement du trafic peut être relativement simple. Ensuite, une simple inversion DNS peut perdre du travail ou créer deux historiques contradictoires. Définissez comment les enregistrements et les téléversements nouvellement créés seraient préservés ou réconciliés. Si l'application ne peut pas les fusionner en toute sécurité, une période de maintenance contrôlée peut être préférable à un retour improvisé vers l'ancienne copie.
Définissez les conditions qui exigent de suspendre la migration, et gardez le responsable de la décision joignable. Conservez les journaux et les preuves utiles selon les règles de conservation du projet. Ne supprimez pas l'ancienne machine ni sa copie de récupération indépendante simplement parce que la page d'accueil s'est chargée une fois. La période de conservation doit couvrir les besoins convenus de vérification et de retour arrière.
Clôturez la migration par des contrôles opérationnels
Après le basculement, vérifiez les sauvegardes, les alertes, le renouvellement des certificats, le travail planifié et la récupération des accès. Confirmez que l'hôte surveillé est la nouvelle destination et qu'aucune intégration de test ne subsiste en production. Examinez les erreurs applicatives et les temps visibles par l'utilisateur sous trafic ordinaire. Mettez à jour l'inventaire et le runbook afin que le prochain administrateur n'ait pas à déduire ce qui a changé.
Les familles dédiées de SwissOctet offrent différentes configurations physiques, mais le travail de migration et l'assistance gérée doivent être confirmés pour le service choisi. Utilisez le catalogue pour sélectionner les ressources adaptées, puis construisez un déplacement testé autour des données de votre application. Une migration est terminée lorsque le service et son processus de récupération fonctionnent sur la destination, et pas simplement lorsque les fichiers ont été transférés.
Votre liste de contrôle pratique.
- Inventorier les données, les tâches, les secrets et les intégrations.
- Vérifier la destination livrée avant de planifier.
- Répéter avec des intégrations externes sûres.
- Définir la cohérence de la base de données et des téléversements.
- Planifier la transition de routage et la prévention des tâches en double.
- Spécifier le retour arrière pour les nouvelles écritures.
- Vérifier les sauvegardes et la surveillance après le basculement.
Les détails qui comptent.
Puis-je migrer en copiant le répertoire de l'application ?+
Uniquement si cela capture tout ce dont le service a besoin et préserve la cohérence. Les bases de données, les téléversements, les tâches, les secrets et la configuration nécessitent généralement une attention séparée.
Réduire le TTL DNS rend-il le basculement instantané ?+
Non. Les réponses déjà mises en cache peuvent subsister jusqu'à la fin de leur durée de vie antérieure, et les clients peuvent se mettre à jour à des moments différents.
Le retour arrière consiste-t-il simplement à pointer DNS vers l'ancien serveur ?+
Pas après que le nouveau serveur a accepté des écritures. Vous devez tenir compte de ces enregistrements et fichiers avant de rétablir le trafic.
Allez à la source.
Ces références soutiennent les concepts techniques de ce guide. Suivez la documentation actuelle avant de modifier un système de production.
- PostgreSQL : Sauvegarde et restauration www.postgresql.org
- PostgreSQL : Cohérence et restauration des dumps SQL www.postgresql.org
- Apache : Documentation sur les hôtes virtuels httpd.apache.org
- Cloudflare DNS : Time to Live developers.cloudflare.com
Conseils éditoriaux par SwissOctet. Les exemples sont illustratifs. Les spécifications de service, les options disponibles et les conditions contractuelles doivent être vérifiées séparément.