После шести лет разработки увидел свет (http://blog.liw.fi/posts/obnam-1.0/) первый стабильный релиз инструмента для организации резервного копирования данных - Obnam 1.0 (http://liw.fi/obnam/), при разработке которого делалась ставка на обеспечение высокой эффективности хранения в сочетании с безопасностью и простотой использования. Код программы написан на языке Python и распространяется (http://liw.fi/obnam/download/) в рамках лицензии GPLv3+. Готовые пакеты сформированы для Ubuntu (PPA (https://launchpad.net/~chris-bigballofwax/+archive/obnam-ppa/)) и Debian.
Основные особенности Obnam:- Резервные копии размещаются в специальном репозитории, данные в котором хранятся в оптимальном представлении с использованием дедупликации. При этом объединение дубликатов осуществляется для всех хранимых бэкапов, независимо от их типа, времени создания и источника резервной копии. В одном репозитории могут храниться бэкапы разных клиентов и серверов. Если на группе серверов используется одинаковая операционная система, то в репозитории физически будет сохранена только одна копия повторяющихся файлов, что позволяет существенно экономить дисковое пространство при организации резервного копирования большого числа типовых систем, например, виртуальных окружений;
- Поддержка размещения репозитория для хранения резервных копий на локальном диске и на внешних серверах с использованием для доступа к данным протокола SSH SFTP (для создания сервера для хранения резервных копий не требуется установка дополнительных программ, достаточно обычного SSH-доступа);
- Режим доступа к резервным копиям в форме снапшотов. Доступ к данным, сохранённым в режиме инкрементального бэкапа, может быть организован в форме снапшота, при котором независимо от выбранной итерации виден полный срез всех данных, несмотря на то, что фактически в момент выбранной итерации могло быть скопировано несколько файлов. Т.е. для восстановления из инкрементальных копий можно сразу получить целостное содержимое ФС, без необходимости предварительного восстановления первичной копии с дальнейшим последовательным раскрытием инкрементальных копий;
- Поддержка шифрования резервных копий с использованием GnuPG;
- Поддержка режимов работы push и pull. В режиме push программа obnam устанавливается на стороне клиента и сохранение резервных копий инициируется клиентом. В режиме pull программа obnam устанавливается на сервер для хранения резервных копий и процесс копирования данных инициируется сервером (данные передаются по SFTP). С точки зрения безопасности предпочтителен режим push, так как для создания полной резервной копии в режиме pull требуется открытие удалённого доступа к ФС клиента с правами root (в случае взлома сервера резервного копирования, скомпрометированными автоматически окажутся все клиенты);
- Из планов на будущее отмечается проведение работы по оптимизации производительности, создание FUSE-модуля для доступа к резервным копиям через монтирование виртуального раздела и реализация режима непрерывного резервного копирования.
URL: http://blog.liw.fi/posts/obnam-1.0/
Новость: http://www.opennet.me/opennews/art.shtml?num=33997
Kewl, начинаем тестить.
На питоне? Счастливого тестирования! :)
Дедуплицироанные бэкапы??? Они б хоть возможность в двух копиях хранить сделали.. Это ж классика - нужно выдернуть что-то полугодовой давности, берём бэкап... а он инкрементный, и кусок данных в нём записан со сбоем. Вот и ждесь то же самое может быть запросто - они ж наверняка по хеш какой-нибудь для блоков расчитывают и пишут, и уже по нему делают дедупликацию.
Так-то и проверить целостность записанного можно. Может там хеши обновляются периодически. Все реализуемо.Оно бы еще умело винду бекапить простым преднастроенным клиентом, а то заморачиваться с cygwin на Н машин как-то ломает. Линукс, то и так бэкапится в 2 счета.
> Так-то и проверить целостность записанного можно.Так ить бэд сектор на бэкапном носителе может всраться опосля проверки. А постоянно его мурыжить проверками - сами понимаете. То что перец упомянул - вполне обычная ситуация, те кто имеет дело с бэкапами на регулярной основе - отлично в курсе этих грабель.
Ну, as for me - чем проще операции, проделываемые с бэкапом и чем их меньше - тем спокойнее. Идеал в этом плане - всё же стример или писалка с автоподачей носителей. Чтобы всё в принципе было физически развязано. А из реального - RAID, хорошая схема интерлива и периодический перенос части полных бэкапов куда-то в другое место, либо параллельный бэкап в разные точки. Особенно для всяких офисов актуально, где дай бог чтобы серверная была, а физически угробить всё молжет хоть свихнувшаяся система пожаротушения хоть вечно свихнувшаяся СБУ.
Вы же сами себе ответили. Не важно, есть дедупликация, нет дедупликации, надо делать более одного backup, само собой на разные физические носители, желательно географически разнесенные. Кстати к RAID это тоже относится, никакой надежности он не дает, только сокращает downtime. Стример и cd писалки это вообще архаика времен дорогого места на винчестерах и флешках.
В любом случае одно другое дополняет, а не заменяет.
Так это два разных случая. Один - это когда защиту надо обеспечить всерьёз. Здесь - распределённые бэкапы и сменные носители. Другой - когда у нас ограниченные средства, и на них надо по-максимуму сделать надежность. Здесь - рейд, интерлив и иногда бэкап вовне, потому что постоянный удалённый бэкап - это дорого и/или медленно.Стример и писалка (с соответствующими автоматами) дают принципиально важное свойство - изоляция носителя от системы. Записали мы на ленту - и она уехала в банк. Даже если после этого по системе проедется 220 вольт и всё сгорит к чертям, лента не пострадает. Заведомо однократно записываемый диск ещё лучше в этом плане - тут уже и злоумышленник подчистить ничего не сможет.
Это действительно два разных случая, но только не так как вы это понимаете(ну или формулируете). RAID вообще никаким местом к бэкапам не относится, ни к дорогим, ни к дешевым.По поводу изоляции носителя. Флешка в этом плане ничем не хуже ленты или дисков, только удобнее и дешевле. Про злоумышленника вообще детский сад какой-то, взять другой cd-r и записать на него измененный вариант данных ему совесть не позволит?
> Это действительно два разных случая, но только не так как вы это
> понимаете(ну или формулируете). RAID вообще никаким местом к бэкапам не относится,
> ни к дорогим, ни к дешевым.
> По поводу изоляции носителя. Флешка в этом плане ничем не хуже ленты
> или дисков, только удобнее и дешевле. Про злоумышленника вообще детский сад
> какой-то, взять другой cd-r и записать на него измененный вариант данных
> ему совесть не позволит?Флешка дороже дисков и живёт меньше чем лента. В остальном - если есть банки, работающий с флешками и использовать те, что имеют реальную защиту от записи - да, вероятно, не хуже.
А RAID очень даже при делах - в "дешевом" случае, когда основная часть бэкапов - локальна и только некотрые мы сохраняем удалённо. Тогда он хорошо повышает вероятность того, что данный нужный бэкап (не сохранённый удалённо) всё же жив, а не сдох вместе с диском. В "дорогом" случае, конечно, RAID неактуален или за него отвечает какой-нибудь Amazon.
> А RAID очень даже при делах - в "дешевом" случае, когда основная
> часть бэкапов - локальна и только некотрые мы сохраняем удалённо. Тогда
> он хорошо повышает вероятность того, что данный нужный бэкап (не сохранённый
> удалённо) всё же жив, а не сдох вместе с диском. В
> "дорогом" случае, конечно, RAID неактуален или за него отвечает какой-нибудь Amazon.Только RAID тогда должен быть софтверный, или должно быть несколько запасных контроллеров. А то сгорел контроллер, в продаже уже их нет, а данные записаны в уникальном формате контроллера. Люди попадали на это, когда NAS с рейдами сгорал - диски оставались исправны (близок локоток), а данные в формате неизвестного изобретателя (а не укусишь, локоток).
И надо мониторить состояние рейда и вовремя реагировать. Домашние - не умеют мониторить, не знают возможности этого, ошибочно надеются на RAID. Он вторичен, а иногда бесполезен.
P.S.
Занятно, клиент сам иницирует бекап. Раньше, вроде, принято было, что только сервер инициирует бекап.
Или я не понял, или утверждается, что эту систему лучше настроить в режиме push, когда она по инициативе клиента может сделать всё что угодно со своим бекапом - уничтожить, например. А при режиме push сервер используется тупо как флешка - тупо расшаренный по SFTP каталог для сброса данных, _вся_ логика, все права доступа к бекапу клиента управляются самим клиентом.
Похоже в тексте новости логика описана странно. Вероятно разница между push-pull в установке клиент-программы Obnam на клиенте. Тогда как серверная часть Obnam установлена на сервере в любом случае.
а должен быть софтверный, или должно быть несколько запасных контроллеров.
> А то сгорел контроллер, в продаже уже их нет, а данные
> записаны в уникальном формате контроллера.Тьфу-тьфу, современные LSI пишут данные в "стандартном" формате, и они очень легко монтируются через device mapper. Даже R5/R6.
Ну и бэкапьте себе "снепшоты". Эта система допускает.
Если систему сделали с такими вот интересными фичами, то это не значит, что теперь она обязана заменить все способы рез коп-я.
Тем более, что клинтов под винду еще нет (и, похоже, не планируются)
> Ну и бэкапьте себе "снепшоты". Эта система допускает.
> Если систему сделали с такими вот интересными фичами, то это не значит,
> что теперь она обязана заменить все способы рез коп-я.
> Тем более, что клинтов под винду еще нет (и, похоже, не планируются)Э... При чём здесь снэпшоты?
Шоп бэкапить на второй хост же, снять консистентное состояние того чего вам надо (либо всей ФС с дедублицированными бэкапами либо состояния какой-то системы из бекапа)
Угу, давайте в придачу к хитрому бэкапу с дедупликацией ещё снапшоты навернём, а потом со всей этой хренью попытаемся взлететь. Еще раз - система бэкапов должна быть ПРОСТОЙ. С минимумов компонент и сложности кода.
а вы раз в неделю делайте полный бекап, а инкрементальные - раз в день. обычное же дело.
Ну дык. Но если оказывается, что у нас бэкап дедуплицируется, то вполне можем огрести ситуацию, когда все экземпляры бэкапа имеют битый кусок, даже если все бэкапы полные.
> Ну дык. Но если оказывается, что у нас бэкап дедуплицируется, то вполне
> можем огрести ситуацию, когда все экземпляры бэкапа имеют битый кусок, даже
> если все бэкапы полные.Что есть "битый кусок" в данном случае, если не секрет?
> Что есть "битый кусок" в данном случае, если не секрет?битый - это тот, который не возможно прочитать, или с порченными данными. Именно поэтому, например symantec NBU, хоть и делает дедуп, но только на диске, с последующим destage полных (читай собранных из dedup) образов на ленту.
>> Что есть "битый кусок" в данном случае, если не секрет?
> битый - это тот, который не возможно прочитать, или с порченными данными.
> Именно поэтому, например symantec NBU, хоть и делает дедуп, но только
> на диске, с последующим destage полных (читай собранных из dedup) образов
> на ленту.та же zfs от этого избавляет, храня несколько копий на разных носителях и сравнивая их хеши.
>> Что есть "битый кусок" в данном случае, если не секрет?
> битый - это тот, который не возможно прочитать, или с порченными данными.не не не, именно в данном случае - после создания бекапа и сверки контрольных сумм как там может оказаться битый кусок?
>Дедуплицироанные бэкапы??? Они б хоть возможность в двух копиях хранить сделали.. Это ж классика - нужно выдернуть что-то полугодовой давности, берём бэкап... а он инкрементный, и кусок данных в нём записан со сбоем.В мане есть опция --deduplicate=never de-duplicate. Можно держать любое количество полных копий, так же как и при инкрементальном и дифференциальном. Или --deduplicate=verify that no hash collisions happen. В этом случае очевидно, что сбойный блок будет выглядеть как коллизия при сравнении с самим собой правильным. Плюс опции --verify и --fsck. При желании можно достаточно надежно соломкой обложиться. =)
Например в ZFS все хешируется, при нарушении хеша автоматом лечится. Чтобы быть увереным, что коллизий хеша не будет - можно включить проверку перед записью.
Можно также хранить несколько копий на одном диске, хотя это не сильно поможет, если диск серьезно посыпется.
В общем в плане хранилища велосипеды.
Потестил немного. Ну... идея, конечно, интересная. Производительность тоже неплохая. Но пока не научится не снимать хеши не изменявшихся с последнего захода файлов, как это делает tar, всё равно слишком накладно по пропускной способности диска/сети.
На заметку возьму, но переходить с Бакулы не буду :)
Круче rsync наверное ни чего нет.
Да, хрену к ней не хватает, то есть возможностей rsynca.
А rsync дедубликацию поддерживает? Актуально для однотипно настроенных компьютеров.
А если файл просто переименовать, то rsync поймет, что не надо заново копировать?
Понять-то поймет, опция подсчета хэшей у него есть (название не помню, надо в ман лезть), но памяти под это дело выжрет — мама не горюй.
> А rsync дедубликацию поддерживает? Актуально для однотипно настроенных компьютеров.zfs/btrfs?
В Btrfs не известно когда увидим работающую дедупликацию. В рассылке писали что уже можно дедуплицировать по расписанию и пример утилиты был, но опции для онлайн дедупликации нет и возможно не будет. Кто-то из разработчиков писал, что идеологически не верно делать дедупликацию в ФС, а надо на прикладном уровне как в Obnam. По-своему он конечно прав.
ZFS ― латентная проприетарь со всеми вытекающими. Если данный факт не смущает, то можно уже рсинкать на ZFS. =) Но проприетарные ынтырпрайз решения с дедупликацией существовали задолго до ZFS и благополучно покупаются теми кому очень надо.
> В Btrfs не известно когда увидим работающую дедупликацию. В рассылке писали что
> уже можно дедуплицировать по расписанию и пример утилиты был, но опции
> для онлайн дедупликации нет и возможно не будет. Кто-то из разработчиков
> писал, что идеологически не верно делать дедупликацию в ФС, а надо
> на прикладном уровне как в Obnam. По-своему он конечно прав.По моему он совсем не прав. Теряется прорачность доступа к данным, если делать дедуплекацию через прикладной уровень, к тому же нужно держать карту хешей, которая в фс уже и так есть
> ZFS ― латентная проприетарь со всеми вытекающими. Если данный факт не смущает,
> то можно уже рсинкать на ZFS. =) Но проприетарные ынтырпрайз решения
> с дедупликацией существовали задолго до ZFS и благополучно покупаются теми кому
> очень надо.Латентная или не латентная, а свободная и еще можно поспорить что свободнее, CDDL или GPL. Бекапы уже написаны: sh,rsync,zfs,snapshot + прочие плюшки zfs, типа прозрачного сжатия данных и дедупликации. В итоге не ломаемое решение из-за своей дубовости, моментальный доступ к любому снимку данных (а не как обычно в инкрементных бекапах - по полчаса думает) и отличная прозрачность. И прозрачность тут будет даже побольше, чем в полных бекапах запакованных tar-ом, т.к. здесь распаковывать ничего не нужно (например что бы diff сделать), просто идешь и в .zfs/snapshot и работаешь с данными от нужной даты.
В последнее время плотно занимался этим вопросом (zfs+дедупликация рулят для хранения сотен гиг lvm-снапшотов), так вот есть подводный камень: zfs стабильна на соляре и вроде бы опен-индиане. Т.к. дедупликатор представляет собой упаковщик с безразмерным словарем (в текущей реализации вроде пользует sha256-хэши блоков, вероятность коллизии что-то в районе 10-31, я эту математику не осилил, так что лучше перепроверьте), код дедупликатора должен как-то ограничивать аппетиты (оценка ~5 GB RAM per 1 TB DATA). Во FreeBSD 9.0 он с этим не справляется >> kernel panic. Есть еще "Native ZFS for Linux", его потестить руки пока не дошли.
Для себя выбрал OpenIndiana domu over xen4.1 dom0 - современных процов хватает протащить гигабитный поток данных с учетом всех пенальти. Важно разумно выбирать размер пула, т.к. БД дедупликатора одна на каждый пул.
backuppc вроде делает то же самое, но у него и интерфейс есть, и работает у многих давно. А это... ну сделают на сервере бэкап. А мне его надо на домашний забрать - и как? А никак. Вещь в себе.
> А мне его надо на домашний забрать - и как?
> А никак. Вещь в себе.А в бэкапписи тоже самое. Данные сжимаются и переименовываются пофайлово. Восстановить и скачать можно только через веб интерфейс. Еще как в себе. Сервре бэкапов упадет и надо поднимать новый чтоб данные вытянуть, а дело это не простое т к в дистрах он бэкапписи недопиленный идет.
>> А мне его надо на домашний забрать - и как?
>> А никак. Вещь в себе.
> А в бэкапписи тоже самое. Данные сжимаются и переименовываются пофайлово. ВосстановитьВот и я о том же - ничего нового не сделали, а интерфейса нормального нет. Шесть лет разрабатывали непонятно что.
> backuppc вроде делает то же самое, но у него и интерфейс есть,
> и работает у многих давно. А это... ну сделают на сервере
> бэкап. А мне его надо на домашний забрать - и как?
> А никак. Вещь в себе.этот по крайней мере не требует рутового доступа с клиента, в отличие от.
rsync может делать инкременальные бэкапы!
но лучше б он этого не делал.
> После шести лет разработки увидел свет (http://blog.liw.fi/posts/obnam-1.0/) первый
> стабильный релиз инструмента для организации резервного копирования данных - Obnam 1.0
> (http://liw.fi/obnam/), при разработке которого делалась ставка на обеспечение высокой
> эффективности хранения в сочетании с безопасностью и простотой использования. Код программыХорошо.
Шесть лет это немалый срок, может большенство косяков поправили.
Интересно сколько людей пользуют (тестируют).
Чем то напоминает duplicity, может плюшек побольше?
Может на основе него делают (или по идеям, и это хорошо ;)?> - Резервные копии размещаются в специальном репозитории, данные в котором хранятся
> в оптимальном представлении с использованием дедупликации. При этом объединение дубликатов
> осуществляется для всех хранимых бэкапов, независимо от их типа, времени создания
> и источника резервной копии. В одном репозитории могут храниться бэкапы разных
> клиентов и серверов. Если на группе серверов используется одинаковая операционная
> система, то в репозитории физически будет сохранена только одна копия повторяющихся
> файлов, что позволяет существенно экономить дисковое пространство при организации резервного
> копирования большого числа типовых систем, например, виртуальных окружений;Ну если хранить пользовательские данные, то дедупликация (устранение повторяющихся данных) может быть и небольшой. В случае виртуальных окружений, да это +.
Иногда бывает быстрее переустановить систему, положить сверху конфиги используемых сервисов. Далее потихонечку смотреть, что забыли!?!?!?> - Поддержка режимов работы push и pull. В режиме push программа
> obnam устанавливается на стороне клиента и сохранение резервных копий инициируется клиентом.
> В режиме pull программа obnam устанавливается на сервер для хранения резервных
> копий и процесс копирования данных инициируется сервером (данные передаются по SFTP).
> С точки зрения безопасности предпочтителен режим push, так как для
> создания полной резервной копии в режиме pull требуется открытие удалённого доступа
> к ФС клиента с правами root (в случае взлома сервера резервного
> копирования, скомпрометированными автоматически окажутся все клиенты);Надеюсть с правами только на чтение?
> Шесть лет это немалый срок, может большенство косяков поправили.Шесть лет - это всего. На самом деле, я бы сказал, что активно Obnam разрабатывается три года. До этого был совершенно другой архитектурно продукт основанный на rsync.
>Чем то напоминает duplicity, может плюшек побольше?
>Может на основе него делают (или по идеям, и это хорошо ;)?Его он пробовал использовать, но натолкнулся на некоторые ограничения и решил, что для устранения этих ограничений потребует слишком больших усилий по модификации duplicity. Самым большим ограничением, по мнению автора, является то, что duplicity делает полный бэкап, а потом инкрементные. Периодический полный бэкап он посчитал слишком нерациональным.
> Далее потихонечку смотреть, что забыли!?!?!?
Сам автор выделяет, кроме дедупликации две сильные стороны программы: поддержка snapshot и шифрования (через GnuPG). Еще отмечается, что на данный момент скорость бэкапа очень маленькая и это планируется исправить в ближайшее будущее.