Restic: árvore e5457a72: arquivo "XX": tamanho de metadados (8770356) e soma de tamanhos de blob (8770808) não correspondem
Oi,
Acabei de atualizar para o restic 0.9 e descobri que o restic agora relata erros para o meu repo existente (que estava ok com o 0.8.3 e não foi alterado após a atualização):
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
Provavelmente os arquivos foram alterados durante a execução do backup.
Resultado de restic version
restic 0.9.0 compiled with go1.10.2 on linux/amd64
Como você executou o Restic exatamente?
restic check
Qual backend / servidor / serviço você usou para armazenar o repositório?
diretório local e rest-server
Comportamento esperado
Eu entendo que o restic não pode fazer nada para garantir que o backup seja consistente (por exemplo, se alguns arquivos dependentes têm conteúdo compatível).
Mas tenho quase certeza de que o restic deve garantir que seu próprio repositório seja consistente nesse caso (os metadados do repositório devem corresponder aos dados do repositório). Se algo foi anexado ao arquivo após stat sido chamado, mas antes de todo o arquivo ser lido, provavelmente o restic deverá ler apenas até o tamanho de arquivo esperado ou apenas atualizar os metadados com o número de bytes que foram realmente lidos.
PS. Provavelmente, esse problema foi corrigido no 0.9 e isso não acontecerá com novos instantâneos.
Mas infelizmente restic rebuild-index não corrige isso.
dionorgua
Todos 5 comentários
Eu ia abrir exatamente a mesma edição que você @dionorgua , você me bateu por 11 min. : +1:
Tenho os mesmos erros em meu repo (veja abaixo) e compartilho a sensação de que eles não devem ser erros e que o restic deve lidar com isso normalmente. Não há nada que um software de backup possa fazer sobre os arquivos que mudam nele, além de avisar que isso aconteceu durante o processo de backup. Mas mais tarde, quando check é executado, não devem ser erros ou mesmo relatados novamente?
Os resultados da verificação v0.9.0 são executados em um repositório no qual a v0.8.3 não relata nenhum erro.
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
em 22 mai. 2018
Eu concordo, isso deve ser um aviso ou não ser mostrado. Não há nada que os usuários possam (ou precisem) fazer.
É um bug no código do arquivador antigo, que gravou o tamanho errado no repositório quando o arquivo foi anexado enquanto o restic o estava lendo. O novo arquivador não faz isso e todas as outras funções funcionarão bem (elas apenas usam o tamanho correto, a soma dos pedaços do arquivo).
fd0
em 22 mai. 2018
Como lidar com esse problema? Está fazendo com que minhas verificações automáticas semanais falhem em vários de meus repositórios de backup.
Aqui está o resultado da minha "verificação do restic" - estou fazendo isso por meio da imagem do docker do 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
em 15 jul. 2018
Essa é uma boa pergunta! Todos os meus repos, exceto um, estão com erro agora ... pensando em desabilitar o estágio de verificação por completo, mas, novamente, era e será uma boa maneira de detectar possíveis regressões futuras. Difícil dizer qual é o melhor caminho a seguir ...
@ fd0 , este é um bug muito sério. Existe alguma solução alternativa para tornar os repositórios silenciosos novamente?
zcalusic
em 15 jul. 2018
Desculpe por isso, desativei o check-in # 1887. Você pode selecionar o commit se desejar.
fd0
em 15 jul. 2018
Questões relacionadas
jpic
·
3Comentários
viric
·
5Comentários
whereisaaron
·
3Comentários
kontakm
·
4Comentários
rakor
·
5Comentários
Comentários muito úteis
Eu concordo, isso deve ser um aviso ou não ser mostrado. Não há nada que os usuários possam (ou precisem) fazer.
É um bug no código do arquivador antigo, que gravou o tamanho errado no repositório quando o arquivo foi anexado enquanto o restic o estava lendo. O novo arquivador não faz isso e todas as outras funções funcionarão bem (elas apenas usam o tamanho correto, a soma dos pedaços do arquivo).