Comment déterminer si un échec de sauvegarde provient du dépôt ou des fichiers source

Testez indépendamment les lectures du dépôt à partir d’une petite source stable, puis testez les chemins de source suspects vers un dépôt temporaire neuf.

La décision est importante lorsqu’une sauvegarde s’arrête en raison d’erreurs de lecture, de somme de contrôle, d’autorisation, de pack ou d’index. Les deux états en concurrence sont les dommages affectant le dépôt ou la destination, et les erreurs de lecture, d’autorisation ou de modification des fichiers source. Commencez avec une configuration enregistrée et des données jetables, observez une seule branche à la fois et arrêtez-vous si le test accroît le risque de perte de données, d’autorisation ou de disponibilité.

Distinguer les dommages du dépôt ou de la destination des erreurs de lecture, d’autorisation ou de modification des fichiers source

Notez l’environnement avant toute modification : versions des logiciels et des micrologiciels, identités des appareils, chemin de montage ou chemin réseau, espace libre, autorisations et symptôme observable. La référence initiale doit conserver suffisamment de détails pour reproduire un arrêt de sauvegarde dû à des erreurs de lecture, de somme de contrôle, d’autorisation, de pack ou d’index.

Le premier candidat est un dommage du dépôt ou de la destination. Le second correspond à des erreurs de lecture, d’autorisation ou de modification des fichiers source. La séquence de dépannage Restic actuelle définit le mécanisme ou la limite de commande utilisés lors du test ; elle ne remplace pas l’observation effectuée sur ce serveur personnel précis.

Rédigez la condition d’acceptation et la condition d’arrêt avant d’exécuter le test discriminant. Une réussite doit modifier les éléments probants prédits par une branche tout en laissant les services indépendants inchangés ; un échec doit ramener le système à l’état enregistré plutôt que déclencher une suite de corrections spéculatives.

Exécuter un seul test discriminant contrôlé

Utilisez ce test discriminant : vérifiez le dépôt et effectuez une restauration canari, puis sauvegardez un ensemble de test fixe et lisible et inspectez séparément les erreurs de source. Gardez constants la charge, le client, le chemin, l’ensemble de fichiers et le calendrier afin que le résultat soit attribuable à la variable modifiée.

Utilisez un flux de travail Restic indépendant pour sélectionner le champ qui peut réellement distinguer les branches, puis capturez son horodatage, son état de sortie, le texte de l’erreur, l’identité de l’appareil ou de l’instantané, la latence, les octets transférés, les autorisations et l’état de récupération. Une sortie de commande propre ne suffit pas lorsque l’identité, la durabilité ou l’état de l’application constitue l’élément vérifié.

Répétez le test une fois après un redémarrage, une reconnexion, un remontage ou un cache froid lorsque cet événement faisait partie de la condition initiale. Si la première exécution est destructive ou si l’environnement ne peut pas être restauré, arrêtez-vous et reproduisez le problème sur une copie jetable.

restic check
restic restore latest --include /canary --target /tmp/restore-test

Interpréter la branche étayée par les éléments probants

RÉUSSITE : les vérifications ou restaurations du dépôt échouent pour plusieurs sources, ou seuls certains chemins source échouent tandis que le dépôt reste sain. Notez la version exacte, l’identité et la charge qui ont réussi afin que la conclusion reste conditionnelle plutôt que de devenir une affirmation universelle.

ÉCHEC : les problèmes de réseau et de mémoire affectent les deux tests ; reproduisez donc le problème localement avant de déclarer l’un ou l’autre côté endommagé. Un échec ne prouve pas automatiquement la branche opposée lorsque le réseau, la mémoire, les autorisations ou la cohérence de la source peuvent influencer les deux tests ; isolez ces dépendances communes avant toute escalade.

RÉSULTAT EXCEPTIONNEL OU AMBIGU : suspendez la maintenance destructive, copiez les journaux et protégez le dernier état sain du dépôt. Conservez les journaux et n’exécutez aucune commande de réparation, de purge, de destruction, de repartitionnement ou de modification récursive des propriétaires tant qu’une copie récupérable n’existe pas.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Appliquer l’action correspondante et reproduire l’échec initial

Appliquez l’action correspondant à la branche observée, puis répétez la condition initiale plutôt qu’un scénario simplifié. La décision n’est valable que lorsque les vérifications ou restaurations du dépôt échouent pour plusieurs sources, ou que seuls certains chemins source échouent tandis que le dépôt reste sain pendant deux cycles ou lors du redémarrage, de la mise en veille, de l’interruption ou de la transition de charge concernée.

Utilisez le dimensionnement des packs Restic pour vérifier le flux de travail dépendant le plus proche, mais conservez le déclencheur initial inchangé. Les jeux de données, partages, conteneurs, utilisateurs et points de récupération indépendants doivent conserver leurs accès et leurs délais précédents.

La limite d’arrêt est explicite : si les problèmes de réseau et de mémoire affectent les deux tests, reproduisez donc le problème localement avant de déclarer l’un ou l’autre côté endommagé, revenez à la dernière configuration vérifiée, conservez les éléments probants et ne passez à un test approfondi de la plateforme ou du matériel que lorsque la branche est reproductible.

Une fois le résultat cible obtenu, comparez-le à la fréquence de vérification afin que la correction ne déplace pas le risque vers un service voisin. Un test cible réussi accompagné d’un nouvel échec de sauvegarde, d’identité, de délai d’attente ou de disponibilité reste une modification échouée.

FAQ

Pour isoler une défaillance de sauvegarde, les recherches restantes portent généralement sur les questions suivantes : une vérification réussie du dépôt peut-elle prouver la couverture de la source, faut-il réparer immédiatement le dépôt et quelles erreurs de source sont faciles à manquer ? Les réponses ci-dessous maintiennent ces cas particuliers séparés de la décision principale.

La limite d’acceptation ne change pas : les vérifications ou restaurations du dépôt échouent pour plusieurs sources, ou seuls certains chemins source échouent tandis que le dépôt reste sain. Si une condition ultérieure modifie le système de fichiers, l’identité, le chemin réseau ou la version de l’application, répétez uniquement le test discriminant concerné par cette modification.

Arrêtez d’élargir l’expérience lorsque les problèmes de réseau et de mémoire affectent les deux tests, et reproduisez donc le problème localement avant de déclarer l’un ou l’autre côté endommagé. À ce stade, suspendez la maintenance destructive, copiez les journaux et protégez le dernier état sain du dépôt ; conservez les éléments probants avant de transmettre le problème au responsable de la plateforme, du stockage ou du matériel.

Une vérification réussie du dépôt peut-elle prouver la couverture de la source ?

Non. Elle prouve les propriétés du dépôt, mais pas que chaque fichier source prévu était lisible ou inclus.

Faut-il réparer immédiatement le dépôt ?

Pas avant d’avoir créé, lorsque c’est possible, une copie de sécurité et confirmé la catégorie de défaillance.

Quelles erreurs de source sont faciles à manquer ?

Les refus d’autorisation, les fichiers qui disparaissent, les secteurs illisibles, les fichiers clairsemés et les problèmes de cohérence de l’application peuvent être masqués dans les résumés.

Le diagnostic est terminé lorsque la même charge amène les éléments probants à suivre les dommages du dépôt ou de la destination, ou les erreurs de lecture, d’autorisation ou de modification des fichiers source, et que l’action correspondante supprime le symptôme initial sans en créer un second. Si aucune branche ne reste reproductible, conservez les journaux et l’état enregistré intacts ; l’incertitude est une raison de transmettre le problème, pas d’empiler davantage de corrections.