Dépôt Restic verrouillé après un plantage : causes, vérifications et solutions

Un dépôt Restic peut rester verrouillé parce qu’un autre processus est toujours actif, qu’un plantage a laissé un état obsolète, que le backend a retardé les mises à jour ou qu’une opération de maintenance détient encore un verrou exclusif.

Sur un serveur domestique multi-hôtes, il est dangereux de supposer que le dernier plantage visible a créé l’unique verrou. Une tâche de purge peut encore s’exécuter ailleurs, un conteneur peut avoir redémarré avec la même planification, ou le stockage d’objets peut ne pas afficher immédiatement l’état le plus récent. Commencez par suspendre les nouvelles planifications et lisez l’identité du verrou ; ne supprimez un verrou qu’après avoir établi que son hôte, son processus, son heure et l’activité du dépôt correspondent tous à une opération terminée.

Lisez l’identité du verrou avant d’agir

Mettez en pause les planifications de sauvegarde, d’oubli, de vérification et de purge sur chaque machine pouvant accéder au dépôt. Listez les verrous et enregistrez leur hôte, leur identifiant de processus, leur utilisateur, leur heure de création, leur heure d’actualisation ainsi que leur rôle exclusif ou non exclusif. Inspectez ensuite le processus correspondant et les journaux du service sur l’hôte indiqué, plutôt que de vous fier uniquement à l’ancienneté du verrou.

Les verrous obsolètes font souvent suite à un processus Restic interrompu, mais un pipeline interrompu n’est qu’une cause possible. Un processus recevant un signal incorrect peut laisser un état ressemblant à celui d’une tâche distante encore en cours.

Si le PID est actif et que les journaux progressent, attendez ou arrêtez la tâche via son gestionnaire de services ; ne déverrouillez pas le dépôt sous le processus. Si le processus est absent et que l’hôte n’a pas redémarré la même tâche, le verrou devient un candidat obsolète. Si l’hôte est inaccessible ou si la vue du backend est incohérente, l’état reste invérifié et aucune action destructive n’est justifiée.

Faites la distinction entre les quatre signatures de verrou

Un processus d’écriture actif dispose d’un processus correspondant, d’une activité récente dans les journaux et d’un verrou qui s’actualise. Une sortie incorrecte se caractérise par l’absence de processus actif et par un horodatage de verrou fixe après l’arrêt de l’hôte ou du conteneur. Un retard du backend apparaît lorsque les clients ne sont pas d’accord sur la liste des verrous ou lorsque les horodatages accusent un retard par rapport à l’activité connue du dépôt. Une opération de maintenance inachevée se manifeste par un verrou exclusif et par un journal de vérification ou de purge qui continue de changer.

Un vaste ordre de dépannage Restic maintient séparées les branches concernant les verrous du dépôt, les échecs de purge et une éventuelle corruption, afin de ne pas appliquer une correction de verrou obsolète à un problème de stockage.

Testez une signature à la fois. Confirmez d’abord que le processus est actif, comparez ensuite les horodatages et les journaux, puis vérifiez l’accessibilité du backend et l’horloge, avant d’inspecter la maintenance. Si deux signatures restent plausibles, conservez le verrou et examinez la branche la plus sûre ; le déverrouillage n’est pas un test de diagnostic, car il modifie la protection que vous essayez de comprendre.

Supprimez uniquement un verrou dont l’obsolescence est prouvée

Avant de déverrouiller, vérifiez une nouvelle fois chaque client, contrôleur d’automatisation, hôte de conteneur et service côté dépôt. Enregistrez la liste actuelle des verrous et les journaux récents. Utilisez la commande normale de suppression des verrous obsolètes, et non une option de suppression globale ou de désactivation des verrous, car la procédure standard est conçue pour laisser en place les verrous actifs.

Un échec réel lié à un verrou obsolète peut interrompre une planification de sauvegarde pourtant établie, mais l’ancienneté d’un cas particulier ne définit pas un seuil universel de suppression sans risque.

Si la commande standard supprime l’enregistrement obsolète et qu’aucun verrou ne réapparaît immédiatement, passez à une liste du dépôt en lecture seule. Si elle refuse d’agir parce que le verrou est actif, arrêtez-vous et trouvez son propriétaire. Si un nouveau verrou apparaît aussitôt, un planificateur ou un conteneur redémarré est toujours en cours d’exécution ; désactivez cette source avant de tenter une autre réparation.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Retestez l’opération d’origine et surveillez la réapparition du problème

Exécutez la même opération que celle qui a échoué, en enregistrant la progression et le statut de sortie. Observez l’apparition du verrou, son actualisation pendant l’exécution de la tâche et sa disparition après une sortie correcte. Laissez ensuite s’exécuter un cycle planifié normal. Cela reproduit le déclencheur d’origine et apporte une preuve plus solide qu’une simple liste réussie du dépôt.

Si le dépôt passe en lecture seule ou si la maintenance échoue après la suppression du verrou, suivez plutôt la procédure de récupération après une purge interrompue au lieu de déverrouiller à répétition.

La récupération est confirmée lorsque deux cycles correspondant à la charge d’origine s’achèvent, que chaque verrou est actualisé pendant l’activité puis supprimé à la fin, et qu’une vérification du dépôt ou une restauration d’échantillon fonctionne normalement. Faites remonter le problème si les verrous réapparaissent après des sorties correctes, si les clients ne sont pas d’accord sur l’état du backend ou si la vérification signale des objets de dépôt manquants ou endommagés. Maintenez le verrouillage activé pendant toute l’enquête.