Avant de commencer
Créez une sauvegarde complète datée et une copie indépendante. Arrêtez les écritures ou utilisez une sauvegarde cohérente avec l’application : copier un dossier actif ne garantit pas la cohérence SQL. Testez la restauration sur une destination isolée. Préservez l’original jusqu’à validation.
Choisir une stratégie de migration
La migration applicative reconstruit un système propre compatible et restaure logiciels et données utiles. La restauration d’une sauvegarde dépend de son format pris en charge. Une image système exige aussi architecture, firmware, disques, pilotes, démarrage et virtualisation compatibles. Un snapshot d’un autre prestataire ne fonctionne pas automatiquement sous KVM.
Relevez les versions exactes, le démarrage, le stockage réellement utilisé et les dépendances externes. Inventoriez comptes, permissions, tâches planifiées, bases, licences, certificats et services hors du dossier de fichiers. Vérifiez les possibilités d’export chez l’ancien prestataire avant toute résiliation.
- application restore
- supported backup restore
- system image compatibility
Inventorier sans modifier la source
Relevez système, architecture, paquets, applications, montages, espace utilisé, utilisateurs et UID/GID, permissions, ACL et attributs étendus. Listez services activés, timers, cron, bases et certificats. Les exemples sont des lectures d’inventaire : aucun ne réalise une migration. Une commande peut être absente d’une installation minimale.
Créez une sauvegarde complète datée et une copie indépendante. Arrêtez les écritures ou utilisez une sauvegarde cohérente avec l’application : copier un dossier actif ne garantit pas la cohérence SQL. Testez la restauration sur une destination isolée. Préservez l’original jusqu’à validation.
- systemd services / timers
- cron / users / UID / GID
- mounts / ACL / xattrs
Inventaire en lecture seule
cat /etc/os-release
uname -mCette page n’a effectué aucune migration, vérification de sauvegarde ou validation de compatibilité. Conservez la source et une récupération testée. Aucune garantie de zéro interruption, d’IP conservée, de licence transférable ou de restauration sans perte n’est donnée.
Inventaire en lecture seule
df -hT
lsblk -fCette page n’a effectué aucune migration, vérification de sauvegarde ou validation de compatibilité. Conservez la source et une récupération testée. Aucune garantie de zéro interruption, d’IP conservée, de licence transférable ou de restauration sans perte n’est donnée.
Inventaire en lecture seule
systemctl list-unit-files --state=enabled
systemctl list-timers --all
crontab -lCette page n’a effectué aucune migration, vérification de sauvegarde ou validation de compatibilité. Conservez la source et une récupération testée. Aucune garantie de zéro interruption, d’IP conservée, de licence transférable ou de restauration sans perte n’est donnée.
Sauvegarder SQL de façon cohérente
Choisissez une sauvegarde adaptée au moteur et testez sa restauration. Copier les fichiers d’une base active ou prendre un snapshot seul ne garantit pas la cohérence applicative. Les exports transactionnels MySQL/MariaDB ont des limites selon le moteur et les opérations DDL simultanées. Préservez schéma, données, routines et événements utiles puis recréez les privilèges appropriés.
Préparez une destination compatible avec les logiciels, assez d’espace pour les données restaurées et les archives temporaires, les ports et les permissions nécessaires. Conservez les versions lors de la première restauration ; séparez les mises à niveau. Une quantité identique de RAM ou de vCPU ne prouve pas des performances équivalentes.
- files ≠ SQL export
- engine / version / collation
- consistent backup
- restore test
Préparer une destination et une copie maîtrisées
Conservez les versions initiales et vérifiez disques, architecture et privilèges. Préservez propriétaires, permissions et attributs pris en charge. La simulation locale rsync ne transfère rien, n’ouvre aucun SSH et ne valide pas l’application. Vérifiez chemins et barres finales avant toute future copie réelle. N’écrasez jamais le réseau d’une destination active avec la configuration de la source.
Planifiez un gel des écritures et un export final cohérent. Transférez séparément fichiers et exports SQL lorsque nécessaire. Comparez nombres de fichiers, tailles et sommes de contrôle d’une même archive stable. Une somme identique prouve l’intégrité du transfert, pas la cohérence ni l’exhaustivité des données.
- compatible OS / dependencies
- ownership / ACL / xattrs
- local dry run
- stable archive checksum
Simulation locale ou contrôle d’intégrité
rsync -aHAXn --numeric-ids -- /source/ /destination/Cette page n’a effectué aucune migration, vérification de sauvegarde ou validation de compatibilité. Conservez la source et une récupération testée. Aucune garantie de zéro interruption, d’IP conservée, de licence transférable ou de restauration sans perte n’est donnée.
Simulation locale ou contrôle d’intégrité
sha256sum /path/archive.tar.gzCette page n’a effectué aucune migration, vérification de sauvegarde ou validation de compatibilité. Conservez la source et une récupération testée. Aucune garantie de zéro interruption, d’IP conservée, de licence transférable ou de restauration sans perte n’est donnée.
Tester applications, certificats et accès en privé
Restaurez données et configuration, renseignez les secrets en privé et testez sous les bons utilisateurs. Vérifiez lectures/écritures SQL, certificats, tâches, relais de messagerie et pare-feu. Gardez une console de récupération avant les changements d’accès. IP, passerelle et noms d’interfaces d’origine ne sont pas nécessairement valides à destination.
Testez en privé avant ouverture : journaux de démarrage, authentification, permissions, données représentatives, persistance après redémarrage propre et dépendances externes. Vérifiez certificats et ports TCP/UDP sans exposer publiquement les interfaces d’administration. Consignez les contrôles et les écarts restant à résoudre.
- service accounts
- SQL read + write
- certificates / scheduled jobs
- new IP / ports
Geler les écritures, basculer et surveiller
Planifiez une dernière synchronisation cohérente sans écrivains concurrents puis validez la destination. Basculez les DNS concernés, surveillez les deux environnements pendant l’expiration des caches et évitez les tâches en double. Conservez le retour arrière et définissez le point nécessitant une réconciliation des nouvelles écritures. Résiliez après validation.
Ne basculez l’adresse publiée ou les DNS qu’après les tests privés. Tenez compte des TTL et caches ; un changement de prestataire implique généralement une nouvelle IP. Surveillez erreurs, ressources et nouvelles écritures. Fixez un point de décision de retour arrière : après de nouvelles écritures, il faut réconcilier les données, pas simplement rétablir les DNS.
- final synchronisation
- A / AAAA / MX as applicable
- avoid duplicate scheduled jobs
- rollback after new writes
Selon votre situation
| Situation | Prochaine vérification |
|---|---|
| Avant la migration | Ne commencez pas la bascule tant qu’une sauvegarde complète n’a pas été restaurée avec succès lors d’un test privé. |
| Pendant le transfert | Une copie à chaud peut manquer des changements simultanés. Préparez une réplication adaptée à l’application et une synchronisation finale avec un administrateur compétent ; aucune migration sans interruption n’est promise. |
| Après la bascule | Conservez l’ancien hébergeur et les sauvegardes originales jusqu’aux contrôles des données, connexions et sauvegardes. Définissez qui autorise la bascule et comment traiter les écritures créées après celle-ci. |
Sources officielles
Ces documents décrivent les protocoles et logiciels concernés. Les conditions de votre service et sa configuration restent à vérifier.