Un instantané est une représentation à un instant donné dont la protection dépend de son implémentation. Une stratégie de sauvegarde ajoute une rétention délibérée, une séparation des accès et une récupération testée. Certains instantanés sont des sauvegardes ; d'autres dépendent du stockage d'origine. Demandez ce qui survit à une suppression, à une compromission ou à la perte de l'environnement principal.
Décrire la copie avant de la nommer
Le mot instantané indique qu'un instant a été représenté, mais pas où se trouvent les données récupérables ni qui peut les supprimer. Un instantané de système de fichiers sur le stockage d'origine et un instantané de bloc géré par un fournisseur peuvent avoir des limites de panne différentes. Commencez par l'implémentation plutôt que de traiter l'étiquette comme une promesse universelle.
AWS documente les instantanés EBS comme des sauvegardes incrémentielles à un instant donné de ses volumes. C'est une implémentation spécifique, pas la preuve que toutes les options d'instantané se comportent de la même manière. Pour tout service, demandez si la restauration dépend du volume d'origine, si les copies quittent le domaine de panne principal et ce qui se passe lorsque la source est supprimée.
Comparer les pannes auxquelles vous comptez survivre
Un retour arrière rapide après une mise à jour et une récupération après la perte d'un compte sont des problèmes différents. Un instantané local peut être pratique pour le premier tout en offrant peu de séparation pour le second. Des copies indépendantes peuvent ajouter une protection, mais seulement si leurs chemins de stockage, d'accès et de suppression sont suffisamment séparés de l'incident auquel vous vous préparez.
Notez la panne et le résultat requis. Cette comparaison illustrative est une aide à la décision, pas une liste de fonctionnalités pour SwissOctet. Elle encourage des questions sur les copies et le contrôle plutôt qu'une affirmation selon laquelle une technologie est toujours supérieure. Le résultat réel dépend de la configuration et du processus de récupération documenté par l'opérateur.
| Scénario | Question pour un instantané | Question pour une sauvegarde |
|---|---|---|
| Mauvaise mise à jour applicative | Puis-je revenir au point souhaité ? | Combien de temps prend une restauration utilisable ? |
| Disque principal perdu | La copie dépend-elle de ce disque ? | Puis-je restaurer sur un stockage neuf ? |
| Compte d'administration compromis | Ce compte peut-il supprimer toutes les copies ? | Les droits de suppression sont-ils séparés ? |
| Erreur découverte des semaines plus tard | Ce point est-il encore conservé ? | La rétention couvre-t-elle le délai de découverte ? |
Vérifier la cohérence applicative
Un disque peut capturer des fichiers alors qu'une application les modifie encore. Selon le logiciel et le processus d'instantané, le résultat peut représenter un état cohérent après plantage plutôt qu'un état applicatif coordonné. Ne supposez pas que des fichiers lisibles signifient qu'une base de données et ses téléversements associés sont cohérents. Utilisez la méthode de sauvegarde documentée par l'application ou la base de données.
La conception d'archivage continu de PostgreSQL illustre la différence : la récupération nécessite une sauvegarde de base appropriée et une séquence continue des fichiers de journal d'écriture anticipée requis. Un répertoire copié sans précaution pendant que la base de données fonctionne n'est pas une procédure équivalente. Si l'application stocke aussi des fichiers en dehors de la base de données, planifiez la récupération conjointe de ces deux ensembles de données.
Traiter la rétention comme une fenêtre de récupération
La rétention doit tenir compte du temps pendant lequel une erreur peut passer inaperçue. Une fenêtre de dix jours n'aide pas pour une suppression accidentelle découverte après un mois. Conserver chaque copie indéfiniment crée un autre problème : coût, exposition croissante des données sensibles et politique de suppression peu claire. Choisissez la rétention à partir d'exigences opérationnelles et de traitement des données concrètes.
Étiquetez les points de récupération avec un contexte utile, comme la version de l'application et l'heure d'achèvement d'une tâche, sans y intégrer de secrets. Conservez suffisamment d'historique pour distinguer un bon état d'un état endommagé. Avant d'élaguer, confirmez comment le système choisi gère les données partagées ou incrémentielles ; supprimer un point étiqueté peut ne pas correspondre à la suppression d'un simple fichier autonome.
Séparer les tâches réussies des données vérifiées
Un outil de sauvegarde qui signale un succès établit que son processus s'est terminé selon ses règles. Cela ne prouve pas automatiquement que toutes les données applicatives importantes ont été sélectionnées, que chaque octet stocké reste intact ou qu'un nouveau serveur peut utiliser le résultat. Ce sont des vérifications différentes. Incluez la santé du dépôt, la revue de la sélection et une restauration représentative dans le plan opérationnel.
Restic documente une distinction entre sa vérification par défaut du dépôt et la vérification qui lit les données de pack stockées. La vérification complète avec lecture des données peut consommer plus de temps et de bande passante. Cet exemple rend le point de planification concret : décidez ce que la vérification lit réellement et budgétez le travail. Utilisez la documentation de l'outil plutôt que de supposer que chaque commande nommée check a la même couverture.
Tester une récupération petite et complète
Imaginez une publication avec une base de données, des images téléversées et une configuration. Restaurez les trois dans un environnement de test privé, puis ouvrez un article et vérifiez ses pièces jointes. Gardez les intégrations planifiées de courrier, de paiement et de publication désactivées pendant l'exercice. Tester seulement un fichier texte aléatoire manquerait les relations qui rendent l'application utile.
Mesurez le temps nécessaire et notez quels identifiants, versions de paquets ou dépendances externes manquaient. Vérifiez les permissions sur les fichiers récupérés, pas seulement leur contenu. Un exercice de récupération découvre souvent que les données existent mais que les instructions ou les accès nécessaires pour les utiliser n'ont jamais été conservés avec le plan d'exploitation.
Lire les sauvegardes optionnelles comme un service spécifique
Lors de la configuration de SwissOctet, examinez l'option de sauvegarde exacte et la période de rétention pour la famille. Demandez quels volumes et données applicatives elle couvre, si la récupération est en libre-service et ce qui se passe lorsque la configuration principale change. L'étiquette de l'option seule n'établit pas une copie indépendante, un dépôt immuable ou un point de récupération cohérent pour la base de données.
Utilisez les instantanés là où ils conviennent à la charge de travail et maintenez une stratégie de sauvegarde plus large pour les pannes qu'ils ne couvrent pas. Enregistrez une voie de récupération indépendante pour les données importantes, protégez les identifiants qui peuvent effacer les copies et testez la procédure. Le meilleur choix est celui qui survit à votre scénario défini, pas celui dont le nom est le plus rassurant.
Votre liste de contrôle pratique.
- Identifier où se trouvent les données récupérables.
- Lister les pannes auxquelles la copie doit survivre.
- Utiliser une méthode de cohérence prise en charge par l'application.
- Choisir la rétention selon la fenêtre de découverte.
- Protéger séparément les droits de suppression.
- Restaurer une application complète en isolation.
Les détails qui comptent.
Un instantané n'est-il jamais une sauvegarde ?+
Certaines implémentations d'instantanés sont des sauvegardes. La distinction utile réside dans leur dépendance au stockage, leur rétention, leur modèle d'accès et leur récupération testée, pas dans l'étiquette seule.
Une vérification d'intégrité réussie prouve-t-elle que l'application fonctionnera ?+
Elle prouve seulement ce que cette vérification couvre. Testez séparément la restauration de l'application, la configuration, les permissions et les relations entre les données.
Dois-je conserver la sauvegarde sur le même serveur ?+
Une copie sur le même serveur peut aider face à des erreurs limitées, mais partage les mêmes défaillances importantes. Les données importantes nécessitent une voie de récupération en dehors de la frontière de défaillance que vous souhaitez survivre.
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.
- Amazon EBS : Snapshots docs.aws.amazon.com
- PostgreSQL : archivage continu et récupération à un instant précis www.postgresql.org
- Restic : travailler avec les dépôts et les contrôles d'intégrité restic.readthedocs.io
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.