Pourquoi une sauvegarde Restic se bloque-t-elle lorsqu’un autre hôte commence à purger les sauvegardes ?

La sauvegarde se bloque généralement parce que l’opération de nettoyage doit disposer d’un contrôle exclusif du dépôt partagé ; le deuxième hôte ne peut donc pas poursuivre dans le même état du dépôt à ce moment-là.

Dans une configuration domestique multihôte, le moment où le problème survient est le meilleur premier indicateur : la sauvegarde progresse normalement, une autre machine lance le nettoyage, puis la sauvegarde attend ou signale un verrou. Confirmez le propriétaire du verrou et consultez le journal de maintenance actif avant toute intervention. Laissez le nettoyage se terminer ou arrêtez-le proprement depuis l’hôte qui le possède ; ne supprimez jamais son verrou depuis le client de sauvegarde en attente.

Confirmer que le nettoyage est bien le déclencheur exact

Enregistrez le journal de sauvegarde en attente ainsi que le journal de maintenance de l’hôte qui effectue le nettoyage, avec leurs horodatages. Listez les verrous du dépôt et faites correspondre l’hôte, le processus et l’état exclusif avec la tâche de nettoyage. La cause est confirmée lorsque la progression de la sauvegarde s’arrête après l’acquisition du dépôt par le nettoyage et reprend une fois ce verrou libéré.

Les opérateurs qui utilisent un même dépôt depuis plusieurs hôtes signalent une concurrence des verrous pendant le nettoyage, car cette opération de maintenance entre en conflit avec des planifications de sauvegarde autrement indépendantes.

Si la sauvegarde était déjà lente, si l’hôte chargé du nettoyage n’a jamais obtenu de verrou ou si les deux journaux s’arrêtent sur une erreur de stockage, ne forcez pas ce diagnostic. Vérifiez la disponibilité et la latence du backend ainsi que le processus de sauvegarde lui-même. L’explication par le verrou du nettoyage ne s’applique que lorsque le déclencheur, le propriétaire du verrou et le moment de sa libération concordent.

Considérer le verrou exclusif comme une limite de sécurité

Le nettoyage modifie le stockage du dépôt et nécessite donc une vue cohérente pendant son exécution. La sauvegarde en attente n’est pas nécessairement bloquée au sens habituel du processus ; elle peut simplement respecter le verrou de maintenance. La première question est de savoir si le nettoyage progresse, et non comment faire ignorer le verrou à la sauvegarde.

Une architecture avec dépôt partagé nécessite un responsable unique de la maintenance, car la maintenance à l’échelle du dépôt affecte tous les clients, même lorsque les données sources appartiennent à des hôtes différents.

Si les journaux du nettoyage progressent et que les entrées-sorties du dépôt continuent, laissez le verrou en place et attendez la fin de la tâche. Si la tâche est réellement bloquée, arrêtez-la correctement depuis l’hôte qui la possède et attendez une fermeture propre. Supprimer le verrou depuis un autre client alors que le nettoyage écrit encore transforme une attente contrôlée en chevauchement dangereux.

Récupérer la sauvegarde en attente sans contourner les verrous

La solution la moins intrusive consiste à attendre la fin du nettoyage. Si la sauvegarde dispose d’une politique de nouvelles tentatives limitée, laissez-la réessayer après la disparition du verrou exclusif. Lorsqu’il faut arrêter le nettoyage, utilisez le gestionnaire de services ou le superviseur de processus sur l’hôte qui le possède, attendez son arrêt, puis vérifiez que la liste des verrous a changé avant de redémarrer la sauvegarde.

La conservation peut être limitée à un hôte, mais la récupération physique de l’espace reste une opération sur le dépôt. Une politique de conservation limitée à l’hôte empêche de sélectionner les mauvais instantanés ; elle ne rend pas sûr l’exécution simultanée d’un nettoyage pour des clients de sauvegarde indépendants.

Relancez la sauvegarde en attente avec le verrouillage normal. Si elle se termine, la correction correspond à la cause confirmée. Si un autre nettoyage démarre immédiatement, désactivez la planification de maintenance en double. Si la sauvegarde se bloque encore sans verrou exclusif, cessez d’augmenter le nombre de tentatives et revenez aux diagnostics du backend, du réseau, de l’analyse de la source ou du processus.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Retester le chevauchement initial et définir la limite

Utilisez une fenêtre contrôlée avec des journaux complets. Lancez une sauvegarde normale, puis invoquez le contrôleur de maintenance prévu et vérifiez qu’il ne crée pas de chevauchement dangereux. Répétez dans l’ordre prévu en lançant d’abord le nettoyage et vérifiez que la sauvegarde attend ou se termine selon la politique configurée, puis réussit après la libération du verrou.

Si un nettoyage interrompu laisse le dépôt dans un état opérationnel différent, suivez le diagnostic d’un nettoyage interrompu plutôt que de considérer chaque panne ultérieure comme une simple concurrence.

La récupération est validée lorsque le chevauchement initial est géré de manière prévisible, que la sauvegarde se termine ensuite, que le nettoyage se ferme proprement et qu’un instantané de test reste restaurable. Escaladez le problème si le verrou ne s’actualise ou ne se libère jamais, si plusieurs hôtes continuent de lancer la maintenance ou si une vérification du dépôt signale des dommages. Ces résultats dépassent le simple cas d’un nettoyage actif en cours.