Superviser restic sur R2 : du stockage réussi à la restauration vérifiée

Une tâche terminée ne prouve pas que les données nécessaires sont récupérables. Ce cas interne généralisé évalue séparément stockage, intégrité, restauration et reprise du service. Il ne décrit pas une migration achevée depuis un autre service.

Fixer l’ID du snapshot et un objectif de reprise

Notez l’ID et restaurez les fichiers nécessaires dans une destination vide et isolée. Vérifiez références et permissions des configurations, ou chargement de la base en isolation. Mesurez la durée. Répétez périodiquement les mêmes contrôles pour comparer fraîcheur et périmètre récupérable.

restic：Restaurer dans une destination isolée

Définir source et réussite

Le dispositif utilise chiffrement et déduplication restic avec l’API compatible S3 de R2. Vérifiez les opérations dans la table de compatibilité. Pour les bases actives, prévoyez une capture cohérente par export ou suspension appropriée de l’application.

Surveiller la fraîcheur

Suivez séparément dernier instantané réussi, retards, échecs et résultats d’intégrité/restauration. Le lancement ne vaut pas réussite. Un échec de notification diffère aussi d’un échec de sauvegarde.

Vérifier intégrité et extraction

restic check par défaut et les contrôles lisant les données ont des périmètres différents. --read-data lit toutes les données ; documentez les contrôles partiels. Combinez contrôles du dépôt, restauration dans un emplacement isolé et comparaison de contenus ou empreintes. Extraire les fichiers ne vérifie pas le démarrage applicatif.

Gérer la rétention avec restic

Choisissez les instantanés par sa politique et utilisez forget, prune, check, en vérifiant auparavant ce qui restera. Supprimer les objets R2 uniquement selon leur âge peut détruire des données partagées nécessaires aux instantanés conservés. Suivez la documentation de rétention ; nettoyer des images distribuées relève d’un autre usage.

Vérifications restantes

Exploitation périodique, supervision/alertes, rétention et extraction/intégrité de données sélectionnées ont été effectuées. Démarrage de toutes les applications, configurations et dépendances, et accès aux identifiants séparés restent à valider de bout en bout. Délai de reprise et perte acceptable doivent être mesurés. Aucune reprise complète ni économie démontrée n’est revendiquée.

1. 1 Snapshot réussi et fraîcheur Vérifiez l’horodatage d’un snapshot réellement réussi et son retard par rapport au calendrier. Le démarrage du job ne suffit pas à prouver sa réussite.
2. 2 Intégrité et restauration isolée Consignez le périmètre du contrôle, exécutez restore --verify dans un autre emplacement et comparez les fichiers et les empreintes attendus avant d’examiner la rétention et prune.
3. 3 Reprise après sinistre complète Le démarrage de toutes les applications, les données dépendantes et la récupération des identifiants stockés séparément restent non vérifiés. Le délai de reprise et la perte de données admissible ne sont pas mesurés.

Ajout du 6 octobre 2026 : verrous obsolètes et concurrence lors des tests de restauration

Une modification supplémentaire vérifie l’activité des processus sur le même hôte avant d’exécuter le déverrouillage standard de restic, qui ne traite que les verrous obsolètes. L’option qui supprimerait tous les verrous, y compris ceux d’opérations actives, n’est pas utilisée. Les conflits donnent lieu à un nombre limité de nouvelles tentatives avec –retry-lock ; les tests de restauration et prune ne relancent pas indéfiniment le processus en cas d’échec. Vérifier l’activité sur un hôte ne prouve pas qu’aucune opération concurrente n’a lieu depuis un autre hôte.

Les données sont extraites avec restore –verify dans un répertoire temporaire isolé. Après vérification des fichiers nécessaires et de leur intégrité, la correspondance entre l’instantané vérifié et la configuration est consignée. La restauration des données visées est confirmée en premier, puis les éléments à conserver sont revus avant prune. La fraîcheur des sauvegardes est évaluée à partir d’un instantané réellement réussi, et non du démarrage du processus ou de ses nouvelles tentatives.

La restauration vérifiée des données visées reste distincte d’une récupération complète incluant le démarrage de toutes les applications et la récupération des identifiants. Pour le traitement des fenêtres de maintenance et des échecs de collecte, consultez aussi Surveillance et investigation des incidents.