Отказоусточивость архивов BorgBackup

https://unixsheikh.com/articles/how-i-store-my-files-and-why-you-should-not-rely-on-fancy-tools-for-backup.html

Познавательная статья. Главное, не докатится до этого :=) -

Это было похоже на то, что мир перестал двигаться. «Нееееееееет!» - закричал я, отчаянно прыгая в полном недоумении. «Этого не может быть! Этого не может быть! Что я только что сделал !? »

Хорошо понимаю этого автора. Но все же, что насчет сабжа?

BorgBackup, насколько понял, подвергает исходные файлы некоторой обработке, например, сжатию. Можно, конечно, не сжимать, но все равно бекап не похож на исходные файлы, и отсюда возникает сабж.

Он данные разбивает на небольшие блоки и работает уже с ними https://borgbackup.readthedocs.io/en/stable/internals/data-structures.html

Если есть подозрение на битый архив то есть borg check https://borgbackup.readthedocs.io/en/stable/usage/check.html

Для RSnapshot это не столь критично, поскольку он ничего не делает с исходными файлами, просто тупо копирует и все.

Но у borg коэффицент дедупликации данных выше. А как ты сможешь эффективно дудуплицировать данные без разбития их на маленькие блоки ?
У всего есть свои недостатки, поэтому архив borg нужно хранить на отказоустойчивом RAID.

И отказоустойчивость нужно организовывать не на уровне borg, а на уровне файловой системы и ниже.

что произойдет с архивом BorgBackup, если повредится или потеряется один из его файлов или инкрементов?

Архив поломается. Возможно, даже целиком, все записи.

Архив поломается. Возможно, даже целиком, все записи.

Опаньки! Это очень серьезный минус при всех плюсах Borg :-(
И даже если я поставлю его на RAID, все равно страшновато.
i-rinat, спасибо что подсказали. Можно даже сказать, что «уберегли».

Может, посмотреть в сторону ZFS? Она тоже умеет бекапировать, но как именно, подробно пока не разбирался.

Samamy

Если есть подозрение на битый архив то есть borg check

Чек это хорошо, но вот восстановления битого архива в нем вроде нет? Так что толку узнать, что архив битый?

поэтому архив borg нужно хранить на отказоустойчивом RAID.

Если я по невнимательности, или какая-то прога случайно удалит важный файл из архива Borg, то даже RAID не поможет.

Поэтому нельзя опираться ТОЛЬКО на одну утилиту. Делай rsync/архивируй tar/используй другую утилиту для бекапа. 3-2-1 никто не отменял.

Это очень серьезный минус

Это неизбежность для всех хранилищ, использующих дедупликацию. Если вместо того, чтобы хранить одни и те же данные в виде нескольких копий, хранишь их в одном месте, повреждения данных в этом месте ломает всё. Или если повреждается информация о том, что где лежит, с данными можно попрощаться, хотя казалось бы именно данные-то целы.

Может, посмотреть в сторону ZFS?

Я разрешаю смотреть в сторону ZFS.

Поэтому нельзя опираться ТОЛЬКО на одну утилиту.

У меня не многоэтажный дата-центр :=), а всего лишь один домашний бекап-сервер с 2-мя дисками

Я разрешаю смотреть в сторону ZFS.

Посмотрел, и туже возник вопрос: что выгоднее - RAID 1 или сопоставимый ZFS ?
Здесь тоже озадачились этим вопросом.

Так что толку узнать, что архив битый?

Если регулярная проверка архива прошла успешно, шансов на то, что что-то там поломалось за время хранения, становится исчезающе мало. Если испортились данные в простой копии, этого не узнать никак.

восстановления битого архива

Существуют файловые системы с избыточным кодированием. Обычно они FUSE. Из ядерного я только про dm-verity слышал, но там только проверка целостности данных, без восстановления.

Если я по невнимательности, или какая-то прога случайно удалит важный файл из архива Borg

Если я правильно понял документацию, borg можно настроить для работы в виде сервера, который позволяет только добавлять данные, но не удалять. В таком режиме просто не получится случайно удалить данные. Для этого придётся логиниться на другую машину, возможно даже не по сети, и вручную удалять файлы.

mdraid и ZFS распространяются бесплатно.

Если регулярная проверка архива прошла успешно, шансов на то, что что-то там поломалось за время хранения, становится исчезающе мало.

Ну да, только это удачный случай. А если произойдет наоборот?

i-rinat, у вас, случаем нет статистики Borg по сжатию какой-нибудь среднестатистической файлопомойки?
В разы вряд ли, имхо, но проценты тоже интересны.

Наоборот? В смысле, выяснится, что есть ошибка? Тогда ой, если это был единственный бекап. Но в таком случае хотя бы есть текущие данные, поэтому бекап можно пересоздать. Проблема только в том, что история изменений потеряется.

Если есть бекап бекапа, то можно взять оттуда, а уже поверх накатить ещё один архив, уже с текущей версией данных.

Ну это ладно. По крайней мере, мне понятно что в случае с borg происходит. А что произойдёт, если что-то испортится в бекапе rsnapshot? Там есть проверка целостности?

По дефолту в borg вообще сжатие выключено, так что экономия будет нулевая. Если сжатие включать, то степень сжатия будет сильно зависеть от вида файлов. Нет каких-то «среднестатистических» файлов. У всех они разные. Возможно, ты видеофайлы бекапишь, а они не сжимаются. Возможно, ты бекапишь промежуточные результаты отладочных сборок программ; они сжимаются очень хорошо, раз в 4-5.

Так-то оно да, но dedup/прозрачное сжатие/шифрование ВМЕСТЕ простыми не бывают. А если сюда рядом еще возможность монтирования/быстрого доставания отдельного файла из бэкапа подкрутить - то всё, тушите свет.

Понятное дело можно густо обмазаться скриптами, но так ты будешь тратить время на поддержание самописной системы резервного копирования.

Простой и кондовый tar.gz/tar.gz.gpg неплох ровно до того момента как ты начинаешь задумываться о том, как малой кровью реализовать фичи описанные выше.

Ну, на правах бояниста и капитана очевидности, вне зависимости от того какой системой резервного копирования пользуешь надо помнить правило про три вида людей, работающих с бэкапами.

1) те кто ещё не делает резервные копии;
2) те, кто уже делает;
3) те, кто уже делает и проверяет сделанные бэкапы на возможность восстановления;

А что произойдёт, если что-то испортится в бекапе rsnapshot? Там есть проверка целостности?

Проверки целостности уже имеющегося бекапа в RSnapshot увы, нет.
Есть несколько другое: поскольку RSnapshot базируется на rsync, можно использовать ключ -c, и тогда в процессе бекапирования каждый выходной файл будет сравниваться с исходным.
Т.е. будем иметь полную гарантию, что скопировалось без ошибок.
Правда тормоза, понятное дело, при этом будут изрядные.

4) Еще те, кто уже собрался делать бекап, но чуть-чуть не успел :-)

Есть облака. Лей вторую копию бэкапа туда(пошифрованную конечно)

-c указывает rsync вычислять хеш файла, чтобы понять, изменился он или нет. Предположим, что файл изменился. Rsync прочитает старый файл, поймёт, что хеш поменялся, запишет новый файл вместо старого. Если в этот момент на накопитель данные запишутся с тихой ошибкой, даже проверка сразу же после записи ничего не найдёт, потому что данные будут читаться из ОЗУ. Чтобы действительно проверить целостность после записи, нужно сбросить буферы ОС, принудить накопитель записать данные, сбросить буферы накопителя, прочитать файл заново, сравнить.

Ну, не знаю, неужели эта проверка сделана так топорно, что для достоверного сравнения надо сбрасывать буфера.
Тогда получается, что и любому сравнению доверять нельзя.

Есть облака. Лей вторую копию бэкапа туда(пошифрованную конечно)

Обычно там или платно, или малый объем. А чтобы на халяву и много, надо скакать каждый месяц с одно акка на другой, утомляет...

Если есть подозрение на битый архив то есть borg check

Чек это хорошо, но вот восстановления битого архива в нем вроде нет? Так что толку узнать, что архив битый?

Вроде как «восстановление» - borg check --repair, но не факт что прям спасет данные

Если я по невнимательности, или какая-то прога случайно удалит важный файл из архива Borg, то даже RAID не поможет.

Для этого есть borg serve --append-only https://borgbackup.readthedocs.io/en/stable/usage/serve.html
И очень аккуратно ходить на этот хост.

Тогда получается, что и любому сравнению доверять нельзя.

Конкретно опция -c не предназначена для контроля целостности. Для контроля нужно сохранение хешей где-то рядом с данными. Желательно сделать выключить-включить питание перед проверкой. Так надёжнее, чем верить, что накопитель действительно записал буфера. Они же могут врать.

Не среднестатистическая файлопомойка, а бекапы ОС, но если подобрать параметры под данные при бекапе то можно добиться хорошего коэффицента, у меня для примера следующие параметры --chunker-params 10,20,15,4095 --compression zstd,9 https://borgbackup.readthedocs.io/en/stable/internals/data-structures.html#chunker-details
И такие результаты:

------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
All archives:                2.89 TB              1.04 TB            189.85 GB

                       Unique chunks         Total chunks
Chunk index:                 7371441             46957821

Мда, так и не пришел к окончательному выводу по поводу Rasnapshot vs Borgbackup.

Пока выигрывает первый хотя бы потому, что принцип его наипростейший, не модифицирует данные, а складывает как есть, а если что-то испортится, то только оно, не потянет за собой что-то.
И что его уже давно юзаю :=)


Samamy: Ну если сжимает в 3 раза, то это конечно очень круто.
Но у меня слабая машинка - допотопный Атом, а Borg требует ресурсов от проца, а Rasnapshot вообще их не требует.