Comment supprimer un verrou Restic obsolète sans interrompre une sauvegarde active

Un verrou Restic obsolète ne doit être supprimé qu’après avoir prouvé que chaque hôte et processus répertorié est inactif. La réparation consiste en un déverrouillage normal d’un verrou obsolète, et non en une suppression forcée de tous les verrous.

Lorsque plusieurs serveurs domestiques partagent un dépôt, un verrou qui semble ancien peut appartenir à une tâche distante lente, à un conteneur redémarré ou à un processus dont l’horloge diffère de celle de la machine de l’opérateur. Suspendez d’abord les nouvelles planifications, enregistrez les métadonnées du verrou, vérifiez l’hôte nommé ainsi que chaque contrôleur de maintenance, puis utilisez la procédure de nettoyage standard. Si un propriétaire ne peut pas être vérifié, arrêtez-vous et préservez le verrou.

Suspendre les nouvelles tâches et identifier chaque propriétaire de verrou

Désactivez les minuteurs, les entrées cron, les planifications de conteneurs et les tâches d’orchestration susceptibles de lancer Restic sur le dépôt. Enregistrez la liste actuelle des verrous et les journaux récents des services. Pour chaque verrou, notez l’hôte, l’ID du processus, l’utilisateur, l’horodatage et indiquez s’il est exclusif, puis examinez le processus nommé sur cet hôte précis.

Une vérification exclusive du dépôt peut bloquer les autres opérations, et un verrou de vérification interrompue peut ressembler à un verrou de sauvegarde abandonné tant que l’opération et son propriétaire n’ont pas été identifiés.

Si un processus est actif ou si ses journaux continuent d’avancer, attendez ou arrêtez-le proprement via son gestionnaire de services. Si l’hôte est inaccessible, le verrou ne peut pas être considéré comme obsolète avec certitude. Ne poursuivez que lorsque chaque processus concerné est absent, qu’aucun planificateur ne peut le redémarrer et qu’aucune écriture n’est effectuée sur le dépôt.

Vérifier qu’un verrou est obsolète au-delà de son ancienneté

Attendez pendant une courte période d’observation, puis répertoriez à nouveau les verrous. Un candidat obsolète n’a aucun propriétaire actif, aucun journal qui progresse, aucun rafraîchissement et aucune activité d’écriture sur le dépôt. Comparez les horloges et interrogez le même backend depuis un autre client de confiance si le dépôt est distant.

Un flux de travail complet pour un dépôt Restic considère le déverrouillage comme une opération administrative parmi d’autres, aux côtés des sauvegardes, vérifications, politiques de rétention et restaurations ; il ne remplace pas la détermination de la personne ou du processus qui possède encore le dépôt.

Si le verrou est rafraîchi, si un journal évolue ou si les clients n’ont pas la même vue du backend, arrêtez-vous. Si le verrou reste inchangé et que son propriétaire est définitivement arrêté, poursuivez. L’ancienneté confirme le résultat, mais ne suffit pas à l’établir ; une opération active et lente peut être plus ancienne que ne le pense l’opérateur.

Utiliser d’abord le nettoyage standard des verrous obsolètes

Utilisez le comportement de déverrouillage normal de Restic afin qu’il supprime les verrous obsolètes tout en préservant ceux qu’il considère encore comme actifs. N’ajoutez pas d’option de suppression globale et n’exécutez pas la commande suivante sans verrouillage. Enregistrez la sortie de la commande et affichez immédiatement après une nouvelle liste des verrous.

La commande de déverrouillage standard est spécifiquement prévue pour les verrous obsolètes, tandis que la suppression forcée est une action distincte et plus risquée qui ne doit pas faire partie de la procédure normale de réparation.

Si l’entrée obsolète disparaît sans qu’aucun verrou actif ne soit supprimé, passez à la validation. Si un verrou actif reste présent, respectez-le et revenez à la vérification de son propriétaire. Si un verrou réapparaît immédiatement, un minuteur, un conteneur ou un hôte distant a lancé une opération ; désactivez cette source et ne répétez pas le déverrouillage tant que le nouveau propriétaire n’est pas identifié.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Valider la sauvegarde d’origine et la prochaine exécution planifiée

Exécutez la sauvegarde exacte qui était bloquée et enregistrez son démarrage, sa progression, son statut de sortie et le cycle de vie du verrou. Vérifiez que le verrou apparaît pendant l’exécution de Restic et disparaît après une sortie propre. Répertoriez le nouvel instantané et restaurez un petit échantillon dans un emplacement distinct avant de réactiver l’automatisation.

Si le dépôt se comporte comme s’il était en lecture seule ou si la maintenance reste incomplète, gardez l’état résultant d’un prune interrompu distinct du nettoyage d’un verrou obsolète.

Réactivez la planification normale pour un cycle. La réparation est réussie lorsque les deux exécutions se terminent, que leurs verrous sont supprimés normalement et que l’échantillon restauré correspond à l’original. Faites remonter le problème si un verrou obsolète réapparaît après la sortie propre d’un processus, si les vues du backend restent incohérentes ou si les résultats de la vérification du dépôt et de la restauration divergent. N’automatisez pas le déverrouillage forcé comme solution à la récurrence.