Obnam vs. Duplicity — неудачные эксперименты

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

К примеру, у нас в компании, особо не экспериментируя, много лет работают на ура множество самописных скриптов, которые на выходе дают классические tar.gz архивы, которые, в дальнейшем, записываются на ленту . Из плюсов — уникальная неприхотливость и универсальность. Понятно, что есть множество минусов…

Когда нужен бэкап всего раздела не брезгуем и dump\restore, ну да это уже отступление.

В целях эксперимента, около года назад была налажена система создания бэкапов с помощью duplicity. И она вполне удачно работает радуя своими возможностями и некоторыми мелкими глюками в каждой новой версии. Нареканий к системе нет, действительно все работает, как часы, но тут на глаза попалась новость о выходе obnam. Не буду перечислять всех ее вкусностей, они есть по ссылке.

Прочитав возможности решено испытать систему в реальности. И тут возникла первая проблема — obnam существует в виде пакетов для Debian\Ubuntu, и начисто отсутствует для RHEK\CentOS. Исходный код нас не страшит, установив с сайта автора необходимые модули для python, и собрав сам obnam — пытаюсь пощупать систему в работе. Получаю вторую проблему, система не работает — т.е. вообще. Ковыряние в коде, переписка с автором и неоднократые попытки  проделать шаги сборки на различных конфигурациях машин — везде кроме CentOS\RHEL система работает. Параллельно были собраны rpm пакеты со всеми зависимостями, но …

В мейлисте obnam выясняется, что rpm уже лежат в epel-testing, хотя  их сборщик также (!) не смог заставить работать систему. На данный момент, как я понимаю, ведутся поиски решения данной проблемы, корни которой уходят в глубь реализации python для RHEL\CentOS.

Но это было лирическое отступление, а теперь к делу. Пришлось эксперимент перенести под Ubuntu. Что меня собственно интересовало.

  1. Скорость создания полного и последующих бэкапов
  2. Суммарный объем бэкапа
  3. Скорость извлечения из бэкапа
  4. Общее удобство пользования и всяческие плюшки

Вводные данные. Данные подлежащие бэкапу лежали на удаленной машине, объем данных 20Гб. Тесты проводились несколько дней — в первый день делалась полный бэкап, в последующие дни инкрементальный (в случае с obnam и его дедубликацией иного быть и не может)

 Скорость создания бэкапа

  • Duplicity создал полную версию архива за 3 с небольшим минуты (no-encryption, volume-size=500).
  • Obnam затратил на это более 20 минут.

Суммарный объем бэкапа

Напомню, исходные данные были 20Гб и много тысяч разнообразных файлов

  • Архив duplicity занимал около 14Гб
  • Архивная база obnam около 17Гб

Настройки obnam позволяют использовать любую программу для сжатия (—compress-with=PROGRAM). Я не указывал ничего, т.е. значение по умолчанию.

Скорость извлечения из архива

Задача достать иерархию папок за две разных даты. Грубо говоря, папку Folder от 29 и 30 октября.

  • Duplicity справился за примерно за 2 минуты в обоих случаях
  • Obnam чуть медленнее, примерно 5 минут

Удобство пользования

Крайне субъективный показатель, но пользоваться obnam мне показалось чуть удобнее. Безусловно, потенциал в программе очень даже существенный, но вот реализация хромает. И дело не в стабильности, Lars Wirzenius все же разберется со сложностями работы на RHEL-based платформах, дело в лаконичности и удобстве опций для работы с obnam.

Хотя Duplicity тоже очень достойный продукт 🙂 Но будем и дальше тестить obnam и следать за разработкой!