Des sauvegardes chiffrées réellement restaurables.

Choisir la limite du dépôt

Utilisez une destination et des identifiants distincts de ceux du serveur de production. Le chiffrement côté client peut protéger les copies stockées, mais le mot de passe ou la clé du dépôt doit être sauvegardé en privé. Sa perte peut rendre inutilisable chaque instantané chiffré.

Capturer des données cohérentes

Utilisez des vidages natifs de la base de données ou une procédure d’instantané prise en charge par l’application. Sauvegardez la configuration, les instructions de déploiement et les secrets protégés nécessaires à la récupération. N’excluez les caches transitoires que si vous savez qu’ils peuvent être reconstruits.

Rendre la suppression plus difficile

Envisagez une destination en ajout seul ou immuable, où la machine source ne peut effacer chaque copie historique. Séparez autant que possible les identifiants de rétention et d'élagage. Le chiffrement seul n'empêche pas un serveur compromis de supprimer un dépôt accessible en écriture.

Planifiez des contrôles et des exercices de restauration

Surveillez le statut de sortie des tâches et l'âge de la dernière sauvegarde valide. Exécutez les contrôles d'intégrité du dépôt pris en charge par l'outil. Restaurez régulièrement un échantillon et effectuez une répétition complète de récupération après des modifications majeures de l'application.

Distinguez l'ajout d'une copie de la suppression de l'historique

Une destination en ajout seul peut permettre au serveur de production d'ajouter des instantanés tout en conservant l'autorité de suppression sur une machine de confiance distincte. La rétention nécessite néanmoins un examen attentif : des instantanés plus récents falsifiés peuvent compromettre certaines politiques de sélection basées sur le calendrier. Consultez les recommandations de l'outil, effectuez un essai à blanc de la rétention et surveillez la capacité. L'opération forget de Restic sélectionne les instantanés ; l'élagage supprime les données stockées non référencées.

• Gardez les identifiants de maintenance du dépôt hors de la machine de production
• Exécutez un test à blanc de conservation avant d'autoriser la suppression
• Utilisez une nouvelle cible vide pour chaque exercice de récupération

restic check
restic snapshots
restic restore latest --target /srv/restore-drill

Documentation officielle : Rétention et élagage Restic

Un exercice de restauration avec une condition de réussite

Choisissez un échec réaliste : un fichier supprimé, une base de données perdue ou une reconstruction complète de la machine. Restaurez dans un répertoire distinct ou un hôte isolé. Vérifiez le contenu des fichiers, les permissions et la capacité de l'application à les utiliser. Consignez le temps écoulé et toute étape manuelle absente du runbook. Une vérification du dépôt confirme une propriété différente d'une restauration applicative fonctionnelle.

• Ne pas restaurer par-dessus l'application en production comme premier test
• Confirmez que les identifiants de chiffrement sont récupérables de manière indépendante
• Alertez si la sauvegarde réussie la plus récente dépasse votre objectif de récupération

Établissez un manifeste de récupération avant de choisir les exclusions

Listez les éléments qui ne peuvent pas être recréés en réinstallant un paquet : contenu de la base de données, fichiers téléversés, configuration de l'application, clés de signature ou de chiffrement et versions de déploiement. Indiquez la méthode de cohérence à côté de chaque élément. Un vidage de base de données correspond à un instant précis ; copier le répertoire d'une base de données active peut donner un résultat différent. Conservez l'accès au dépôt, sa phrase secrète et toute exportation de clé Borg dans un emplacement de récupération privé distinct. Vérifiez qu'une machine de remplacement peut ouvrir le dépôt avant d'en faire l'unique copie de récupération.

• Énoncez l'objectif de point de reprise : quelle quantité de travail récent peut être perdue. Définissez la planification en fonction de cette exigence.
• Précisez l'objectif de temps de reprise : combien de temps une reconstruction peut prendre. Incluez l'importation de la base de données et les modifications de DNS dans la répétition.
• Vérifiez qu'une exclusion destinée aux caches ne supprime pas aussi les téléversements, les volumes de conteneurs ou la configuration protégée.
• Utilisez la documentation correspondant à la version majeure de Borg installée ; les formats de dépôt et les commandes ne sont pas interchangeables entre toutes les versions.

Documentation officielle : Borg : chiffrement, cohérence et restauration

Vérifiez les données stockées ainsi que les métadonnées du dépôt

La vérification par défaut du dépôt Restic et une vérification par lecture intégrale n'accomplissent pas le même travail. Planifiez la vérification des données en tenant compte de son coût en bande passante et en temps d'exécution. L'exemple vérifie un cinquième défini des fichiers pack ; les vérifications planifiées suivantes doivent utiliser les autres fractions pour couvrir le dépôt. Un sous-ensemble choisi aléatoirement n'offre pas la même garantie de couverture. Aucune des deux opérations ne prouve que l'application peut démarrer avec les données restaurées.

restic check --read-data-subset=1/5
restic snapshots --host example-host
restic restore latest --host example-host --target /srv/restore-drill

Documentation officielle : restic : contrôles du dépôt et vérification des données

Gardez la maintenance hors de portée du client compromis

Le stockage en ajout seul de Borg préserve les données de segments validées, mais un client peut toujours modifier la liste visible des archives ; la récupération et la compaction nécessitent la procédure administrative documentée. Limitez l'identifiant de sauvegarde distant à la commande serveur de Borg, et non à un shell ou une connexion au système de fichiers sans restriction qui pourrait contourner ces protections. Avec restic, consultez les recommandations keep-within pour la rétention en ajout seul. Avant toute maintenance susceptible de supprimer l'historique, inspectez l'état du dépôt et prévisualisez la sélection depuis une machine de confiance.

• Surveillez l'âge de la dernière copie réussie, la croissance du dépôt, l'espace de cache et la capacité libre aux deux extrémités.
• Si une restauration échoue, conservez le dépôt d'origine et les journaux avant toute tentative de réparation ou de nettoyage.
• Si la tâche réussit mais que des fichiers attendus manquent, inspectez le contenu de l'archive et les motifs d'exclusion avant de modifier la conservation.
• Terminez l'exercice en ouvrant les fichiers et en exécutant les contrôles applicatifs en isolation ; tenez les destinations de production hors de la commande de restauration.

Documentation officielle : Borg : exploitation et maintenance en ajout seul · restic : considérations sur la rétention et l'ajout seul