Ларс Вирзениус (Lars Wirzenius), один из студенческих товарищей Линуса Торвальдса, вовлечённый в развитие Linux с первых дней существования проекта (создатель Linux Documentation Project и один из первых мэйтенеров в дистрибутиве Debian), представил (http://blog.liw.fi/posts/obnam-1.7/) новый выпуск проекта Obnam 1.7 (http://liw.fi/obnam/), в рамках которого развивается система резервного копирования, основанная на идее оптимизации хранения резервных копий за счёт использования репозитория со встроенной поддержкой дедупликации данных. Код программы написан на языке Python и распространяется (http://liw.fi/obnam/download/) в рамках лицензии GPLv3+. Готовые пакеты сформированы для Ubuntu (https://launchpad.net/~chris-bigballofwax/+archive/obnam-ppa/), openSUSE (http://download.opensuse.org/repositories/home:/Vayun/), Gentoo и Debian (http://liw.fi/code/).
Предлагаемый в Obnam подход к резервному копированию нацелен на достижение трёх целей: обеспечение высокой эффективности хранения, простоты использования и безопасности. Эффективность хранения достигается благодаря размещению резервных копий в специальном репозитории, данные в котором хранятся в оптимальном представлении с использованием дедупликации. В одном репозитории могут храниться бэкапы разных клиентов и серверов. При этом объединение дубликатов осуществляется для всех хранимых бэкапов, независимо от их типа, времени создания и источника резервной копии. Для проверки целостности репозитория и его восстановления после сбоя предоставляется специальный вариант утилиты fsck.Если на группе серверов используется одинаковая операционная система, то в репозитории будет сохранена только одна копия повторяющихся файлов, что позволяет существенно сэкономить дисковое пространство при организации резервного копирования большого числа типовых систем, например, виртуальных окружений. Репозиторий для хранения резервных копий может быть размещён как на локальном диске, так и на внешних серверах (для создания сервера для хранения резервных копий не требуется установка дополнительных программ, достаточно доступа по SFTP). Возможен доступ к резервным копиям через монтирование виртуального раздела при помощи специально подготовленного FUSE-модуля.
Для упрощения работы с бэкапами, доступ к резервным копиям организован в форме снапшотов, подразумевающих возможность получения полного среза всех данных резервной копии в состоянии на момент совершения любой из проведённых итераций резервного копирования. Полная резервная копия будет создана только при первом запуске Obnam, при повторных запусках будут сохраняться только инкрементальные изменения, выявленные с момента прошлого запуска. Таким образом, при необходимости восстановления данных можно сразу получить целостное содержимое ФС на момент создания любой инкрементальной копии (без необходимости предварительного восстановления первичной копии с дальнейшим последовательным раскрытием инкрементальных копий).Obnam поддерживает два режима организации процесса резервного копирования - push и pull. В режиме push программа obnam устанавливается на стороне клиента и сохранение резервных копий инициируется клиентом (бэкапы копируются клиентом на сервер хранения резервных копий). В режиме pull программа obnam устанавливается на сервер для хранения резервных копий и процесс копирования данных инициируется сервером (сервер забирает данные с машин клиентов по SFTP).
Для обеспечения высокой безопасности предпочтителен режим push, так как для создания полной резервной копии в режиме pull требуется открытие удалённого доступа к ФС клиента с правами root (в случае взлома сервера резервного копирования, скомпрометированными автоматически окажутся все клиенты). Для дополнительной защиты резервных копий предусмотрена возможность их шифрования с использованием GnuPG (в случае взлома хранилища, злоумышленник не сможет просмотреть содержимое резервных копий без закрытого ключа).
Основные новшества, реализованные в Obnam 1.7:
- Проведена значительная внутренняя переработка, в результате которой была переписана ощутимая часть кода. Внутренние преобразования не должны отразиться на видимых пользователю возможностях, но не исключается наличие незамеченных ошибок, поэтому обновление до версии 1.7 следует проводить с осторожностью и желательно предварительно сохранить копию репозитория с бэкапами;- В интерфейс для создания плагинов добавлена возможность подключения обработчиков, вызываемых после завершения бэкапа (например, такой обработчик может сигнализировать системе мониторинга об успешном создании бэкапа);
- Обновлён FUSE-плагин, используемый для монтирования репозитория бэкапов в форме файловой системы. В плагин добавлена возможность обновления отображаемого представления репозитория;- Добавлена опция "--always-restore-setuid" для принудительного восстановления состояния флагов setuid/setgid, даже если процесс восстановления запускается не от пользователя root или владельца файлов;
- Добавлена опция "--exclude-from" для загрузки списка исключений из внешнего файла (ранее список исключений мог задаваться только в файле конфигурации или командной строке);- Начато написание руководства пользователя Obnam (http://code.liw.fi/obnam/manual/), в настоящее время оно скомпоновано из серии заметок из блога автора и разрозненных статей с сайта проекта;
- Для большинства выводимых ошибок реализованы уникальные коды идентификации, которые позволяют легко найти подобные ошибки в логе (например, "R0B15DX");
- Полностью переписана утилита obnam-benchmark, используемая для тестирования производительности. При установке Obnam данная утилита больше не поставляется и доступна только из git-репозитория проекта;
- Команда "obnam verify" теперь показывает прогресс выполнения операции на основе как числа проверенных файлов, так и размера данных;
- Удалена поддержка команды convert5to6, выполнявшей преобразование устаревшего формата репозитория резервных копий;- В лог добавлено отражение информации о накладных расходах при передаче данных в хранилище. Под накладными расходами понимается число байт, не связанных с непосредственным контентом файлов, а определяющих метаданные, такие как имена файлов, права доступа, расширенные атрибуты и т.п.
URL: http://blog.liw.fi/posts/obnam-1.7/
Новость: http://www.opennet.me/opennews/art.shtml?num=39323
Сравнить бы с амандой и бакулой.
Для копирования локальных данных еще годится, но попытка использовать ее для удаленного копирования по ssh больших объемов показало полную неспособность к этому. Мало того, что оно дико тормознутое по сравнению с rsync, так еще теряет соединение и на этом подвисает. Видно питонистов не учат обрабатывать ошибки. При повторных запусках начинает все с самого начала, даже если ему принудительно сказать делать чекпойнты.
> Мало того, что оно дико тормознутое по сравнению с rsync,Вы что, питон не тормозит!!!1111
> Для копирования локальных данных еще годится, но попытка использовать ее для удаленного
> копирования по ssh больших объемов показало полную неспособность к этому. Мало
> того, что оно дико тормознутое по сравнению с rsync, так еще
> теряет соединение и на этом подвисает. Видно питонистов не учат обрабатывать
> ошибки. При повторных запусках начинает все с самого начала, даже если
> ему принудительно сказать делать чекпойнты.Баги репортили?
Интереснее всего с Acronis...
Что-то никак не могу ущучить, как
"Полная резервная копия будет создана только при первом запуске Obnam, при повторных запусках будут сохраняться только инкрементальные изменения, выявленные с момента прошлого запуска."
может одновременно сочетаться с
"Таким образом, при необходимости восстановления данных можно сразу получить целостное содержимое ФС на момент создания любой инкрементальной копии (без необходимости предварительного восстановления первичной копии с дальнейшим последовательным раскрытием инкрементальных копий)."
видимо подразумевается так:Только первый запуск займет дисковый объем, равный по размеру резервируемым данным,
при повторных запусках будет требоваться только объем, необходимый для сохранения инкрементальных изменений, выявленных с момента прошлого запуска.----
Сколько при этом потребуется перегнать по сети - вопрос, требующий отдельного уточнения.
BONTMIA (rsync-based bash? script) рулит.
Там хранилище чем-то похоже на гит. Каждый снапшот объединяет чанки (=блобы) воедино, потому если некоторые чанки были в предыдущем снапшоте, они без изменения будут включены в снапшот новый. Ну а доступ к снапшоту быстрый, а к чанкам — прямой. Потому не нужно перечитывать все предыдущие снапшоты.
Да, правильно.
Фактически там все бекапы полные, разница в том что первый снимок будет делаться долго, потому что бекапит всё, а остальные быстро, потому что только изменения. При этом первый снимок (как и любой другой) потом можно удалить, остальные остануться целыми.Я правда не проверял как это работает например на бекапе базы, где несколько больших датафайлов, которые изменяются где-то внутри. Предполагаю в таком случае огромные блобы будут сохраняться в бекап заново целиком. Но для баз есть другие инструменты и методы.
Использую obnam для бекапа $HOME. Данные в основном фото, около 70GB. С учётом встроенного сжатия бекап с ~40 снимками занимает на 15% меньше места, чем сами данные в $HOME.
>> Готовые пакеты сформированы для Ubuntu, openSUSE, Gentoo и Debian.Готовые пакеты для Gentoo?
Не занудствуй.
binary packages почему бы и нет, хотя тут наверное все же речь о ebuild.
Так это же zbackup!Я его кстати юзаю, очень прикольная штука - можно хоть оббэкапиться, инкременты почти ничего не занимают. Причём дедуплицируется ведь вообще всё - sql дампы например тоже можно.
И забавный нюанс - засчёт того, что дедуплицирует оно последовательности, заtar'ивание в алфавитном порядке увеличивает эффективность дедупликации :)