Ларс Вирзениус (Lars Wirzenius), один из студенческих товарищей Линуса Торвальдса, вовлечённый в развитие Linux с первых дней существования проекта (создатель Linux Documentation Project и один из первых мэйтенеров в дистрибутиве Debian), представил (http://blog.liw.fi/posts/obnam-1.2/) релиз системы для организации резервного копирования данных Obnam 1.2 (http://liw.fi/obnam/), отличающейся поддержкой дедупликации в репозитории резервных копий.
Код программы написан на языке Python и распространяется (http://liw.fi/obnam/download/) в рамках лицензии GPLv3+. Готовые пакеты сформированы для Ubuntu (PPA (https://launchpad.net/~chris-bigballofwax/+archive/obnam-ppa/)), Gentoo и Debian (http://liw.fi/code/).
Предлагаемый в Obnam подход к резервному копированию основывается на достижении трёх целей: обеспечение высокой эффективности хранения, простоты использования и безопасности. Эффективность хранения достигается благодаря размещению резервных копий в специальном репозитории, данные в котором хранятся в оптимальном представлении с использованием дедупликации. В одном репозитории могут храниться бэкапы разных клиентов и серверов. При этом объединение дубликатов осуществляется для всех хранимых бэкапов, независимо от их типа, времени создания и источника резервной копии. Если на группе серверов используется одинаковая операционная система, то в репозитории будет сохранена только одна копия повторяющихся файлов, что позволяет существенно сэкономить дисковое пространство при организации резервного копирования большого числа типовых систем, например, виртуальных окружений. Репозиторий для хранения резервных копий может быть размещён как на локальном диске, так и на внешних серверах (для создания сервера для хранения резервных копий не требуется установка дополнительных программ, достаточно доступа по SFTP);
Для упрощения работы с бэкапами, доступ к резервным копиям организован в форме снапшотов, подразумевающих возможность получения полного среза всех данных резервной копии в состоянии на момент совершения любой из проведённых итераций резервного копирования. Полная резервная копия будет создана только при первой запуске Obnam, при повторных запусках будут сохраняться только инкрементальные изменения, выявленные с момента прошлого запуска. Таким образом, при необходимости восстановления данных можно сразу получить целостное содержимое ФС на момент создания любой инкрементальной копии (без необходимости предварительного восстановления первичной копии с дальнейшим последовательным раскрытием инкрементальных копий).Obnam поддерживает два режима организации процесса резервного копирования - push и pull. В режиме push программа obnam устанавливается на стороне клиента и сохранение резервных копий инициируется клиентом (бэкапы копируются клиентом на сервер хранения резервных копий). В режиме pull программа obnam устанавливается на сервер для хранения резервных копий и процесс копирования данных инициируется сервером (сервер забирает данные с машин клиентов по SFTP). Для обеспечения высокой безопасности предпочтителен режим push, так как для создания полной резервной копии в режиме pull требуется открытие удалённого доступа к ФС клиента с правами root (в случае взлома сервера резервного копирования, скомпрометированными автоматически окажутся все клиенты). Для дополнительной защиты резервных копий предусмотрена возможность их шифрования с использованием GnuPG (в случае взлома хранилища, злоумышленник не сможет просмотреть содержимое резервных копий без закрытого ключа).
Среди новшеств, реализованных в версии Obnam 1.2:
- Поддержка команды "diff", показывающей различия между двумя резервными копиями - выводится список файлов, которые были добавлены, удалены или изменены, в промежутке между двумя произвольными генерациями резервных копий;
- Имена помещаемых в бэкап файлов теперь выводятся в лог при выборе уровня лога INFO, а не DEBUG;
- Для упрощения написания скриптов вывод из плагина "show" теперь может быть перенаправлен в файл при указании опции "--output=FILE". Перенаправление поддерживается для команд clients, generations, genids, ls, diff и nagios-last-backup-age;- Доработана документация и подсказки по командам.
URL: http://blog.liw.fi/posts/obnam-1.2/
Новость: https://www.opennet.ru/opennews/art.shtml?num=35026
Чем оно удобнее duplicity?
https://bugs.launchpad.net/ubuntu/+source/duplicity/+bug/989496
тем что использует дедупликацию блоков данных, а не инкрементальные бекапы ?
Ого, существовала старая версия...
на самом деле хорошая вещь
лучше чем rsync, тем что с ключами шифрования работать может
> на самом деле хорошая вещьПоддерживаю! Уже хотя бы тем, что еще одна система резервного копирования.
> лучше чем rsync, тем что с ключами шифрования работать можетGnuPG тоже умеет работать с ключами.
А rsync немного не для этого, как мне кажется.
Да и duplicity тоже может работать с ключами.Эх, не хватает образования да и коридоров тоже, что бы сравнить Obnam и Duplicity.
А случаем кто-нибудь не в курсе. Если ли готовые программы для бэкапа, которые постоянно отслеживают изменения? А то на больших объемах данных такой подход "сверки" прям не особо хорош. Интересует кросс платформенные решения.
> Если ли готовые программы для бэкапа, которые постоянно отслеживают изменения?google://backup+inotify => http://serverfault.com/questions/7969/is-there-a-working-lin...
это Очень Кроссплатформенно, да ;-)
> это Очень Кроссплатформенно, да ;-)Потому и не цитировал то, на что не нашёл слов для совета искать самому, отталкиваясь от ответа на менее точный вопрос. *notify всё-таки штука достаточно специфическая, чтобы как минимум степень кроссплатформенности стоило уточнить -- фря, макось, винда или тамагочи.
Капитан говорит, что "сверку" как правило производят в случае если изменилось время последнего изменения. Что-то мне трудно представить ситуацию, когда отслеживание будет значительно эффективнее проверки времени изменения, кроме случая когда бекапы каждые 5 минут запускаются.
> Капитан говорит, что "сверку" как правило производят в случае если изменилось время
> последнего изменения. Что-то мне трудно представить ситуацию, когда отслеживание будет
> значительно эффективнее проверки времени изменения, кроме случая когда бекапы каждые 5
> минут запускаются.на 100 млн. файлов даже просто просмотр времени - дело очень не быстрое...
Боюсь тут даже не во времени дело, а в пожирании ресурсов. Даже если в итоге ничего не поменялось.
> Боюсь тут даже не во времени дело, а в пожирании ресурсов. Даже
> если в итоге ничего не поменялось.Так эта монитор тоже не бесплатный, особенно когда несколько юзеров начнут файлы пачками удалять или загружать. Плюс всё равно придётся иногда сканировать всё дерево для надёжности и при старте монитора.
Не говорю, что не может быть применения такому бэкапу, но найти это применение сложно.
>Не говорю, что не может быть применения такому бэкапу, но найти это применение сложно.Ой, да ладно. А как же DropBox :-)
По сути это одна медаль. Если быть совсем точно, не обязательно сразу бакапить после изменения. Можно и выждать время. Зато при таком подходе можно иметь состояния на все "пачки" изменений.
>>Не говорю, что не может быть применения такому бэкапу, но найти это применение сложно.
> Ой, да ладно. А как же DropBox :-)
> По сути это одна медаль. Если быть совсем точно, не обязательно сразу
> бакапить после изменения. Можно и выждать время. Зато при таком подходе
> можно иметь состояния на все "пачки" изменений.В Дропбоксе онлайн синхронизация это фича, а не способ экономить ресурсы. И жрёт эта фича очевидно больше чем регулярный бэкап того же объёма по расписанию.
Посмотрите Box Backup. С кроссплатформенностью все в порядке
Rsync написан на нормальном языке программирования и не зависит особо от других программ, лично я привык такими программами пользоваться.
Когда слышу про всякие питоны пёрлы и т д просто капец.
Давайте уже ядро Linux не на C а на java или на питоне писать.
>Rsync написан на нормальном языке программирования и не зависит особо от других программ, лично я привык такими программами пользоваться.
>Когда слышу про всякие питоны пёрлы и т д просто капец.Сейчас скачал архив с исходниками rsync -- там внутри лежат скрипты и на перле, и на питоне, которые помогают при сборке.
А про "независимость" вообще смешно. Скопируй с машины, на которой гента или убунта стоит, бинарник rsync на другую машину, на которой, скажем, debian lenny. Попробуй запустить. И это учитывая то послабление, что архитектура обеих машин одинаковая.
Не то что с пистоном. Там то никаких проблем с версиями.
Причем тут пистон? Речь о НЕЗАВИСИМОСТИ программ на НОРМАЛЬНЫХ ЯЗЫКАХ.
> Причем тут пистон? Речь о НЕЗАВИСИМОСТИ программ на НОРМАЛЬНЫХ ЯЗЫКАХ.От каких языков зависит используемый рсинк? Не сбор этого рсинка, а уже готовая прога?
>От каких языков зависит используемый рсинк?Чего?
> Чего?Сам что-ли не понимаешь что вверху написал? Я тебе подряд скопирую, с подтемой. Одна строка - одна реплика человека.
---
Rsync написан на нормальном языке программирования и не зависит особо от других программ
Сейчас скачал архив с исходниками rsync -- там внутри лежат скрипты и на перле, и на питоне, которые помогают при сборке.
Не то что с пистоном.
Речь о НЕЗАВИСИМОСТИ программ на НОРМАЛЬНЫХ ЯЗЫКАХ.
От каких языков зависит используемый рсинк? Не сбор этого рсинка, а уже готовая прога?
Чего?
---
Тут тебе объясняют что рсинк используется без всяких пистонов в системе. В ответ ты начал, зачем-то, рассказывать про сборку рсинка из исходников. А под конец типа не понял что к чему.
---
Скопируй с машины, на которой гента или убунта стоит, бинарник rsync на другую машину, на которой, скажем, debian lenny. Попробуй запустить.
Не то что с пистоном. Там то никаких проблем с версиями.
Причем тут пистон?
От каких языков зависит используемый рсинк? Не сбор этого рсинка, а уже готовая прога?
Чего?
---
Здесь тебе сказали что проблема с запускам рсинка слитого с другой системы ничуть не геморойней пистоновых скриптов. И их возможным незапуском в других версиях пистона.
> Не то что с пистоном. Там то никаких проблем с версиями.да
и что странно линукс при этом работает на стопицот тыщ архитектур, но гента с дебианом не очень то и совместима
Линукс - ядро. Ядро от дебиана(линуховое, в уже бинарном виде) можно прикрутить к Генте. Как и в обратную сторону.
Очень сомневаюсь.
А ещё (это я по секрету): ядро можно из ванильных исходников собрать даже под убунту. Честно-честно.
>Ядро от дебиана(линуховое, в уже _____бинарном_____ виде) можно прикрутить к Генте
Сайты виндоводов за углом. Это там нельзя ядрышко от икспишки взять и в висту сунуть.
О, отличное сравнение. Прикрути ядро 2.4 к современному Debian.
А что, если подшаманить с /dev - думаешь не взлетит?
Берем дебиан, ставим на него сервер OpenVZ, в контейнер ставим генту. Получаем генту с ядром от дебиан.
> Берем дебиан, ставим на него сервер OpenVZ, в контейнер ставим генту.
> Получаем генту с ядром от дебиан.Конкретно в этом случае скорее с ядром от openvz, если правильно помню недавние обсуждения в debian-russian@ (советовали брать из proxmox или сам proxmox). Это в альте собирают родным пакетом ихний el branch...
Но если не ovz, а lxc или просто чрут -- то угу, ядро из одного дистрибутива, ABI из другого :)
> А про "независимость" вообще смешно. Скопируй с машины, на которой гента или
> убунта стоит, бинарник rsync на другую машину, на которой, скажем, debian
> lenny. Попробуй запустить. И это учитывая то послабление, что архитектура обеих
> машин одинаковая.Скопировал /usr/bin/rsync с Debian 6.0 (squeeze) на ALT Linux Sisyphus, запускается. Достал rsync из ALT Linux Master 2.4 -- на сизифе запускается, на дебиане уже нет. Потаскал бинарники между сизифом и openSUSE 11.4 -- взаимно совместимы.
Ась? :)
PS: дедупликация при полнометражных бэкапах пачки хостов/vm/ve интересна, но в сумме не вижу смысла перебираться с bacula.
было дело. причём именно rsync с debian 6 на генту не обновлявшуюся с 2009 года и со сломаным ebuild. ну завелось оно после небольшого шаманства с либами. И что???
Ой скопировал и все запускается. Или может вы бины для х86 на arm хотели запустить.
Зачем копировать бинарник из одной ОС в другую?
> Зачем копировать бинарник из одной ОС в другую?Человек будто попытался сказать, что совместимость бинарников между дистрибутивами примерно так же плоха, как и совместимость питониевого кода. Промахнулся на пару порядков, тем более применительно к rsync.
> Зачем копировать бинарник из одной ОС в другую?Про переносимость не слыхАл?
>> Зачем копировать бинарник из одной ОС в другую?
> Про переносимость не слыхАл?Он даже не слыхал такого слова, как ABI - в лине тысячи их!
> питоне писать.Прикольно будет когда в питоне опять сломают совместимость и в самый нужный момент окажется что кина^W бэкапов то и не будет.
>> питоне писать.
>Прикольно будет когда в питоне опять сломают совместимость и в самый нужный момент окажется что кина^W бэкапов то и не будет.А ты чего - дурачек накатывать сразу новые версии на все машины без разбору? У нормальных людей для этого есть дистрибутивы с релизами, в рамках которых весь софт тестируется на совместимость версий. Хотя нет, ты просто упоротый тролль, который когда-то что-то слышал о проблемах совместимости в питоне и теперь пытается наугад блеснуть своими познаниями
> Ларс Вирзениус (Lars Wirzenius
> ObnamПроект живет, это хорошо!
Спасибо автору!
Аллитерация бросяется в глаза при каждом прочтении...Оно бы еще умело мастдай копировать (хоть из под cygwin)...
> Аллитерация бросяется в глаза при каждом прочтении...
> Оно бы еще умело мастдай копировать (хоть из под cygwin)...Там сначала надо маздайными средствами сделать копию system state.
А потом уже её копировать.
Визениусу зачот, решпект и уважуха, но с развёрнутой и исправно (тьфу-тьфу) работающей бакулы слезать не собираюсь :-Ь
Кто нибудь может на пальцах объяснить, чем оно круче BackupPC ?
> Кто нибудь может на пальцах объяснить, чем оно круче BackupPC ?Всё, что умеет мигрировать более архивные данные на более медленные/дешёвые носители, уже круче. Насчёт обма... обнама не знаю. :)
а кто сказал, что BackupPC не умеет?
http://backuppc.sourceforge.net/faq/BackupPC.html#archive_fu...
мда.. попытался на CentOS6 запустить, то одно надо, то другого нет.. ((
Хотя вроде поставив десяток библиотек для питона, оно запустилось)
"Для обеспечения высокой безопасности предпочтителен режим push"
Наоборот. Бэкап-серверу верят все, он - никому. Иначе оно = файлопомойка.
> "Для обеспечения высокой безопасности предпочтителен режим push"
> Наоборот. Бэкап-серверу верят все, он - никому. Иначе оно =
> файлопомойка.Взлом бекап сервера и эгегей!
Обама?
> Обама?Обанама!