Comment empêcher les tâches de purge Restic de bloquer les sauvegardes planifiées

Évitez les collisions lors du nettoyage en désignant un seul responsable de la maintenance par dépôt et en lui attribuant une fenêtre pendant laquelle aucun client de sauvegarde ne peut lancer de nouvelle opération.

Dans un dépôt partagé sur un serveur domestique, l’échec commence généralement avant l’erreur de verrouillage : plusieurs hôtes possèdent des plannings de maintenance, une sauvegarde dure plus longtemps que prévu et le nettoyage démarre sans mécanisme de contrôle à l’échelle du dépôt. Inversez cette chronologie. Centralisez le nettoyage, prévoyez suffisamment de temps, sérialisez les tâches en dehors de Restic et envoyez des alertes en cas d’exécution ignorée ou en retard. Si une collision s’est déjà produite, arrêtez les nouvelles tâches et utilisez la procédure de récupération minimale plutôt que d’affaiblir le verrouillage.

Attribuez un seul responsable de la maintenance à chaque dépôt

Recherchez sur chaque client et dans chaque service côté dépôt les commandes de maintenance de Restic. Notez qui est responsable de forget, prune, check, unlock et des alertes. Désactivez les plannings de nettoyage en double et conservez un seul contrôleur disposant des identifiants du dépôt et de la visibilité nécessaires pour voir tous les clients.

Plusieurs sauvegardes peuvent être coordonnées autour d’un même dépôt, mais supprimer tous les verrouillages avant le nettoyage annule la limite de sécurité et peut créer le chevauchement dangereux que le planning devait éviter.

Le contrôle de responsabilité est réussi lorsqu’un seul hôte peut lancer la maintenance à l’échelle du dépôt et que chaque client de sauvegarde sait où signaler les échecs. Si un équipement ou un outil d’encapsulation de sauvegarde peut lancer une maintenance masquée, désactivez son option automatique ou intégrez-le au même contrôleur avant de poursuivre.

Réservez une fenêtre de nettoyage plus longue que la pire exécution normale

Utilisez les journaux récents pour déterminer la durée de la sauvegarde normale la plus longue, celle du nettoyage récent le plus long, les délais de réveil des clients et le retard accumulé des nouvelles tentatives. Planifiez le nettoyage après la fin prévue de la dernière sauvegarde et prévoyez du temps pour sa propre durée maximale normale. Ne choisissez pas minuit simplement parce que cette heure semble calme sur un seul hôte.

Une stratégie de rétention doit également limiter les instantanés par hôte ou par étiquette afin que la rétention multi-hôte ne sélectionne pas les mauvais instantanés lorsque le dépôt est géré par un seul responsable de la maintenance.

Si les sauvegardes dépassent fréquemment la limite proposée, déplacez le nettoyage plutôt que de raccourcir la fenêtre de sauvegarde. Si la durée du nettoyage dépasse l’intervalle disponible, réduisez la fréquence de la récupération physique, examinez le débit du backend ou utilisez une fenêtre plus large. La prévention échoue lorsque le planning dépend de l’achèvement de chaque tâche dans sa durée moyenne.

Imposez l’exclusion mutuelle et une politique de nouvelle tentative visible

Utilisez une seule méthode externe de sérialisation que toutes les tâches locales respectent : l’ordonnancement des unités systemd, un wrapper de verrouillage partagé ou une file d’attente contrôlée par l’hôte de maintenance. Le wrapper doit refuser ou retarder la tâche lancée ultérieurement, préserver le verrouillage propre à Restic et écrire un état clair sur lequel la supervision peut déclencher une alerte.

Un planning Restic basé sur systemd peut séparer les services récurrents de sauvegarde et de nettoyage afin que l’ordre d’exécution, le code de sortie et les journaux restent visibles.

Définissez un intervalle de nouvelle tentative limité et un délai maximal. Une sauvegarde bloquée par la maintenance doit réessayer après la fenêtre, et non disparaître jusqu’au lendemain ; un nettoyage bloqué par une sauvegarde en retard doit déclencher une alerte et passer à la prochaine fenêtre approuvée. Ne faites jamais du déverrouillage forcé automatique l’action de nouvelle tentative.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Testez la politique de prévention et conservez une procédure de retour en arrière minimale

Testez les deux ordres sur un dépôt jetable ou un jeu de données d’exemple : démarrez d’abord la sauvegarde et demandez ensuite le nettoyage, puis démarrez d’abord le nettoyage et demandez ensuite la sauvegarde. Dans chaque cas, une tâche doit attendre ou se terminer de manière visible, le contrôleur doit réessayer selon la politique configurée et aucun verrouillage ne doit être supprimé sous un processus actif.

Après le déploiement, examinez les journaux de la prochaine sauvegarde, de forget et de prune normaux. Si le dépôt passe en lecture seule après la maintenance, utilisez la procédure de récupération après un nettoyage interrompu distincte plutôt que d’assouplir le mécanisme de prévention.

La politique est validée lorsque deux cycles s’achèvent sans chevauchement, que les tâches retardées réessaient de manière visible, que des alertes sont envoyées en cas de fenêtre manquée et qu’une restauration d’exemple reste valide. En cas d’échec, désactivez d’abord l’automatisation du nettoyage et laissez les sauvegardes ordinaires fonctionner avec le verrouillage normal. Faites remonter le problème lorsqu’aucune fenêtre de maintenance ne convient à la charge mesurée ou lorsque le backend ne peut pas effectuer le nettoyage de manière fiable.