Restic: дерево e5457a72: файл «XX»: размер метаданных (8770356) и сумма размеров больших двоичных объектов (8770808) не совпадают
Привет,
Только что обновился до restic 0.9 и обнаружил, что restic теперь сообщает об ошибках для моего существующего репо (это было нормально с 0.8.3 и не было изменено после обновления):
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
Вероятно, файлы были изменены во время резервного копирования.
Вывод restic version
restic 0.9.0 compiled with go1.10.2 on linux/amd64
Как именно вы пробежали рестик?
restic check
Какой бэкэнд / сервер / сервис вы использовали для хранения репозитория?
локальный каталог и rest-сервер
Ожидаемое поведение
Я понимаю, что restic не может ничего сделать для обеспечения согласованности резервного копирования (например, что несколько зависимых файлов имеют совпадающее содержимое).
Но я почти уверен, что restic должен в этом случае убедиться, что его собственный репозиторий согласован (метаданные репозитория должны соответствовать данным репозитория). Если что-то было добавлено к файлу после вызова stat , но до того, как весь файл будет прочитан, вероятно, restic должен читать только до ожидаемого размера файла или просто обновлять метаданные с количеством байтов, которые были фактически прочитаны.
PS. Вероятно, эта проблема исправлена в версии 0.9, и этого не будет для новых снимков.
Но, к сожалению, restic rebuild-index не исправляет.
dionorgua
Все 5 Комментарий
Я собирался открыть точно такой же выпуск, что и ты @dionorgua , ты опередил меня на 11 мин. : +1:
У меня такие же ошибки в моем репо (см. Ниже), и я разделяю мнение, что это не должно быть ошибок, и restic должен с ними справиться. Программное обеспечение для резервного копирования ничего не может сделать с файлами, которые изменяются в нем, кроме предупреждения о том, что это произошло во время процесса резервного копирования. Но позже, когда запускается check , это не должно быть ошибкой или даже сообщаться снова?
Результаты проверки v0.9.0 выполняются на репо, на котором v0.8.3 не сообщает об ошибках.
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
22 мая 2018
Я согласен, это должно быть предупреждением или вообще не отображаться. Пользователи ничего не могут (или должны) делать.
Это ошибка в старом коде архиватора, который записывал неправильный размер в репо, когда файл был добавлен, пока restic его читал. Новый архиватор этого не делает, и все остальные функции будут работать нормально (они просто используют правильный размер, сумму фрагментов файлов).
fd0
22 мая 2018
Как решить эту проблему? Это приводит к сбою моих еженедельных автоматических проверок в нескольких репозиториях с резервными копиями.
Вот результат моей "restic check" - я делаю это через рестик-образ докера.
...
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
15 июл. 2018
Это хороший вопрос! Все мои репозитории, кроме одного, сейчас ошибочны ... думаю о том, чтобы полностью отключить этап проверки, но опять же, это был и будет хорошим способом обнаружения возможных будущих регрессов. Трудно сказать, как лучше всего двигаться вперед ...
@ fd0 , это довольно серьезная ошибка, есть ли какое-то решение, чтобы снова отключить репозиторий?
zcalusic
15 июл. 2018
Извините за это, я отключил проверку в №1887. Вы можете выбрать фиксацию, если хотите.
fd0
15 июл. 2018
Смежные вопросы
rakor
·
5Комментарии
axllent
·
4Комментарии
whereisaaron
·
3Комментарии
jpic
·
3Комментарии
stevesbrain
·
3Комментарии
Самый полезный комментарий
Я согласен, это должно быть предупреждением или вообще не отображаться. Пользователи ничего не могут (или должны) делать.
Это ошибка в старом коде архиватора, который записывал неправильный размер в репо, когда файл был добавлен, пока restic его читал. Новый архиватор этого не делает, и все остальные функции будут работать нормально (они просто используют правильный размер, сумму фрагментов файлов).