The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Представлена система резервного копирования Obnam 1.0, поддерживающая снапшоты и дедупликацию

02.06.2012 15:10

После шести лет разработки увидел свет первый стабильный релиз инструмента для организации резервного копирования данных - Obnam 1.0, при разработке которого делалась ставка на обеспечение высокой эффективности хранения в сочетании с безопасностью и простотой использования. Код программы написан на языке Python и распространяется в рамках лицензии GPLv3+. Готовые пакеты сформированы для Ubuntu (PPA) и Debian.

Основные особенности Obnam:

  • Резервные копии размещаются в специальном репозитории, данные в котором хранятся в оптимальном представлении с использованием дедупликации. При этом объединение дубликатов осуществляется для всех хранимых бэкапов, независимо от их типа, времени создания и источника резервной копии. В одном репозитории могут храниться бэкапы разных клиентов и серверов. Если на группе серверов используется одинаковая операционная система, то в репозитории физически будет сохранена только одна копия повторяющихся файлов, что позволяет существенно экономить дисковое пространство при организации резервного копирования большого числа типовых систем, например, виртуальных окружений;
  • Поддержка размещения репозитория для хранения резервных копий на локальном диске и на внешних серверах с использованием для доступа к данным протокола SSH SFTP (для создания сервера для хранения резервных копий не требуется установка дополнительных программ, достаточно обычного SSH-доступа);
  • Режим доступа к резервным копиям в форме снапшотов. Доступ к данным, сохранённым в режиме инкрементального бэкапа, может быть организован в форме снапшота, при котором независимо от выбранной итерации виден полный срез всех данных, несмотря на то, что фактически в момент выбранной итерации могло быть скопировано несколько файлов. Т.е. для восстановления из инкрементальных копий можно сразу получить целостное содержимое ФС, без необходимости предварительного восстановления первичной копии с дальнейшим последовательным раскрытием инкрементальных копий;
  • Поддержка шифрования резервных копий с использованием GnuPG;
  • Поддержка режимов работы push и pull. В режиме push программа obnam устанавливается на стороне клиента и сохранение резервных копий инициируется клиентом. В режиме pull программа obnam устанавливается на сервер для хранения резервных копий и процесс копирования данных инициируется сервером (данные передаются по SFTP). С точки зрения безопасности предпочтителен режим push, так как для создания полной резервной копии в режиме pull требуется открытие удалённого доступа к ФС клиента с правами root (в случае взлома сервера резервного копирования, скомпрометированными автоматически окажутся все клиенты);
  • Из планов на будущее отмечается проведение работы по оптимизации производительности, создание FUSE-модуля для доступа к резервным копиям через монтирование виртуального раздела и реализация режима непрерывного резервного копирования.


  1. Главная ссылка к новости (http://blog.liw.fi/posts/obnam...)
  2. OpenNews: В ZFS появилась поддержка исключения дубликатов
  3. OpenNews: Opendedup - файловая система с автоматическим объединением дубликатов данных
  4. fsbackup - система инкрементального резервного копирования и синхронизации ФС
  5. OpenNews: В файловой системе HAMMER появилась поддержка объединения дубликатов
  6. OpenNews: ddpt - расширенный вариант утилиты dd
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/33997-backup
Ключевые слова: backup, obnam, snapshot
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (43) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, AlexAT (ok), 15:45, 02/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Kewl, начинаем тестить.
     
     
  • 2.64, Аноним (-), 17:19, 05/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    На питоне? Счастливого тестирования! :)
     

  • 1.3, Crazy Alex (??), 15:48, 02/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Дедуплицироанные бэкапы??? Они б хоть возможность в двух копиях хранить сделали.. Это ж классика - нужно выдернуть что-то полугодовой давности, берём бэкап... а он инкрементный, и кусок данных в нём записан со сбоем. Вот и ждесь то же самое может быть запросто - они ж наверняка по хеш какой-нибудь для блоков расчитывают и пишут, и уже по нему делают дедупликацию.
     
     
  • 2.5, Аноним (-), 17:08, 02/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Так-то и проверить целостность записанного можно. Может там хеши обновляются периодически. Все реализуемо.

    Оно бы еще умело винду бекапить простым преднастроенным клиентом, а то заморачиваться с cygwin на Н машин как-то ломает. Линукс, то и так бэкапится в 2 счета.

     
     
  • 3.8, Аноним (-), 17:35, 02/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Так-то и проверить целостность записанного можно.

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

     
  • 3.9, Crazy Alex (??), 17:38, 02/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, as for me - чем проще операции, проделываемые с бэкапом и чем их меньше - тем спокойнее. Идеал в этом плане - всё же стример или писалка с автоподачей носителей. Чтобы всё в принципе было физически развязано. А из реального - RAID, хорошая схема интерлива и периодический перенос части полных бэкапов куда-то в другое место, либо параллельный бэкап в разные точки. Особенно для всяких офисов актуально, где дай бог чтобы серверная была, а физически угробить всё молжет хоть свихнувшаяся система пожаротушения хоть вечно свихнувшаяся СБУ.
     
     
  • 4.10, angra (ok), 18:45, 02/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Вы же сами себе ответили. Не важно, есть дедупликация, нет дедупликации, надо делать более одного backup, само собой на разные физические носители, желательно географически разнесенные. Кстати к RAID это тоже относится, никакой надежности он не дает, только сокращает downtime. Стример и cd писалки это вообще архаика времен дорогого места на винчестерах и флешках.
     
     
  • 5.11, Аноним (-), 18:54, 02/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    В любом случае одно другое дополняет, а не заменяет.
     
  • 5.15, Crazy Alex (??), 20:00, 02/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Так это два разных случая. Один - это когда защиту надо обеспечить всерьёз. Здесь - распределённые бэкапы и сменные носители. Другой - когда у нас ограниченные средства, и на них надо по-максимуму сделать надежность. Здесь - рейд, интерлив и иногда бэкап вовне, потому что постоянный удалённый бэкап - это дорого и/или медленно.

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

     
     
  • 6.19, angra (ok), 21:54, 02/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Это действительно два разных случая, но только не так как вы это понимаете(ну или формулируете). RAID вообще никаким местом к бэкапам не относится, ни к дорогим, ни к дешевым.

    По поводу изоляции носителя. Флешка в этом плане ничем не хуже ленты или дисков, только удобнее и дешевле. Про злоумышленника вообще детский сад какой-то, взять другой cd-r и записать на него измененный вариант данных ему совесть не позволит?

     
     
  • 7.23, Crazy Alex (??), 22:52, 02/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Это действительно два разных случая, но только не так как вы это
    > понимаете(ну или формулируете). RAID вообще никаким местом к бэкапам не относится,
    > ни к дорогим, ни к дешевым.
    > По поводу изоляции носителя. Флешка в этом плане ничем не хуже ленты
    > или дисков, только удобнее и дешевле. Про злоумышленника вообще детский сад
    > какой-то, взять другой cd-r и записать на него измененный вариант данных
    > ему совесть не позволит?

    Флешка дороже дисков и живёт меньше чем лента. В остальном - если есть банки, работающий с флешками и использовать те, что имеют реальную защиту от записи - да, вероятно, не хуже.

    А RAID очень даже при делах - в "дешевом" случае, когда основная часть бэкапов - локальна и только некотрые мы сохраняем удалённо. Тогда он хорошо повышает вероятность того, что данный нужный бэкап (не сохранённый удалённо) всё же жив, а не сдох вместе с диском. В "дорогом" случае, конечно, RAID неактуален или за него отвечает какой-нибудь Amazon.

     
     
  • 8.29, Af. (?), 00:16, 03/06/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Только RAID тогда должен быть софтверный, или должно быть несколько запасных кон... текст свёрнут, показать
     
     
  • 9.45, AlexAT (ok), 13:20, 03/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    а должен быть софтверный, или должно быть несколько запасных контроллеров Тьфу... текст свёрнут, показать
     
  • 4.12, Аноним (-), 18:56, 02/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ну и бэкапьте себе "снепшоты". Эта система допускает.
    Если систему сделали с такими вот интересными фичами, то это не значит, что теперь она обязана заменить все способы рез коп-я.
    Тем более, что клинтов под винду еще нет (и, похоже, не планируются)
     
     
  • 5.16, Crazy Alex (??), 20:01, 02/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну и бэкапьте себе "снепшоты". Эта система допускает.
    > Если систему сделали с такими вот интересными фичами, то это не значит,
    > что теперь она обязана заменить все способы рез коп-я.
    > Тем более, что клинтов под винду еще нет (и, похоже, не планируются)

    Э... При чём здесь снэпшоты?

     
     
  • 6.30, Аноним (-), 01:23, 03/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Шоп бэкапить на второй хост же, снять консистентное состояние того чего вам надо (либо всей ФС с дедублицированными бэкапами либо состояния какой-то системы из бекапа)
     
     
  • 7.54, Crazy Alex (??), 18:00, 03/06/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Угу, давайте в придачу к хитрому бэкапу с дедупликацией ещё снапшоты навернём, а потом со всей этой хренью попытаемся взлететь. Еще раз - система бэкапов должна быть ПРОСТОЙ. С минимумов компонент и сложности кода.
     
  • 2.24, mitiok (ok), 22:53, 02/06/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    а вы раз в неделю делайте полный бекап, а инкрементальные - раз в день. обычное же дело.
     
     
  • 3.55, Crazy Alex (??), 18:02, 03/06/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну дык. Но если оказывается, что у нас бэкап дедуплицируется, то вполне можем огрести ситуацию, когда все экземпляры бэкапа имеют битый кусок, даже если все бэкапы полные.
     
     
  • 4.57, XoRe (ok), 18:33, 03/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну дык. Но если оказывается, что у нас бэкап дедуплицируется, то вполне
    > можем огрести ситуацию, когда все экземпляры бэкапа имеют битый кусок, даже
    > если все бэкапы полные.

    Что есть "битый кусок" в данном случае, если не секрет?

     
     
  • 5.60, Аноним (-), 12:27, 04/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Что есть "битый кусок" в данном случае, если не секрет?

    битый - это тот, который не возможно прочитать, или с порченными данными. Именно поэтому, например symantec NBU, хоть и делает дедуп, но только на диске, с последующим destage полных (читай собранных из dedup) образов на ленту.

     
     
  • 6.63, Аноним (-), 14:11, 05/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Что есть "битый кусок" в данном случае, если не секрет?
    > битый - это тот, который не возможно прочитать, или с порченными данными.
    > Именно поэтому, например symantec NBU, хоть и делает дедуп, но только
    > на диске, с последующим destage полных (читай собранных из dedup) образов
    > на ленту.

    та же zfs от этого избавляет, храня несколько копий на разных носителях и сравнивая их хеши.

     
  • 6.66, XoRe (ok), 22:50, 08/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Что есть "битый кусок" в данном случае, если не секрет?
    > битый - это тот, который не возможно прочитать, или с порченными данными.

    не не не, именно в данном случае - после создания бекапа и сверки контрольных сумм как там может оказаться битый кусок?


     
  • 2.25, filosofem (ok), 23:08, 02/06/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Дедуплицироанные бэкапы??? Они б хоть возможность в двух копиях хранить сделали.. Это ж классика - нужно выдернуть что-то полугодовой давности, берём бэкап... а он инкрементный, и кусок данных в нём записан со сбоем.

    В мане есть опция --deduplicate=never de-duplicate. Можно держать любое количество полных копий, так же как и при инкрементальном и дифференциальном. Или --deduplicate=verify that no hash collisions happen. В этом случае очевидно, что сбойный блок будет выглядеть как коллизия при сравнении с самим собой правильным. Плюс опции --verify и --fsck. При желании можно достаточно надежно соломкой обложиться. =)

     
  • 2.62, Elhana (ok), 09:59, 05/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Например в ZFS все хешируется, при нарушении хеша автоматом лечится. Чтобы быть увереным, что коллизий хеша не будет - можно включить проверку перед записью.
    Можно также хранить несколько копий на одном диске, хотя это не сильно поможет, если диск серьезно посыпется.
    В общем в плане хранилища велосипеды.
     

  • 1.13, AlexAT (ok), 19:10, 02/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Потестил немного. Ну... идея, конечно, интересная. Производительность тоже неплохая. Но пока не научится не снимать хеши не изменявшихся с последнего захода файлов, как это делает tar, всё равно слишком накладно по пропускной способности диска/сети.
     
  • 1.17, YetAnotherOnanym (?), 20:41, 02/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На заметку возьму, но переходить с Бакулы не буду :)
     
  • 1.22, Anonymousw (?), 22:37, 02/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Круче rsync наверное ни чего нет.
     
  • 1.26, MozgoTrest (?), 23:10, 02/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Да, хрену к ней не хватает, то есть возможностей rsynca.
     
     
  • 2.34, ffirefox (?), 01:45, 03/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А rsync дедубликацию поддерживает? Актуально для однотипно настроенных компьютеров.
    А если файл просто переименовать, то rsync поймет, что не надо заново копировать?


     
     
  • 3.36, Аноним (-), 03:18, 03/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Понять-то поймет, опция подсчета хэшей у него есть (название не помню, надо в ман лезть), но памяти под это дело выжрет — мама не горюй.
     
  • 3.39, Аноним (-), 08:30, 03/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А rsync дедубликацию поддерживает? Актуально для однотипно настроенных компьютеров.

    zfs/btrfs?

     
     
  • 4.43, filosofem (ok), 12:35, 03/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    В Btrfs не известно когда увидим работающую дедупликацию. В рассылке писали что уже можно дедуплицировать по расписанию и пример утилиты был, но опции для онлайн дедупликации нет и возможно не будет. Кто-то из разработчиков писал, что идеологически не верно делать дедупликацию в ФС, а надо на прикладном уровне как в Obnam. По-своему он конечно прав.
    ZFS ― латентная проприетарь со всеми вытекающими. Если данный факт не смущает, то можно уже рсинкать на ZFS. =) Но проприетарные ынтырпрайз решения с дедупликацией существовали задолго до ZFS и благополучно покупаются теми кому очень надо.
     
     
  • 5.59, Аноним (-), 07:15, 04/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    По моему он совсем не прав Теряется прорачность доступа к данным, если делать д... большой текст свёрнут, показать
     
     
  • 6.65, PnD (??), 20:46, 06/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
      В последнее время плотно занимался этим вопросом (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 - современных процов хватает протащить гигабитный поток данных с учетом всех пенальти. Важно разумно выбирать размер пула, т.к. БД дедупликатора одна на каждый пул.
     

  • 1.28, Pilat (ok), 23:30, 02/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    backuppc вроде делает то же самое, но у него и интерфейс есть, и работает у многих давно. А это... ну сделают на сервере бэкап. А мне его надо на домашний забрать - и как? А никак. Вещь в себе.
     
     
  • 2.31, Аноним (-), 01:36, 03/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >  А мне его надо на домашний забрать - и как?
    > А никак. Вещь в себе.

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


     
     
  • 3.38, Pilat (ok), 03:42, 03/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >>  А мне его надо на домашний забрать - и как?
    >> А никак. Вещь в себе.
    > А в бэкапписи тоже самое. Данные сжимаются и переименовываются пофайлово. Восстановить

    Вот и я о том же - ничего нового не сделали, а интерфейса нормального нет. Шесть лет разрабатывали непонятно что.

     
  • 2.49, Михрютка (?), 14:20, 03/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > backuppc вроде делает то же самое, но у него и интерфейс есть,
    > и работает у многих давно. А это... ну сделают на сервере
    > бэкап. А мне его надо на домашний забрать - и как?
    > А никак. Вещь в себе.

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

     

  • 1.41, Anonymousw (?), 09:45, 03/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    rsync может делать инкременальные бэкапы!
     
     
  • 2.48, Михрютка (?), 14:11, 03/06/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    но лучше б он этого не делал.
     

  • 1.42, vi (?), 11:16, 03/06/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хорошо Шесть лет это немалый срок, может большенство косяков поправили Интерес... большой текст свёрнут, показать
     
     
  • 2.61, fetisheer (ok), 15:06, 04/06/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Шесть лет это немалый срок, может большенство косяков поправили.

    Шесть лет - это всего. На самом деле, я бы сказал, что активно Obnam разрабатывается три года. До этого был совершенно другой архитектурно продукт основанный на rsync.

    >Чем то напоминает duplicity, может плюшек побольше?
    >Может на основе него делают (или по идеям, и это хорошо ;)?

    Его он пробовал использовать, но натолкнулся на некоторые ограничения и решил, что для устранения этих ограничений потребует слишком больших усилий по модификации duplicity. Самым большим ограничением, по мнению автора, является то, что duplicity делает полный бэкап, а потом инкрементные. Периодический полный бэкап он посчитал слишком нерациональным.

    > Далее потихонечку смотреть, что забыли!?!?!?

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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру