Révisé · Ressources Hosmio
Avant de commencer
Choisissez une destination jetable et un périmètre de test écrit. Confirmez l'accès au code de l'application, aux versions logicielles requises et au matériel de sauvegarde approuvé. Gardez la cible séparée de la production, avec les notifications sortantes, les tâches planifiées et les écritures externes désactivées jusqu'à un test délibéré.
01
Listez ce qui doit être déplacé et ce qui doit être recréé.
Incluez le runtime, la base de données, les fichiers téléversés, la configuration, les tâches planifiées, les certificats, la propriété DNS et les intégrations externes. Consignez qui contrôle chaque dépendance et comment l'accès peut être rétabli si le VPS actuel est indisponible. Identifiez toute fonctionnalité propre à un fournisseur qui nécessite un remplacement plutôt qu'une copie de fichier.
Notez par écrit les versions et extensions attendues. Une commande d'installation qui récupère la dernière version disponible aujourd'hui peut ne pas recréer l'application que vous exploitez. Référencez un stockage sécurisé des secrets pour les identifiants ; un plan de reprise doit expliquer comment une personne autorisée les récupère sans mettre les secrets dans le plan lui-même.
02
Choisissez une méthode d'export et de restauration adaptée aux données.
Pour PostgreSQL, un export logique avec pg_dump couvre une seule base de données, tandis que les objets globaux tels que les rôles nécessitent un traitement séparé. L'outil refuse de sauvegarder un serveur dont la version majeure est plus récente que celle prise en charge par le client. La documentation officielle met également en garde contre le fait de considérer pg_dump comme une stratégie de sauvegarde universelle en production régulière. PostgreSQL : pg_dump ↗
Choisissez la méthode adaptée à votre application et à vos besoins de récupération avec son opérateur. Notez ce que l'export omet et comment les fichiers sont maintenus cohérents avec les références de la base de données. Une commande qui se termine avec succès est une première vérification utile, pas la preuve qu'une application complète a été préservée.
03
Restaurez vers une cible explicitement séparée.
Inspectez l'archive et la destination avant de restaurer. La restauration d'archive PostgreSQL utilise pg_restore ; les options qui nettoient les objets existants peuvent supprimer des données, et son comportement par défaut peut continuer après des erreurs SQL. Planifiez la gestion des erreurs et inspectez le résultat plutôt que de supposer que chaque objet a été restauré. PostgreSQL : pg_restore ↗ N'exécutez pas un tutoriel sur la base de données de production simplement parce que son nom vous est familier.
Pour les sauvegardes de fichiers, sélectionnez l'instantané souhaité et une destination de test vide. Restic documente que la restauration peut écraser les fichiers existants ; un écrasement interrompu peut laisser un résultat partiel. restic : restauration à partir d'une sauvegarde ↗ Notez l'instantané source et le chemin cible dans la note d'exercice. Ce sont des lignes directrices pour le choix de la méthode, pas des commandes exécutées ou vérifiées sur un VPS Hosmio.
04
Vérifiez les tâches utilisateur et les effets secondaires cachés.
| Vérification | Preuves à conserver | Résultat |
|---|---|---|
| L'application démarre avec les versions documentées | Inventaire des versions et résultat de démarrage | Pas encore testé |
| Les enregistrements et fichiers représentatifs concordent | Vérifications de données synthétiques et pièces jointes | Pas encore testé |
| Les permissions se comportent correctement | Deux rôles de test et accès attendu | Pas encore testé |
| Les tâches n'envoient pas de travail externe en double | Actions sortantes désactivées ou test contrôlé | Pas encore testé |
| L'opérateur de remplacement peut suivre les notes | Parcours indépendant et lacunes | Pas encore testé |
Utilisez des comptes synthétiques et des enregistrements de test sans danger dans la mesure du possible. Vérifiez les limites d'accès ainsi que les lectures réussies. Une application qui démarre mais accorde les mauvaises permissions n'est pas une récupération réussie. Conservez les vérifications échouées dans le registre avec un responsable pour la remédiation.
05
Planifiez le moment où de nouvelles écritures changent la décision.
Une répétition doit éclairer la séquence du futur transfert : étape de cohérence finale, vérifications de la destination, bascule du trafic, décision d'acceptation et mise hors service de l'ancien service. Décidez qui peut arrêter ou inverser l'opération. Si la destination a accepté de nouvelles écritures, renvoyer les utilisateurs vers une ancienne copie peut perdre ou scinder ces écritures ; le retour en arrière nécessite un plan de données, pas seulement un changement DNS.
Prévoyez un chevauchement dans le budget. Un second serveur, un stockage indépendant, des frais de trafic, des licences et du temps opérateur peuvent être nécessaires. Ne supposez pas qu'un fournisseur calcule au prorata un VPS ni que les fonds prépayés sont remboursables. Les prix par période publiés par Hosmio décrivent des conditions initiales ; ils ne définissent pas un service de migration ou de remboursement.
06
Laissez des preuves qu'un autre opérateur peut utiliser.
Notez la date de l'exercice, les versions, les identifiants de copie, la cible, l'effort écoulé et les résultats uniquement après que l'exercice a été réellement effectué. Jusque-là, utilisez « planifié » ou « non testé ». Conservez la fiche d'acceptation avec les notes de récupération et listez les dépendances qui empêchent encore une reconstruction indépendante.
Si la répétition échoue, classez la lacune : données manquantes, logiciel incompatible, identifiants indisponibles, dépendance externe ou procédure peu claire. Résolvez le plus petit problème bloquant, puis répétez la vérification concernée. Ne qualifiez pas l'application de portable tant qu'une tâche critique reste non testée.
Reliez le plan à des responsabilités opérationnelles nommées et le processus d'approbation des changements du client. Le résultat visé est une capacité démontrée à récupérer dans un périmètre documenté, et non une promesse d'absence d'interruption ou une migration livrée automatiquement.