Restic: tree e5457a72: fichier "XX": la taille des métadonnées (8770356) et la somme des tailles d'objets blob (8770808) ne correspondent pas
Salut,
Je viens de mettre à jour vers restic 0.9 et j'ai trouvé que restic signale maintenant des erreurs pour mon dépôt existant (cela était correct avec la 0.8.3 et n'a pas été modifié après la mise à niveau):
error for tree e5457a72:
tree e5457a72: file "mail.err": metadata size (1085858) and sum of blob sizes (1085966) do not match
tree e5457a72: file "mail.info": metadata size (8770356) and sum of blob sizes (8770808) do not match
tree e5457a72: file "mail.log": metadata size (8770356) and sum of blob sizes (8770808) do not match
tree e5457a72: file "mail.warn": metadata size (1091226) and sum of blob sizes (1091334) do not match
Les fichiers ont probablement été modifiés pendant la sauvegarde.
Sortie de restic version
restic 0.9.0 compiled with go1.10.2 on linux/amd64
Comment avez-vous géré restic exactement?
restic check
Quel backend / serveur / service avez-vous utilisé pour stocker le référentiel?
répertoire local et serveur de repos
Comportement prévisible
Je comprends que restic ne peut rien faire pour s'assurer que la sauvegarde est cohérente (par exemple, que quelques fichiers dépendants ont un contenu correspondant).
Mais je suis à peu près sûr que restic devrait s'assurer que son propre référentiel est cohérent dans ce cas (les métadonnées du référentiel doivent correspondre aux données du référentiel). Si quelque chose a été ajouté au fichier après l'appel de stat , mais avant que le fichier entier ne soit lu, restic devrait probablement lire uniquement jusqu'à la taille de fichier attendue, ou simplement mettre à jour les métadonnées avec le nombre d'octets réellement lus.
PS. Ce problème est probablement résolu sur la version 0.9 et cela ne se produira pas pour les nouveaux instantanés.
Mais malheureusement, restic rebuild-index ne résout pas le problème.
dionorgua
Tous les 5 commentaires
J'étais sur le point d'ouvrir exactement le même numéro que vous @dionorgua , vous m'avez battu de 11 minutes. : +1:
J'ai les mêmes erreurs dans mon dépôt (voir ci-dessous) et partage le sentiment que cela ne devrait pas être des erreurs et que Restic devrait le gérer avec élégance. Un logiciel de sauvegarde ne peut rien faire contre les fichiers qui changent en dessous, à part l'avertissement que cela s'est produit pendant le processus de sauvegarde. Mais plus tard, lorsque check est exécuté, il ne devrait pas s'agir d'erreurs, ni même signalées à nouveau?
Les résultats de la vérification de la v0.9.0 s'exécutent sur un dépôt sur lequel la v0.8.3 ne signale aucune erreur.
check snapshots, trees and blobs
error for tree c1c7286d:
tree c1c7286d: file "panacea.dat": metadata size (5975885) and sum of blob sizes (5975910) do not match
error for tree 5908dec5:
tree 5908dec5: file "panacea.dat": metadata size (5425341) and sum of blob sizes (5425366) do not match
Fatal: repository contains errors
zcalusic
le 22 mai 2018
Je suis d'accord, cela devrait être un avertissement ou ne pas être montré du tout. Les utilisateurs ne peuvent (ou doivent) rien faire.
C'est un bogue dans l'ancien code de l'archiveur, qui écrivait la mauvaise taille dans le référentiel lorsque le fichier était ajouté pendant que Restic le lisait. Le nouvel archiveur ne fait pas cela, et toutes les autres fonctions fonctionneront très bien (elles utilisent juste la taille correcte, la somme des morceaux de fichiers).
fd0
le 22 mai 2018
Comment traiter ce problème? Cela provoque l'échec de mes vérifications automatiques hebdomadaires sur plusieurs de mes dépôts de sauvegarde.
Voici la sortie de mon "contrôle restic" - je le fais via l'image du docker restic.
...
Digest: sha256:9c851e0ba8a9c20ef853ee507af14c4d87c33661c25136262e97506a1cdc7a57
Status: Image is up to date for restic/restic:latest
ID Date Host Tags Directory
----------------------------------------------------------------------
8eb0175e 2018-02-28 21:01:38 internal-cluster /fisheye
a7848682 2018-03-31 09:28:09 internal-cluster /fisheye
8ad27273 2018-04-30 09:28:09 internal-cluster /fisheye
97d2e914 2018-05-31 09:28:12 internal-cluster /fisheye
96ba1cc7 2018-06-30 09:28:13 internal-cluster /fisheye
23ef9a4b 2018-07-08 09:28:11 internal-cluster /fisheye
76f8e70a 2018-07-09 09:28:12 internal-cluster /fisheye
74d46da4 2018-07-10 09:28:14 internal-cluster /fisheye
a893de2c 2018-07-11 09:28:12 internal-cluster /fisheye
7dbeb6c0 2018-07-12 09:28:13 internal-cluster /fisheye
8df2f318 2018-07-13 09:28:11 internal-cluster /fisheye
e7321bf1 2018-07-14 09:28:13 internal-cluster /fisheye
----------------------------------------------------------------------
12 snapshots
+ restic check
+ sudo -E docker run --rm -e AWS_ACCESS_KEY_ID=**** -e AWS_SECRET_ACCESS_KEY=**** -e RESTIC_PASSWORD=**** -v /mnt/efs/fisheye:/fisheye:ro -h internal-cluster --user root restic/restic -r s3:s3.amazonaws.com/redacted/restic/fisheye check
using temporary cache in /tmp/restic-check-cache-069761908
create exclusive lock for repository
load indexes
check all packs
check snapshots, trees and blobs
error for tree d93db471:
tree d93db471: file "atlassian-fisheye-2018-07-13.log": metadata size (52139444) and sum of blob sizes (52165018) do not match
error for tree 8d1b1f5f:
tree 8d1b1f5f: file "atlassian-fisheye-2018-04-30.log": metadata size (53418588) and sum of blob sizes (53426968) do not match
Fatal: repository contains errors
deweysasser
le 15 juil. 2018
Voilà une bonne question! Tous mes dépôts sauf un sont en erreur maintenant ... je pense à désactiver complètement l'étape de vérification, mais là encore, c'était et sera un bon moyen de détecter d'éventuelles régressions futures. Difficile de dire quelle est la meilleure façon d'aller de l'avant ...
@ fd0 , c'est un bogue assez sérieux, existe-t-il une solution de contournement pour rendre les dépôts silencieux à nouveau?
zcalusic
le 15 juil. 2018
Désolé pour cela, j'ai désactivé l'enregistrement # 1887. Vous pouvez choisir le commit si vous le souhaitez.
fd0
le 15 juil. 2018
Questions connexes
fd0
·
4Commentaires
TheLastProject
·
3Commentaires
RafaelAybar
·
3Commentaires
axllent
·
4Commentaires
e2b
·
4Commentaires
Commentaire le plus utile
Je suis d'accord, cela devrait être un avertissement ou ne pas être montré du tout. Les utilisateurs ne peuvent (ou doivent) rien faire.
C'est un bogue dans l'ancien code de l'archiveur, qui écrivait la mauvaise taille dans le référentiel lorsque le fichier était ajouté pendant que Restic le lisait. Le nouvel archiveur ne fait pas cela, et toutes les autres fonctions fonctionneront très bien (elles utilisent juste la taille correcte, la somme des morceaux de fichiers).