Migration sécurisée des données VPS avec rsync

Inventaire avant la copie

Lister les fichiers d'application, les propriétaires, les ACL, les attributs étendus, les bases de données, les secrets, les tâches planifiées, les services, les règles de pare-feu, le DNS, les certificats et le stockage externe. Vérifier la capacité de destination suffisante et la compatibilité des utilisateurs, des systèmes de fichiers, des packages du système d'exploitation et des versions d'application. Réduire la durée de vie (TTL) du DNS avant la bascule uniquement si cela est compatible avec votre stratégie DNS ; les enregistrements en cache peuvent avoir une durée de vie supérieure aux prévisions.

Créez et vérifiez une sauvegarde indépendante de la source. Conservez la source inchangée et disponible pendant toute la durée du transfert initial. Définissez des contrôles de réussite et une procédure de restauration avant d'annoncer une fenêtre de maintenance.

• Ne copiez pas les systèmes de fichiers virtuels tels que /proc, /sys, /dev ou /run comme des données ordinaires.
• Utilisez les outils natifs de sauvegarde, de réplication ou d'extraction de données de base de données, le cas échéant.
• Ne stockez jamais les clés privées dans l'historique des commandes ni dans les notes partagées.

Effectuez un test à blanc pour préparer les données de l'application.

Pour un répertoire tel que /srv/app/, testez l'opération à partir de la source avec sudo rsync -aHAX --numeric-ids --info=progress2 --dry-run -e "ssh -i /root/.ssh/migration_key" /srv/app/ admin@DESTINATION:/srv/app/. Remplacez l'utilisateur, le chemin de la clé, la destination et les chemins des données. La barre oblique finale indique de copier le contenu du répertoire source plutôt que de créer un niveau de répertoire supplémentaire.

Vérifiez chaque chemin et chaque erreur. Assurez-vous que le compte distant dispose des droits d'écriture sur la destination ; l'utilisation de l'authentification root est inutile et souvent désactivée. Si le résultat du test à blanc est correct, répétez la commande sans --dry-run. N'ajoutez pas --delete uniquement pour rendre les répertoires identiques : une source ou une destination incorrecte pourrait entraîner la suppression de données importantes.

• Pour les transferts volumineux, exécutez la commande dans une session de terminal persistante.
• Limitez la bande passante si la copie risque d'affecter le trafic de production.
• Consignez les options de commande et les versions des outils dans l'enregistrement de migration.

Mettez en pause les écritures et effectuez la dernière passe.

Placez l'application en mode maintenance ou en lecture seule (procédure documentée). Arrêtez les services d'écriture concernés en suivant leur procédure standard, puis effectuez la dernière sauvegarde de la base de données ou terminez la réplication. Exécutez à nouveau la commande rsync afin de ne transférer que les données modifiées. Conservez l'état de maintenance jusqu'à la fin de la validation.

Démarrez les services sur la destination avec la configuration prévue, en limitant initialement l'accès public si possible, et exécutez les vérifications d'intégrité, de connexion, d'écriture, de file d'attente, de certificat, de journalisation et de dépendances. Ne mettez à jour le DNS ou le routage qu'après la réussite de ces tests. Évitez de modifier simultanément la version de l'application et l'emplacement d'hébergement, sauf si le risque combiné est explicitement accepté.

• Enregistrez l'heure d'arrêt final des écritures et le résultat de la synchronisation.
• Valider la propriété des fichiers et les contrôles d'accès obligatoires.
• Surveiller les anciens et nouveaux points de terminaison pendant la transition DNS.

Vérifier, observer et conserver la restauration.

Pour une comparaison plus approfondie des fichiers, exécuter la commande rsync d'origine avec --checksum --dry-run pendant une fenêtre appropriée ; le calcul de la somme de contrôle lit les deux ensembles de données et peut s'avérer coûteux. Privilégier les contrôles d'intégrité au niveau applicatif pour les bases de données et les stockages d'objets. Surveiller les erreurs, la latence, l'utilisation des ressources, les tâches en arrière-plan et les rappels externes après la bascule.

Conserver la source intacte, mais empêcher les écritures simultanées jusqu'à la fin de la fenêtre de restauration. Suivre ensuite le plan de conservation et de suppression sécurisée. Une migration est considérée comme terminée uniquement lorsque les sauvegardes, la surveillance, la documentation et les procédures de récupération font référence à la destination.