https://www.opennet.ru/openforum/vsluhforumID3/84848.html После шести лет разработки увидел свет (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.<br><br><br>Основные особенности Obnam:<br><br><br><br><br><br>- Резервные копии размещаются в специальном репозитории, данные в котором хранятся в оптимальном представлении с использованием дедупликации. При этом объединение дубликатов осуществляется для всех хранимых бэкапов, независимо от их типа, времени создания и источника резервной копии. В одном репозитории могут храниться бэкапы разных клиентов и серверов. Если на группе серверов используется одинаковая опер https://www.opennet.ru/openforum/vsluhforumID3/84848.html#66 Fri, 08 Jun 2012 18:50:15 GMT &gt;&gt; Что есть "битый кусок" в данном случае, если не секрет?<br>&gt; битый - это тот, который не возможно прочитать, или с порченными данными. <br><br>не не не, именно в данном случае - после создания бекапа и сверки контрольных сумм как там может оказаться битый кусок?<br><br><br> https://www.opennet.ru/openforum/vsluhforumID3/84848.html#65 Wed, 06 Jun 2012 16:46:55 GMT В последнее время плотно занимался этим вопросом (zfs+дедупликация рулят для хранения сотен гиг lvm-снапшотов), так вот есть подводный камень: zfs стабильна на соляре и вроде бы опен-индиане. Т.к. дедупликатор представляет собой упаковщик с безразмерным словарем (в текущей реализации вроде пользует sha256-хэши блоков, вероятность коллизии что-то в районе 10-31, я эту математику не осилил, так что лучше перепроверьте), код дедупликатора должен как-то ограничивать аппетиты (оценка ~5 GB RAM per 1 TB DATA). Во FreeBSD 9.0 он с этим не справляется &gt;&gt; kernel panic. Есть еще "Native ZFS for Linux", его потестить руки пока не дошли.<br> Для себя выбрал OpenIndiana domu over xen4.1 dom0 - современных процов хватает протащить гигабитный поток данных с учетом всех пенальти. Важно разумно выбирать размер пула, т.к. БД дедупликатора одна на каждый пул.<br> https://www.opennet.ru/openforum/vsluhforumID3/84848.html#64 Tue, 05 Jun 2012 13:19:34 GMT На питоне? Счастливого тестирования! :)<br> https://www.opennet.ru/openforum/vsluhforumID3/84848.html#63 Tue, 05 Jun 2012 10:11:29 GMT &gt;&gt; Что есть "битый кусок" в данном случае, если не секрет?<br>&gt; битый - это тот, который не возможно прочитать, или с порченными данными. <br>&gt; Именно поэтому, например symantec NBU, хоть и делает дедуп, но только <br>&gt; на диске, с последующим destage полных (читай собранных из dedup) образов <br>&gt; на ленту.<br><br>та же zfs от этого избавляет, храня несколько копий на разных носителях и сравнивая их хеши.<br> https://www.opennet.ru/openforum/vsluhforumID3/84848.html#62 Tue, 05 Jun 2012 05:59:42 GMT Например в ZFS все хешируется, при нарушении хеша автоматом лечится. Чтобы быть увереным, что коллизий хеша не будет - можно включить проверку перед записью.<br>Можно также хранить несколько копий на одном диске, хотя это не сильно поможет, если диск серьезно посыпется.<br>В общем в плане хранилища велосипеды.<br> https://www.opennet.ru/openforum/vsluhforumID3/84848.html#61 Mon, 04 Jun 2012 11:06:41 GMT &gt; Шесть лет это немалый срок, может большенство косяков поправили.<br><br>Шесть лет - это всего. На самом деле, я бы сказал, что активно Obnam разрабатывается три года. До этого был совершенно другой архитектурно продукт основанный на rsync.<br><br>&gt;Чем то напоминает duplicity, может плюшек побольше?<br>&gt;Может на основе него делают (или по идеям, и это хорошо ;)?<br><br>Его он пробовал использовать, но натолкнулся на некоторые ограничения и решил, что для устранения этих ограничений потребует слишком больших усилий по модификации duplicity. Самым большим ограничением, по мнению автора, является то, что duplicity делает полный бэкап, а потом инкрементные. Периодический полный бэкап он посчитал слишком нерациональным.<br><br>&gt; Далее потихонечку смотреть, что забыли!?!?!?<br><br>Сам автор выделяет, кроме дедупликации две сильные стороны программы: поддержка snapshot и шифрования (через GnuPG). Еще отмечается, что на данный момент скорость бэкапа очень маленькая и это планируется исправить в ближайшее будущее.<br> https://www.opennet.ru/openforum/vsluhforumID3/84848.html#60 Mon, 04 Jun 2012 08:27:43 GMT &gt; Что есть "битый кусок" в данном случае, если не секрет?<br><br>битый - это тот, который не возможно прочитать, или с порченными данными. Именно поэтому, например symantec NBU, хоть и делает дедуп, но только на диске, с последующим destage полных (читай собранных из dedup) образов на ленту.<br> https://www.opennet.ru/openforum/vsluhforumID3/84848.html#59 Mon, 04 Jun 2012 03:15:42 GMT &gt; В Btrfs не известно когда увидим работающую дедупликацию. В рассылке писали что <br>&gt; уже можно дедуплицировать по расписанию и пример утилиты был, но опции <br>&gt; для онлайн дедупликации нет и возможно не будет. Кто-то из разработчиков <br>&gt; писал, что идеологически не верно делать дедупликацию в ФС, а надо <br>&gt; на прикладном уровне как в Obnam. По-своему он конечно прав.<br><br>По моему он совсем не прав. Теряется прорачность доступа к данным, если делать дедуплекацию через прикладной уровень, к тому же нужно держать карту хешей, которая в фс уже и так есть<br><br>&gt; ZFS &#8213; латентная проприетарь со всеми вытекающими. Если данный факт не смущает, <br>&gt; то можно уже рсинкать на ZFS. =) Но проприетарные ынтырпрайз решения <br>&gt; с дедупликацией существовали задолго до ZFS и благополучно покупаются теми кому <br>&gt; очень надо.<br><br>Латентная или не латентная, а свободная и еще можно поспорить что свободнее, CDDL или GPL. Бекапы уже написаны: sh,rsync,zfs,snapshot + прочие плюшки zfs, типа прозрачного сжатия данных и дедупликации. В https://www.opennet.ru/openforum/vsluhforumID3/84848.html#57 Sun, 03 Jun 2012 14:33:55 GMT &gt; Ну дык. Но если оказывается, что у нас бэкап дедуплицируется, то вполне <br>&gt; можем огрести ситуацию, когда все экземпляры бэкапа имеют битый кусок, даже <br>&gt; если все бэкапы полные.<br><br>Что есть "битый кусок" в данном случае, если не секрет?<br>