Третьего дня настроил Synology Hyper Backup для бэкапа фоток в mail.ru облако (платный аккаунт с WebDAV). Естественно, с шифрованием. Эта шайтан-машина молотила двое суток, а через три дня, при еженедельной проверке целостности, обнаружилось, что один чанк из 9200 не залился, хотя в логах от mail.ru ни одной ошибки, просто он решил не сохранять.
Наверное, для фоточек с котиками - небольшая потеря, но для монолитного бэкапа размером в полтерабайта это означает, что вся предыдущая загрузка пошла псу под хвост, т.к. у Hyper Backup нет возможности перезалить один хромой чанк.
Решение
В итоге принято решение вернуться на rclone, который пока показал себя неплохо, и при этом загружает и шифрует каждый файл отдельно. Под это дело агет выделил отдельный крошечный LXC-контейнер в кластере Proxmox и в виде вишенки на торте даже запилил индикатор прогресса в виде MQTT-сенсора для дашборда Home Assistant. Последний оказался неожиданно полезным ввиду неторопливости процесса, выглядит примерно так:
Хронология и раскопки в логах
Сам бы я несколько дней разбирался, что произошло, спасибо Клоду за диагноз:
Цепочка, по логам .75 (/volume1/@appdata/HyperBackup/log/synolog/synobackup.log):
21.08 19:34 первичная заливка в mail.ru началась
23.08 02:41 seed закончен (~31 ч), 124292 файла
23–25.08 инкременты 04:00 — успешно (v2, v3, v4)
25.08 06:00 ПЕРВАЯ еженедельная проверка целостности (вт 06:00)
25.08 06:09 "The backup target is found broken"
→ task 3: Backupable → ErrorDetect → RestoreOnly
26,27,28.08 04:00 "failed to init backup", errcode 2304, 0 сек
Конкретная поломка — в Guard/detect/error.log:
Missing file[Pool/0/0/833.bucket] on cloud target
Pointing to bad ci offset ... (5 записей)
В облаке пропал ровно один чанк-файл на 52 МБ из 9200. Проверил независимо, через rclone-ремоут mail.ru (не через WebDAV, которым ходит Hyper Backup) — файла действительно нет:
832.bucket.2 52436912 21:53:18
← 833.bucket отсутствует
833.index.2 203616 21:54:28
834.bucket.2 52435100 21:53:35
Соседний 833.index (203 КБ) на месте, все 830–839 на месте. Сверка списка облака: 9199 .bucket против 9200 .index, дырка одна — Pool/0/0/833.
При этом в логе заливки нет ни одной ошибки: HB запустил PUT 833.bucket.2 в 21:54:13, получил успех, через 15 секунд залил индекс и пошёл дальше. То есть mail.ru принял 52 МБ, отчитался «ок» и не сохранил объект. Это отказ на стороне облака, не сети и не NAS (в тот момент шло 5–6 параллельных заливок — вероятный, но не доказанный триггер).
Дальше сработала логика Hyper Backup: один потерянный чанк = вся цель помечена detect-bad, задача переводится в restore_only, и любой последующий запуск умирает на инициализации за 0 секунд. Инкременты 23–25 августа этого не замечали, потому что старые бакеты не перечитываются — нашла только проверка целостности.
Плохая часть: в Guard/detect/bad_ver_list_rec те же 5 чанков перечислены под всеми четырьмя версиями. Файлы, попавшие в 833-й бакет, с 21 августа не менялись, поэтому битые все 4 версии — «удалить повреждённые версии» здесь равно «удалить репозиторий».