форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Представлена система резервного копирования Obnam 1.0, подде..."	+/–
Сообщение от opennews (??) on 02-Июн-12, 15:43
После шести лет разработки увидел свет (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.dev/opennews/art.shtml?num=33997
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

2. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
Сообщение от AlexAT (ok) on 02-Июн-12, 15:45
Kewl, начинаем тестить.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	64. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от Аноним (??) on 05-Июн-12, 17:19
	На питоне? Счастливого тестирования! :)
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

3. "Представлена система резервного копирования Obnam 1.0, подде..."	+1 +/–
Сообщение от Crazy Alex (??) on 02-Июн-12, 15:48
Дедуплицироанные бэкапы??? Они б хоть возможность в двух копиях хранить сделали.. Это ж классика - нужно выдернуть что-то полугодовой давности, берём бэкап... а он инкрементный, и кусок данных в нём записан со сбоем. Вот и ждесь то же самое может быть запросто - они ж наверняка по хеш какой-нибудь для блоков расчитывают и пишут, и уже по нему делают дедупликацию.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от Аноним (??) on 02-Июн-12, 17:08
	Так-то и проверить целостность записанного можно. Может там хеши обновляются периодически. Все реализуемо. Оно бы еще умело винду бекапить простым преднастроенным клиентом, а то заморачиваться с cygwin на Н машин как-то ломает. Линукс, то и так бэкапится в 2 счета.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	8. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от Аноним (??) on 02-Июн-12, 17:35
	> Так-то и проверить целостность записанного можно. Так ить бэд сектор на бэкапном носителе может всраться опосля проверки. А постоянно его мурыжить проверками - сами понимаете. То что перец упомянул - вполне обычная ситуация, те кто имеет дело с бэкапами на регулярной основе - отлично в курсе этих грабель.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	9. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от Crazy Alex (??) on 02-Июн-12, 17:38
	Ну, as for me - чем проще операции, проделываемые с бэкапом и чем их меньше - тем спокойнее. Идеал в этом плане - всё же стример или писалка с автоподачей носителей. Чтобы всё в принципе было физически развязано. А из реального - RAID, хорошая схема интерлива и периодический перенос части полных бэкапов куда-то в другое место, либо параллельный бэкап в разные точки. Особенно для всяких офисов актуально, где дай бог чтобы серверная была, а физически угробить всё молжет хоть свихнувшаяся система пожаротушения хоть вечно свихнувшаяся СБУ.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	10. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от angra (ok) on 02-Июн-12, 18:45
	Вы же сами себе ответили. Не важно, есть дедупликация, нет дедупликации, надо делать более одного backup, само собой на разные физические носители, желательно географически разнесенные. Кстати к RAID это тоже относится, никакой надежности он не дает, только сокращает downtime. Стример и cd писалки это вообще архаика времен дорогого места на винчестерах и флешках.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	11. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от Аноним (??) on 02-Июн-12, 18:54
	В любом случае одно другое дополняет, а не заменяет.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	15. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от Crazy Alex (??) on 02-Июн-12, 20:00
	Так это два разных случая. Один - это когда защиту надо обеспечить всерьёз. Здесь - распределённые бэкапы и сменные носители. Другой - когда у нас ограниченные средства, и на них надо по-максимуму сделать надежность. Здесь - рейд, интерлив и иногда бэкап вовне, потому что постоянный удалённый бэкап - это дорого и/или медленно. Стример и писалка (с соответствующими автоматами) дают принципиально важное свойство - изоляция носителя от системы. Записали мы на ленту - и она уехала в банк. Даже если после этого по системе проедется 220 вольт и всё сгорит к чертям, лента не пострадает. Заведомо однократно записываемый диск ещё лучше в этом плане - тут уже и злоумышленник подчистить ничего не сможет.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	19. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от angra (ok) on 02-Июн-12, 21:54
	Это действительно два разных случая, но только не так как вы это понимаете(ну или формулируете). RAID вообще никаким местом к бэкапам не относится, ни к дорогим, ни к дешевым. По поводу изоляции носителя. Флешка в этом плане ничем не хуже ленты или дисков, только удобнее и дешевле. Про злоумышленника вообще детский сад какой-то, взять другой cd-r и записать на него измененный вариант данных ему совесть не позволит?
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	23. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от Crazy Alex (??) on 02-Июн-12, 22:52
	> Это действительно два разных случая, но только не так как вы это > понимаете(ну или формулируете). RAID вообще никаким местом к бэкапам не относится, > ни к дорогим, ни к дешевым. > По поводу изоляции носителя. Флешка в этом плане ничем не хуже ленты > или дисков, только удобнее и дешевле. Про злоумышленника вообще детский сад > какой-то, взять другой cd-r и записать на него измененный вариант данных > ему совесть не позволит? Флешка дороже дисков и живёт меньше чем лента. В остальном - если есть банки, работающий с флешками и использовать те, что имеют реальную защиту от записи - да, вероятно, не хуже. А RAID очень даже при делах - в "дешевом" случае, когда основная часть бэкапов - локальна и только некотрые мы сохраняем удалённо. Тогда он хорошо повышает вероятность того, что данный нужный бэкап (не сохранённый удалённо) всё же жив, а не сдох вместе с диском. В "дорогом" случае, конечно, RAID неактуален или за него отвечает какой-нибудь Amazon.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	29. "Представлена система резервного копирования Obnam 1.0, подде..."	–1 +/–
	Сообщение от Af. on 03-Июн-12, 00:16
	> А RAID очень даже при делах - в "дешевом" случае, когда основная > часть бэкапов - локальна и только некотрые мы сохраняем удалённо. Тогда > он хорошо повышает вероятность того, что данный нужный бэкап (не сохранённый > удалённо) всё же жив, а не сдох вместе с диском. В > "дорогом" случае, конечно, RAID неактуален или за него отвечает какой-нибудь Amazon. Только RAID тогда должен быть софтверный, или должно быть несколько запасных контроллеров. А то сгорел контроллер, в продаже уже их нет, а данные записаны в уникальном формате контроллера. Люди попадали на это, когда NAS с рейдами сгорал - диски оставались исправны (близок локоток), а данные в формате неизвестного изобретателя (а не укусишь, локоток). И надо мониторить состояние рейда и вовремя реагировать. Домашние - не умеют мониторить, не знают возможности этого, ошибочно надеются на RAID. Он вторичен, а иногда бесполезен. P.S. Занятно, клиент сам иницирует бекап. Раньше, вроде, принято было, что только сервер инициирует бекап. Или я не понял, или утверждается, что эту систему лучше настроить в режиме push, когда она по инициативе клиента может сделать всё что угодно со своим бекапом - уничтожить, например. А при режиме push сервер используется тупо как флешка - тупо расшаренный по SFTP каталог для сброса данных, _вся_ логика, все права доступа к бекапу клиента управляются самим клиентом. Похоже в тексте новости логика описана странно. Вероятно разница между push-pull в установке клиент-программы Obnam на клиенте. Тогда как серверная часть Obnam установлена на сервере в любом случае.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	45. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от AlexAT (ok) on 03-Июн-12, 13:20
	а должен быть софтверный, или должно быть несколько запасных контроллеров. > А то сгорел контроллер, в продаже уже их нет, а данные > записаны в уникальном формате контроллера. Тьфу-тьфу, современные LSI пишут данные в "стандартном" формате, и они очень легко монтируются через device mapper. Даже R5/R6.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	12. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от Аноним (??) on 02-Июн-12, 18:56
	Ну и бэкапьте себе "снепшоты". Эта система допускает. Если систему сделали с такими вот интересными фичами, то это не значит, что теперь она обязана заменить все способы рез коп-я. Тем более, что клинтов под винду еще нет (и, похоже, не планируются)
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	16. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от Crazy Alex (??) on 02-Июн-12, 20:01
	> Ну и бэкапьте себе "снепшоты". Эта система допускает. > Если систему сделали с такими вот интересными фичами, то это не значит, > что теперь она обязана заменить все способы рез коп-я. > Тем более, что клинтов под винду еще нет (и, похоже, не планируются) Э... При чём здесь снэпшоты?
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	30. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от Аноним (??) on 03-Июн-12, 01:23
	Шоп бэкапить на второй хост же, снять консистентное состояние того чего вам надо (либо всей ФС с дедублицированными бэкапами либо состояния какой-то системы из бекапа)
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	54. "Представлена система резервного копирования Obnam 1.0, подде..."	+1 +/–
	Сообщение от Crazy Alex (??) on 03-Июн-12, 18:00
	Угу, давайте в придачу к хитрому бэкапу с дедупликацией ещё снапшоты навернём, а потом со всей этой хренью попытаемся взлететь. Еще раз - система бэкапов должна быть ПРОСТОЙ. С минимумов компонент и сложности кода.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	24. "Представлена система резервного копирования Obnam 1.0, подде..."	+1 +/–
	Сообщение от mitiok (ok) on 02-Июн-12, 22:53
	а вы раз в неделю делайте полный бекап, а инкрементальные - раз в день. обычное же дело.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	55. "Представлена система резервного копирования Obnam 1.0, подде..."	+1 +/–
	Сообщение от Crazy Alex (??) on 03-Июн-12, 18:02
	Ну дык. Но если оказывается, что у нас бэкап дедуплицируется, то вполне можем огрести ситуацию, когда все экземпляры бэкапа имеют битый кусок, даже если все бэкапы полные.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	57. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от XoRe (ok) on 03-Июн-12, 18:33
	> Ну дык. Но если оказывается, что у нас бэкап дедуплицируется, то вполне > можем огрести ситуацию, когда все экземпляры бэкапа имеют битый кусок, даже > если все бэкапы полные. Что есть "битый кусок" в данном случае, если не секрет?
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	60. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от Аноним (??) on 04-Июн-12, 12:27
	> Что есть "битый кусок" в данном случае, если не секрет? битый - это тот, который не возможно прочитать, или с порченными данными. Именно поэтому, например symantec NBU, хоть и делает дедуп, но только на диске, с последующим destage полных (читай собранных из dedup) образов на ленту.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	63. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от Аноним (??) on 05-Июн-12, 14:11
	>> Что есть "битый кусок" в данном случае, если не секрет? > битый - это тот, который не возможно прочитать, или с порченными данными. > Именно поэтому, например symantec NBU, хоть и делает дедуп, но только > на диске, с последующим destage полных (читай собранных из dedup) образов > на ленту. та же zfs от этого избавляет, храня несколько копий на разных носителях и сравнивая их хеши.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	66. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от XoRe (ok) on 08-Июн-12, 22:50
	>> Что есть "битый кусок" в данном случае, если не секрет? > битый - это тот, который не возможно прочитать, или с порченными данными. не не не, именно в данном случае - после создания бекапа и сверки контрольных сумм как там может оказаться битый кусок?
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	25. "Представлена система резервного копирования Obnam 1.0, подде..."	+1 +/–
	Сообщение от filosofem (ok) on 02-Июн-12, 23:08
	>Дедуплицироанные бэкапы??? Они б хоть возможность в двух копиях хранить сделали.. Это ж классика - нужно выдернуть что-то полугодовой давности, берём бэкап... а он инкрементный, и кусок данных в нём записан со сбоем. В мане есть опция --deduplicate=never de-duplicate. Можно держать любое количество полных копий, так же как и при инкрементальном и дифференциальном. Или --deduplicate=verify that no hash collisions happen. В этом случае очевидно, что сбойный блок будет выглядеть как коллизия при сравнении с самим собой правильным. Плюс опции --verify и --fsck. При желании можно достаточно надежно соломкой обложиться. =)
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	62. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от Elhana (ok) on 05-Июн-12, 09:59
	Например в ZFS все хешируется, при нарушении хеша автоматом лечится. Чтобы быть увереным, что коллизий хеша не будет - можно включить проверку перед записью. Можно также хранить несколько копий на одном диске, хотя это не сильно поможет, если диск серьезно посыпется. В общем в плане хранилища велосипеды.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

13. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
Сообщение от AlexAT (ok) on 02-Июн-12, 19:10
Потестил немного. Ну... идея, конечно, интересная. Производительность тоже неплохая. Но пока не научится не снимать хеши не изменявшихся с последнего захода файлов, как это делает tar, всё равно слишком накладно по пропускной способности диска/сети.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

17. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
Сообщение от YetAnotherOnanym on 02-Июн-12, 20:41
На заметку возьму, но переходить с Бакулы не буду :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

22. "Представлена система резервного копирования Obnam 1.0, подде..."	+1 +/–
Сообщение от Anonymousw on 02-Июн-12, 22:37
Круче rsync наверное ни чего нет.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

26. "Представлена система резервного копирования Obnam 1.0, подде..."	+1 +/–
Сообщение от MozgoTrest on 02-Июн-12, 23:10
Да, хрену к ней не хватает, то есть возможностей rsynca.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	34. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от ffirefox on 03-Июн-12, 01:45
	А rsync дедубликацию поддерживает? Актуально для однотипно настроенных компьютеров. А если файл просто переименовать, то rsync поймет, что не надо заново копировать?
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	36. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от Аноним (??) on 03-Июн-12, 03:18
	Понять-то поймет, опция подсчета хэшей у него есть (название не помню, надо в ман лезть), но памяти под это дело выжрет — мама не горюй.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	39. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от Аноним (??) on 03-Июн-12, 08:30
	> А rsync дедубликацию поддерживает? Актуально для однотипно настроенных компьютеров. zfs/btrfs?
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	43. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от filosofem (ok) on 03-Июн-12, 12:35
	В Btrfs не известно когда увидим работающую дедупликацию. В рассылке писали что уже можно дедуплицировать по расписанию и пример утилиты был, но опции для онлайн дедупликации нет и возможно не будет. Кто-то из разработчиков писал, что идеологически не верно делать дедупликацию в ФС, а надо на прикладном уровне как в Obnam. По-своему он конечно прав. ZFS ― латентная проприетарь со всеми вытекающими. Если данный факт не смущает, то можно уже рсинкать на ZFS. =) Но проприетарные ынтырпрайз решения с дедупликацией существовали задолго до ZFS и благополучно покупаются теми кому очень надо.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	59. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от Аноним (??) on 04-Июн-12, 07:15
	> В Btrfs не известно когда увидим работающую дедупликацию. В рассылке писали что > уже можно дедуплицировать по расписанию и пример утилиты был, но опции > для онлайн дедупликации нет и возможно не будет. Кто-то из разработчиков > писал, что идеологически не верно делать дедупликацию в ФС, а надо > на прикладном уровне как в Obnam. По-своему он конечно прав. По моему он совсем не прав. Теряется прорачность доступа к данным, если делать дедуплекацию через прикладной уровень, к тому же нужно держать карту хешей, которая в фс уже и так есть > ZFS ― латентная проприетарь со всеми вытекающими. Если данный факт не смущает, > то можно уже рсинкать на ZFS. =) Но проприетарные ынтырпрайз решения > с дедупликацией существовали задолго до ZFS и благополучно покупаются теми кому > очень надо. Латентная или не латентная, а свободная и еще можно поспорить что свободнее, CDDL или GPL. Бекапы уже написаны: sh,rsync,zfs,snapshot + прочие плюшки zfs, типа прозрачного сжатия данных и дедупликации. В итоге не ломаемое решение из-за своей дубовости, моментальный доступ к любому снимку данных (а не как обычно в инкрементных бекапах - по полчаса думает) и отличная прозрачность. И прозрачность тут будет даже побольше, чем в полных бекапах запакованных tar-ом, т.к. здесь распаковывать ничего не нужно (например что бы diff сделать), просто идешь и в .zfs/snapshot и работаешь с данными от нужной даты.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	65. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от PnD (??) on 06-Июн-12, 20:46
	В последнее время плотно занимался этим вопросом (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 - современных процов хватает протащить гигабитный поток данных с учетом всех пенальти. Важно разумно выбирать размер пула, т.к. БД дедупликатора одна на каждый пул.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

28. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
Сообщение от Pilat (ok) on 02-Июн-12, 23:30
backuppc вроде делает то же самое, но у него и интерфейс есть, и работает у многих давно. А это... ну сделают на сервере бэкап. А мне его надо на домашний забрать - и как? А никак. Вещь в себе.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	31. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от Аноним (??) on 03-Июн-12, 01:36
	>  А мне его надо на домашний забрать - и как? > А никак. Вещь в себе. А в бэкапписи тоже самое. Данные сжимаются и переименовываются пофайлово. Восстановить и скачать можно только через веб интерфейс. Еще как в себе. Сервре бэкапов упадет и надо поднимать новый чтоб данные вытянуть, а дело это не простое т к в дистрах он бэкапписи недопиленный идет.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	38. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от Pilat (ok) on 03-Июн-12, 03:42
	>>  А мне его надо на домашний забрать - и как? >> А никак. Вещь в себе. > А в бэкапписи тоже самое. Данные сжимаются и переименовываются пофайлово. Восстановить Вот и я о том же - ничего нового не сделали, а интерфейса нормального нет. Шесть лет разрабатывали непонятно что.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	49. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от Михрютка on 03-Июн-12, 14:20
	> backuppc вроде делает то же самое, но у него и интерфейс есть, > и работает у многих давно. А это... ну сделают на сервере > бэкап. А мне его надо на домашний забрать - и как? > А никак. Вещь в себе. этот по крайней мере не требует рутового доступа с клиента, в отличие от.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

41. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
Сообщение от Anonymousw on 03-Июн-12, 09:45
rsync может делать инкременальные бэкапы!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	48. "Представлена система резервного копирования Obnam 1.0, подде..."	+1 +/–
	Сообщение от Михрютка on 03-Июн-12, 14:11
	но лучше б он этого не делал.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

42. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
Сообщение от vi on 03-Июн-12, 11:16
> После шести лет разработки увидел свет (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 (в случае взлома сервера резервного > копирования, скомпрометированными автоматически окажутся все клиенты); Надеюсть с правами только на чтение?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	61. "Представлена система резервного копирования Obnam 1.0, подде..."	+/–
	Сообщение от fetisheer (ok) on 04-Июн-12, 15:06
	> Шесть лет это немалый срок, может большенство косяков поправили. Шесть лет - это всего. На самом деле, я бы сказал, что активно Obnam разрабатывается три года. До этого был совершенно другой архитектурно продукт основанный на rsync. >Чем то напоминает duplicity, может плюшек побольше? >Может на основе него делают (или по идеям, и это хорошо ;)? Его он пробовал использовать, но натолкнулся на некоторые ограничения и решил, что для устранения этих ограничений потребует слишком больших усилий по модификации duplicity. Самым большим ограничением, по мнению автора, является то, что duplicity делает полный бэкап, а потом инкрементные. Периодический полный бэкап он посчитал слишком нерациональным. > Далее потихонечку смотреть, что забыли!?!?!? Сам автор выделяет, кроме дедупликации две сильные стороны программы: поддержка snapshot и шифрования (через GnuPG). Еще отмечается, что на данный момент скорость бэкапа очень маленькая и это планируется исправить в ближайшее будущее.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема