Как сократить бэкап (90% — файлы дистрибутива)?

Question

[Ярослав]

Если делаем бэкап какой-то виртуалки, большая часть бэкапа - будут стандартные файлы, вроде /bin/ls итд. Одинаковые на миллионах систем (и даже в пределах компании они одинаковые на многих машинах).

Напрашивается решение - минимизировать архивы. Смотрим каждый файл, берем его хеш, и как-то централизованно проверяем. Если этот хеш встречается много раз - просто удаляем этот файл из архива (помечая, что в том месте был файл с таким-то хешем). При распаковке заполняем эти хеши настоящими файлами (например, выкачивая их из сервиса по хешу, или, например, скачивая .deb где есть файл с этим хешем).

Есть ли какой-то софт или сервис для этого?

P.S.
Да, иногда можно обойтись инкрементальными бэкапами чтобы частично решить эту проблему, или использовать LXC overlayfs для виртуалок. Но интересует именно решение на уровне архивов.

update:
сделал свой велосипед - утилита hashget для простой дедупликации.
Статья на хабре: Сократить бэкапы на 99.5% с hashget

Answer 1

[АртемЪ]

Дедупликация в системе хранения архивов, или система архивации с дедупликацией. У меня например пара десятков VHD тестовых windows виртуалок лежит на небольшом SSD. И работают шустро ибо SSD и умещаются на диск который значительно меньше суммы размеров этих VHD.

Но интересует именно решение на уровне архивов

Пример архиватора - zpaq Кроме собственно банального сжатия - дедупликация, поддержка удаленных архивов.

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

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

Comments

[Ярослав]

А чем дедупликацию делаете?

[АртемЪ]

Ярослав Поляков, Есть куча разных вариантов.
Если архив - я в ответе указал архиватор с поддержкой дедупликации.
Если файловая система - у меня винда, штатными виндовыми средствами.
Enable-DedupVolume D:
В линуксе тоже есть подобный вещи, разной степени стабильности.

[d'Ivan]

Ярослав Поляков, есть разные программы с поддержкой дедупликации. Borg Backup и много других, (бес)платных.

Answer 2

[Ambrosian]

Дифференциальный бэкап.

Comments

[Ярослав]

Это воркэраунд, да. (про него и написал, как инкрементальный). Но все таки это немного хуже - очень много дублирования:
- Первый бэкап для виртуалки будет полным (хотя все файлы можно с debian.org скачать)
- Если виртуалок много, и они все почти одинаковые, то у каждой будет полный первый бэкап (хотя с этой идеей сокращения их по хешам, можно все сократить почти до нуля).

Бэкапы же часто делаются, долго хранятся - но редко используются :-) Хочется выжать максимум из этого (чтобы были маленькими, легко копировать, хранить. И пусть даже распаковываются чуть дольше).

[АртемЪ]

Ярослав Поляков,

Первый бэкап для виртуалки будет полным (хотя все файлы можно с debian.org скачать)

Эта проблема не решается в принципе.

Если виртуалок много, и они все почти одинаковые, то у каждой будет полный первый бэкап

Эта проблема полностью решается дедупликацией.

[Ярослав]

Почему первая проблема не решается в принципе? Если по каждому файлу хранить только URL архива, где он есть - то легко "разжать" его всегда из сотни байт до пары мегабайт.

[Ambrosian]

Ярослав Поляков, а зачем?
дистрибутив на фоне остальной части бэкапа (а бэкапов нужно держать несколько, не только последний) - это немного.
тем более для современного железа

[АртемЪ]

Ярослав Поляков,

Если по каждому файлу хранить только URL архива, где он есть - то легко "разжать" его всегда из сотни байт до пары мегабайт.

Для этого нужно обеспечить гарантированное хранилище.

Т.е при попытке распаковки у вас может -
1)отсутствовать доступ в интернет.
2)доступ в интернет может быть очень медленным
3)данный URL может быть недоступен.
4)по данному URL может лежать совершенно другой файл.

[nrgian]

Ярослав Поляков,

- Первый бэкап для виртуалки будет полным (хотя все файлы можно с debian.org скачать)

Как назло, к тому времени, когда бэкап понадобится - та версия Дебиана уже будет списана в архив и репозитарии прикладных приложений будут отключены.

Answer 3

[Дмитрий]

Full-diff-inc на уровне бекапа. Но это не учитывает другие бекапы. Тут вам поможет дедупликация, но с ней нужно быть осторожно.

Comments

[Ярослав]

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

Хочется именно чтобы архиватор знал, что "этот файл публичный, широко распространенный, его можно выкачать с debian.org". Одна такая глобальная база для всего человечества. Тогда можно и паковать быстрее гораздо, и использование проще будет.

[Дмитрий]

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

[Ярослав]

Вот в имеющихся условиях - да, наверное это правильное решение. Ну или overlayfs (когда в файлухе виртулки - только данные). Но это - с учетом имеющихся условий. А мне интересно, что, вдруг условия другие и может быть можно просто простую и надежную дубовую схему с .tar.gz так оптимизировать.

[АртемЪ]

Ярослав Поляков,

Хочется именно чтобы архиватор знал, что "этот файл публичный, широко распространенный, его можно выкачать с debian.org"

Ну это в принципе невозможно.
Архиватор ничего не может знать. Знать может только человек.

А если бы и знал - сегодня этот файл распространенный, а завтра его не найдешь -распаковка будет негарантированной. Т.е если это реализовать архив будет распаковываться в некоторых случаях. Но не факт что будет.

[d'Ivan]

Ярослав Поляков, на то это и бекап, что он не полагается на внешние факторы, такие как наличие файла в интернете.

Answer 4

[CityCat4]

Если говорить о бэкапе скажем виртуалок - то мне очень понравилась Nakivo Backup. Дедупликацию делает средствами гипера, первый бэкап ессно полный, все остальные (ну, как настроишь) - инкрементные. Умеет только виртуалки.