| 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.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, всё равно слишком накладно по пропускной способности диска/сети.
| | |
| |
| 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.42, vi (?), 11:16, 03/06/2012 [ответить] [﹢﹢﹢] [ · · · ] | +/– | Хорошо Шесть лет это немалый срок, может большенство косяков поправили Интерес... большой текст свёрнут, показать | | |
| |
| 2.61, fetisheer (ok), 15:06, 04/06/2012 [^] [^^] [^^^] [ответить]
| +/– |
 > Шесть лет это немалый срок, может большенство косяков поправили.
Шесть лет - это всего. На самом деле, я бы сказал, что активно Obnam разрабатывается три года. До этого был совершенно другой архитектурно продукт основанный на rsync.
>Чем то напоминает duplicity, может плюшек побольше?
>Может на основе него делают (или по идеям, и это хорошо ;)?
Его он пробовал использовать, но натолкнулся на некоторые ограничения и решил, что для устранения этих ограничений потребует слишком больших усилий по модификации duplicity. Самым большим ограничением, по мнению автора, является то, что duplicity делает полный бэкап, а потом инкрементные. Периодический полный бэкап он посчитал слишком нерациональным.
> Далее потихонечку смотреть, что забыли!?!?!?
Сам автор выделяет, кроме дедупликации две сильные стороны программы: поддержка snapshot и шифрования (через GnuPG). Еще отмечается, что на данный момент скорость бэкапа очень маленькая и это планируется исправить в ближайшее будущее.
| | |
|
|
