Flux de maintenance d’un dépôt Restic : vérifier, élaguer, compacter et tester la restauration

L’approche sûre consiste à traiter les planifications de tâches, la vérification de l’intégrité, la prévisualisation de la rétention, le nettoyage en vue du compactage, la nouvelle vérification et la restauration isolée comme une séquence de contrôles observables, et non comme une seule commande.

Sur un dépôt Restic utilisé par un ou plusieurs hôtes de serveur domestique, le risque pratique est de devoir maintenir un dépôt Restic sans bloquer les sauvegardes ni confondre la récupération d’espace avec la récupérabilité. Notez l’identité actuelle et le point de récupération, commencez par le critère le moins intrusif, interprétez les résultats de réussite et d’échec avant de modifier une autre variable, et arrêtez-vous lorsque le stockage devient instable ou que la seule copie récupérable risque d’être exposée. Le flux de travail ci-dessous ne se termine qu’une fois la charge de travail d’origine exécutée avec succès ou lorsque les éléments disponibles atteignent un seuil nécessitant une escalade.

Ouvrir une fenêtre de maintenance à l’échelle du dépôt

Mettez en pause les planifications de sauvegarde, d’oubli, de vérification, de copie et de nettoyage sur chaque hôte pouvant accéder au dépôt. Confirmez qu’aucun détenteur actif de verrou ne subsiste, enregistrez la version de Restic et l’identifiant du dépôt, puis testez les identifiants sans les exposer dans l’historique du shell ni dans les journaux. La maintenance du dépôt constitue une modification d’état partagée, et non une tâche par conteneur.

Si un plantage antérieur a laissé un verrou, suivez le flux de travail de ZimaSpace pour un dépôt Restic verrouillé après un plantage avant de le déverrouiller. Un verrou est la preuve d’une propriété ; supprimez-le uniquement lorsque le processus nommé, l’hôte, les horodatages et l’activité du backend montrent que l’opération est terminée.

Vérifiez l’espace libre du backend, les inodes ou les limites d’objets, les permissions d’écriture ainsi que l’espace local du cache ou des fichiers temporaires. Arrêtez-vous si le chemin de stockage est instable, si une rétention immuable empêche la suppression requise ou si un autre écrivain ne peut pas être mis en pause.

Vérifier la structure et échantillonner les données du dépôt

Exécutez restic snapshots et une commande restic check normale, en enregistrant la sortie et le code de retour. Planifiez ensuite --read-data ou les sous-ensembles de lecture des données pris en charge, selon la taille du dépôt et la bande passante. Une réussite limitée à la structure ne prouve pas que chaque pack est lisible.

Une discussion de la communauté Restic distingue les rôles courants de check, prune et rebuild-index et explique que la reconstruction de l’index ne constitue pas une maintenance préventive normale. N’exécutez pas rebuild-index et ne supprimez pas de fichiers pack simplement parce qu’une vérification est lente ; réservez les commandes de récupération à une incohérence diagnostiquée.

Si la vérification signale des packs manquants, une incompatibilité de hachage, une erreur de lecture du backend ou une incohérence de l’index, arrêtez-vous avant le nettoyage. Protégez le dépôt, répétez uniquement la lecture en échec via un chemin stable et effectuez une escalade vers une récupération documentée sur une copie.

Prévisualiser la rétention, puis nettoyer et compacter

Exécutez la politique restic forget prévue avec --dry-run et examinez les instantanés conservés et supprimés par hôte, chemin et balises. N’appliquez forget que lorsque la liste préserve les points de récupération requis. Dans la mesure du possible, conservez un instantané récent vérifié en dehors d’une modification expérimentale de la politique.

Dans Restic, « compact » n’est pas une commande distincte : prune supprime les données non référencées et recompacte les fichiers du dépôt si nécessaire. Un guide de dépannage actuel décrit les échecs de prune de Restic, notamment les problèmes d’espace libre et de verrous qui doivent être résolus avant toute nouvelle tentative destructive.

Exécutez prune une seule fois, sans concurrence avec les sauvegardes, et conservez son journal complet. En cas d’échec, ne relancez pas la commande à l’aveugle et ne supprimez pas les objets qui semblent temporaires. Vérifiez de nouveau les verrous, l’espace de travail libre, les permissions du backend et la dernière phase terminée ; préservez l’état du dépôt pour le diagnostic.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Effectuer une nouvelle vérification et une restauration isolée

Après un prune réussi, exécutez de nouveau restic check et terminez la couverture de lecture des données prévue. Comparez le nombre d’instantanés, la taille du dépôt et les erreurs avec la référence établie avant la maintenance. Si l’espace ne diminue pas conformément à une estimation, cela ne constitue pas un échec lorsque les instantanés conservés référencent encore les données.

Restaurez un instantané récent ainsi qu’un sous-ensemble représentatif plus ancien dans un répertoire vide. Vérifiez le contenu des fichiers, les permissions, les horodatages, les liens symboliques et un artefact au niveau de l’application. Une opération de montage ou de listage seule ne constitue pas un test de restauration.

Ne reprenez les planifications que lorsque la vérification post-prune réussit, que les données restaurées sont utilisables et qu’une nouvelle petite sauvegarde peut être créée puis restaurée. Effectuez une escalade en cas de nouvelle corruption, d’erreur backend répétée ou de prune incomplet avant d’autoriser plusieurs hôtes à écrire de nouveau.