Définissez la perte de données acceptable et le temps de récupération, conservez une copie indépendante cohérente et testez la restauration de l'application réelle en isolation. Une tâche de sauvegarde terminée ou une vérification d'intégrité seule ne prouve pas que toutes les dépendances nécessaires à la récupération sont présentes.
Commencez par la récupération dont vous avez besoin
Un plan de sauvegarde commence par deux questions pratiques : quelle quantité de travail récent pourriez-vous perdre, et combien de temps le service pourrait-il rester indisponible ? Ces réponses déterminent la planification, les données à inclure et la méthode de restauration. Une copie quotidienne peut convenir à un site rarement modifié tout en laissant un écart trop important pour une application très sollicitée.
Listez ce qui fait fonctionner le service, pas seulement son dossier le plus volumineux. Les données applicatives, le contenu de la base de données, la configuration, les fichiers téléversés et les informations nécessaires pour reconstruire l'environnement peuvent tous compter. Conservez un inventaire privé des dépendances et des clés de récupération. La sauvegarde doit soutenir un système fonctionnel, pas seulement produire une archive dont l'objectif est oublié.
Conservez une copie en dehors de la limite de défaillance
Un second répertoire sur la même machine peut aider à récupérer une modification erronée, mais il reste exposé à la perte de cette machine. Les instantanés locaux peuvent être précieux pour un retour arrière rapide et nécessitent toujours une copie indépendante pour les incidents plus larges. Choisissez une destination de récupération distincte et décidez quels accès doivent pouvoir lire, écrire ou supprimer la sauvegarde.
Si les identifiants de production peuvent supprimer chaque copie de récupération, un compte applicatif compromis peut déjouer toute la stratégie. Séparez les accès lorsque c'est possible et protégez les identifiants de stockage. Le chiffrement aide à protéger le contenu stocké, mais le processus de récupération dépend aussi de la conservation de sa clé en lieu sûr, en dehors de l'environnement endommagé.
Capturez un état applicatif cohérent
La copie de fichiers de base de données ouverts sans méthode appropriée peut capturer un état inutilisable. Utilisez une approche de sauvegarde prise en charge par l'application ou la base de données, et déterminez si elle nécessite un instantané cohérent, une exportation logique ou une brève pause des écritures. Coordonnez les données associées afin qu'un répertoire de téléversement et ses références en base de données décrivent le même point du flux de travail.
Documentez délibérément les exclusions. Les caches et les fichiers de compilation temporaires peuvent être reproductibles ; les téléversements des clients ne le sont généralement pas. Passez la liste en revue après l'ajout d'une fonctionnalité ou le déplacement d'un répertoire. Une tâche de sauvegarde réussie ne peut pas préserver un chemin qui n'a jamais été inclus.
Testez la restauration dans un environnement isolé
Restaurez des données représentatives dans un emplacement distinct et vérifiez qu'elles s'ouvrent correctement. Pour une application, testez le service restauré ainsi que les fichiers. Désactivez les e-mails sortants, les tâches planifiées et les intégrations externes dans l'environnement de test afin que la répétition n'agisse pas sur de vrais utilisateurs ni ne duplique des tâches de production.
Les contrôles d'intégrité du dépôt et un test de restauration répondent à des questions différentes. Un outil peut vérifier les structures et les données stockées alors que l'application a encore besoin d'une configuration manquante ou d'une clé oubliée. Notez la durée de la récupération, les étapes manuelles nécessaires et les points à améliorer dans la procédure. Répétez l'exercice après des changements importants.
Un scénario pratique : répéter la récupération avant le lancement
Prenons l'exemple d'une application avec une base de données, des téléversements d'utilisateurs et un petit ensemble de fichiers de configuration privés. Le propriétaire crée un inventaire de récupération et choisit une méthode de cohérence prise en charge par la base de données. Une destination de sauvegarde distincte stocke les copies nécessaires, tandis que la clé de récupération est conservée en dehors de la machine de production. Le premier test commence par un environnement isolé vide, afin que les dépendances cachées ne puissent pas être empruntées au serveur en fonctionnement.
Le propriétaire restaure les données et la configuration, puis vérifie la connexion, un enregistrement représentatif et un fichier téléversé. Les e-mails sortants, les tâches planifiées et les actions externes restent désactivés pendant la répétition. Si la base de données démarre mais qu'un chemin de téléversement ou un secret manque, le test a révélé une lacune qu'une tâche d'archivage réussie ne révélerait pas. Le propriétaire corrige l'inventaire et répète le contrôle de récupération concerné.
Enfin, le propriétaire consigne le temps de restauration et les étapes manuelles. La planification et la politique de rétention sont comparées à la quantité de travail récent qui pourrait être perdue et à la durée pendant laquelle le service pourrait rester indisponible. Ce sont des décisions propres au projet, et non des garanties fournies par une étiquette de stockage. Une procédure testée rend une sauvegarde optionnelle ou un produit de stockage utile dans le cadre d'une stratégie de récupération plus large.
| Preuves de récupération | Ce qu'il vérifie | Question restante |
|---|---|---|
| Tâche de sauvegarde terminée | La tâche a signalé un succès | Tous les chemins requis étaient-ils inclus ? |
| Contrôle d'intégrité du dépôt | Contrôles des structures ou des données stockées | L'application dispose-t-elle de toutes les dépendances ? |
| Restauration isolée de l'application | Une récupération représentative fonctionne | Le temps observé respecte-t-il votre objectif ? |
Rendez la défaillance visible et la rétention intentionnelle
Une sauvegarde qui s'arrête silencieusement est une surprise future. Surveillez l'achèvement des tâches, la capacité disponible et l'âge du dernier point de récupération utilisable. Conservez un historique suffisant pour récupérer après un problème découvert plus tard, et comprenez comment l'élagage affecte cet historique. Examinez attentivement les opérations de suppression, car des erreurs de rétention peuvent supprimer la seule version utile.
Lisez la portée de toute option de sauvegarde sur votre service SwissOctet choisi et confirmez le processus de restauration. Vault Storage peut être considéré comme un composant de capacité, mais un produit de stockage seul ne constitue pas une politique de récupération complète. Décidez ce que vous devez restaurer, conservez la copie indépendante et prouvez la procédure avant que le service ne devienne critique.
Votre liste de contrôle pratique.
- Définissez la perte de données et le temps de récupération acceptables.
- Incluez les bases de données, les téléversements et les informations de reconstruction.
- Conservez une copie indépendante et des clés de récupération distinctes.
- Restaurez en isolation et testez l'application.
- Surveillez l'âge des sauvegardes, la capacité et la rétention.
Les détails qui comptent.
Un second répertoire sur le même serveur est-il une sauvegarde indépendante ?+
Non. Il reste exposé à la perte de ce serveur, même s'il peut aider à récupérer une erreur locale.
Un contrôle d'intégrité remplace-t-il une répétition de restauration ?+
Non. Un dépôt valide peut encore omettre la configuration, les clés ou les données requises par l'application.
Pourquoi désactiver les intégrations lors d'un test de restauration ?+
Pour empêcher l'environnement de test d'envoyer des e-mails à de vrais utilisateurs, de répéter des tâches ou de déclencher des actions de production.
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.
- restic : Restauration à partir d'une sauvegarde restic.readthedocs.io
- restic : Travailler avec les dépôts restic.readthedocs.io
- PostgreSQL : Sauvegarde et restauration www.postgresql.org
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.