Liste de contrôle de migration d'hébergement avec tests et retour arrière
Planifiez un déménagement d'hébergement avec des copies de fichiers et de bases de données, des identifiants privés, des tests de destination, un basculement DNS et une fenêtre de retour arrière vérifiée.
Contenu révisé · Français
- Type de guide
- Déplacer et récupérer
- Exemples
- Illustratif, propre à l'environnement
- Portée de l'intégration
- Aucune machine distante connectée
Inventorier l'application complète
Enregistrez les fichiers web, les bases de données, les téléversements, les tâches planifiées, le courrier, les certificats, DNS, les intégrations tierces et les secrets. Vérifiez les versions d'exécution et les licences sur la destination. Une exportation d'image n'est utile que si la destination prend en charge son format et sa mise en réseau.
Faites la première copie avant de modifier DNS
Utilisez un transport privé et un répertoire de destination que vous contrôlez. L'exemple copie le contenu plutôt que d'imbriquer le dossier source, et commence par une simulation. Il omet délibérément une option de suppression. Vérifiez la propriété et les permissions sur la destination.
rsync -avzn -e "ssh -p 22" /srv/site/ operator@192.0.2.40:/srv/site/
# After reviewing the dry run and destination:
rsync -avz -e "ssh -p 22" /srv/site/ operator@192.0.2.40:/srv/site/Exporter la base de données avec sa méthode native
La copie des fichiers d’une base de données en cours d’exécution ne remplace pas une exportation de base de données cohérente avec l’application. L’approche à transaction unique de MySQL convient aux tables transactionnelles et nécessite toujours de la prudence lors de modifications de schéma ou avec des tables non transactionnelles. Utilisez une destination protégée pour l’exportation et demandez le mot de passe plutôt que de l’intégrer dans un argument.
mysqldump --single-transaction --routines --triggers --events \
-u app_user -p app_database > /private-backup/app-database.sqlLe chemin de sortie est illustratif et doit être privé, accessible en écriture et en dehors de la racine web. Pour PostgreSQL, utilisez plutôt son flux de travail pg_dump / pg_restore.
Testez la destination avant le basculement
Utilisez un nom d'hôte temporaire ou une substitution DNS locale contrôlée. Testez la connexion, les écritures, les téléversements, les tâches en arrière-plan, les messages sortants et HTTPS. Copiez les secrets via un canal privé et évitez d'exécuter les tâches planifiées des deux côtés contre le même service externe.
Faites une copie finale cohérente et déplacez la route
Réduisez le TTL à l'avance, mettez en pause les écritures si nécessaire, exportez les dernières modifications et terminez la synchronisation finale des fichiers. Mettez à jour DNS uniquement après la réussite des vérifications de destination. Conservez l'ancien hôte et une sauvegarde indépendante pendant la fenêtre de rollback ; les caches DNS peuvent continuer à envoyer certains visiteurs vers l'origine précédente.
Retirez l'ancien service seulement après acceptation
Surveillez les erreurs et comparez les enregistrements critiques après le déplacement. Réconciliez les écritures qui ont atteint l’ancienne origine. Confirmez le courrier et les rappels externes, puis fermez l’ancien service conformément à ses règles de facturation et de conservation des données. Aucune migration sans interruption ni automatique n’est revendiquée.
Partez avec un résultat vérifiable.
- Inventoriez les fichiers, la base de données, l'environnement d'exécution, les tâches planifiées, le courrier, DNS et les dépendances d'intégration.
- Gardez les exports, les identifiants et les clés de récupération en dehors de la racine web publique.
- Testez la connexion, les écritures, les téléversements, HTTPS et les tâches en arrière-plan sur la destination.
- Suspendez ou réconciliez les écritures pendant la copie finale, puis changez DNS.
- Accepter la demande et rétablir les contrôles avant de retirer l'ancien service.
Questions, réponses.
Changer de DNS copie-t-il mon site web ?
Non. DNS modifie l'acheminement des visiteurs ; il ne transfère pas de fichiers, bases de données, boîtes aux lettres, tâches planifiées ou identifiants. Testez la destination complète avant de déplacer la route.
Les deux hôtes peuvent-ils continuer à accepter des écritures pendant un déplacement ?
Uniquement avec une conception délibérée de synchronisation et de réconciliation. Sinon, utilisez une fenêtre de maintenance appropriée pour la copie finale cohérente. Les caches DNS peuvent encore envoyer des requêtes à l’origine précédente après un changement.
La migration est-elle effectuée automatiquement par OmbraHost ?
Aucune migration ni connexion à un fournisseur distant ne s’exécute dans l’application. Les options de migration préparées nécessitent un périmètre confirmé, un accès, un basculement et un plan de retour arrière avant que tout travail réel soit proposé.