Схоронил

почему не хочу юзать бакулу? слишком много всего будет в конфигах, хочется чтобы такая инфа хранилась во внутренней базе(можно внешней mysql,pgsql), хочется меньше управлять через конфиги.

когда мои танки войдут в Москвукогда буду писать свою замену BareOS'а (читай: никогда) учту такую ситуацию.

слишком много всего будет в конфигах, хочется чтобы такая инфа хранилась во внутренней базе

Тебе файлы принципиально неудобны или просто неудобно иметь дело с одним очень большим файлом?

Тебе файлы принципиально неудобны или просто неудобно иметь дело с одним очень большим файлом?

Там же можно на несколько файлов разбить. @/path/to/file

Bacula - оптимальный выбор. 2 director'а (один основной, второй - cold standby, конфиги синхронизировать по incrond'у или ещё как-нибудь), 2 catalog'а на postgresql (один - основной, второй - hot standby на streaming replication), разбитые по группам конфиги Job'ов, как выше посоветовали, 2 storage'а - и ваша шерсть будет мягкой и шелковистой.

Да там можно и подключить содержимое каталога (правда через это самое место) : www.linux.org.ru/wiki/en/Bacula#a_.D0.92.D1.8B.D0.BD.D0.BE.D1.81_.D1.87.D0.B0...

Вот только может у него принципиальная идиосинкарзия к файлам...

У меня к самой бакуле идиосинкразия за годы выработалась ;) особенно к ее системе хранения бэкапов ленточноориентированной.

Если оно не ломается то можно относиться к ней как к чёрному ящику. А так — интересно что можно рассмотреть в качестве альтернативы.

Вообще: одна задача — один том, и пусть оно внутри себя ориентируется хоть на дискеты...

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

А из опенсурсного аналогов бакулы, похоже, действительно нет...

По поводу черного ящика - там геморрой именно в настройке и поддержке всего дела с оглядкой на volume/pool/retention/recycle/format/еще дохрена всяких слов, которые при бэкапе на диск нафиг не нужны. Выглядит и ощущается как колхоз.

I know that feel bro

У меня к самой бакуле идиосинкразия за годы выработалась ;) особенно к ее системе хранения бэкапов ленточноориентированной.

Аналогично. При этом свободной замены BareOS'у нет. Все остальные бэкапилки ещё хуже.

Вот нашёл интересный аналог - http://burp.grke.org/features.html

Там товарищъ как раз пишет что хотел аналог бакулы без всей её монструозности.

Надо попробовать. Есть агенты под винду.

BURP!

Вот нашёл интересный аналог - http://burp.grke.org/features.html

Очень интересно. Про недостатки Bacul'ы человек правильно излагает. Непонятно только все ли достоинства Bacul'ы он оценил? Поддерживает ли BURP тома (Volumes), серверы сохранения (Storage) отдельно от управляющих (Director)?

Поддерживает ли BURP тома (Volumes), серверы сохранения (Storage) отдельно от управляющих (Director)?

Нет, у него один демон, всё упрощено. Меня, в принципе, это устраивает. Если мне нужно будет бэкапить на другой сервер, я его по NFS подключу.

Погонял BURP энтот тестово - вполне вкусно. Само при первом подключении генерирует клиенту SSL сертификат, всё максимально автоматизировано. VSS умеет под виндой. Умеет передавать дельты файлов, в отличии от бакулы. В общем, надо гонять дальше.

Поганенько тут то, что, если захочешь добавить новый device в sd, его надо рестартить, что оборвёт текущие job. Я пока просто нагенерил девайсов себе пачку, заранее :)

An additional experimental version of Burp, which I have labelled 'Burp 2' is now available.

Пугает, конечно.

Так задачи-же не круглые сутки выполняются? Обычно вообще во внерабочее время.

Ой... В случае с bacula, тут возникает много забавностей. Оно не умеет diff на уровне содержимого файла. А умеет только на уровне целого файла из задания. Соот-но: у меня есть виртуальные машинки по 400 гб. Есть файловые сервера на такой же объём. - За ночь, я не успею всё сделать просто. По сему, я ограничиваю скорость работы job (1-4 mb/sec), и фигачу, чтобы не мешало никому.

у меня есть виртуальные машинки по 400 гб

Разбей виртуалки на систему и данные. Образ с системой получится маленький - его бэкапить целиком. Данные бэкапить изнутри виртуалки.

Есть файловые сервера на такой же объём

Тут уже сложнее.

я ограничиваю скорость работы job (1-4 mb/sec), и фигачу, чтобы не мешало никому

Надеюсь образы виртуалок бэкапятся не тогда когда они запущены?

Я кстати тоже на лоре искал что-нибудь вместо бакулы. Даже со всеми своими недостатками бакула все равно лучшая.

Тем более бэкапы настраиваются один раз и дальше нужно просто периодически проверять все ли в порядке.
Бэкапы это такая штука, которая должна быть надежной/ Лучше, проверенная временем, неудобная бакула, чем бэкапился, которая может подвести.

Разбей виртуалки на систему и данные. Образ с системой получится маленький - его бэкапить целиком. Данные бэкапить изнутри виртуалки.

Лень всё переделывать уже... У меня зоопарк из виртуалок: Ubuntu 10.04, 12.04, 14.04, FreeBSD.

Тут уже сложнее.

Забавность ещё в том, что там FreeBSD 6.x, с клиентом бакулы, там вообще не скучно. :)

Надеюсь образы виртуалок бэкапятся не тогда когда они запущены?

Делаю снепшот (от включенной машинки). Да, будет ребут. Но у меня супер критичные виртуалки (будут) бекапиться двумя способами (online+offline).

Тем более бэкапы настраиваются один раз и дальше нужно просто периодически проверять все ли в порядке.

Согласен. С моими скриптами в этом плане как раз и не особо удобно. По сему пришёл к выводу, что нужна bacula - у меня как-бы за три недели с одного из сервера вышло из строя три диска, при том два - сразу. Один чуть позже. Поднимался с холодного backup - главное что всё прошло ОК. Но решил особо не тянуть и настроить что-то более удобное + соеденить с zabbix.

Правда, не особо представляю как я буду bacula-fd настраивать на HP-UX 11. Ну да ладно, там в крайнем случае, буду через ignite с ленты подниматься...

Это багофича

В случае с bacula, тут возникает много забавностей. Оно не умеет diff на уровне содержимого файла. А умеет только на уровне целого файла из задания.

Это не баг и не фича, это неизбежное следствие из того как Bacula делает резервные копии. То что для резервного копирования не требуется доступность прошлой версии файла это большой плюс. Кроме того, с таким подходом можно на тома по 2 Tb копировать хоть 100 Tb задание, только успевай НЖМД или ленты менять. А чтобы делать binary diff'ы пришлось бы иметь доступную копию этих 100 Tb. Возможно разбивание крупных файлов на куски и сравнение контрольных сумм кусков улучшило бы ситуацию, но всё равно, если дописать хоть один байт в начале файла, то все куски получатся с другими контрольными суммами.

Да чур тебя! :)

То что для резервного копирования не требуется доступность прошлой версии файла это большой плюс.

Если ты делаешь инкрементальный backup или diff, то ещё как требуется всё то, что было сделано до.

только успевай НЖМД менять.

Один НЖМД сейчас стоит 12к, на 4ТБ если брать. Что весьма не дёшего, чтобы следовать политике: «только успевай менять».

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

Да снова чур тебя! Кто-ж так делает то..? Разбивают на фиксированные кусочки от начала файла. Например: 1к, 1к, 1к, 1к. - Если ты допишешь в начало, у тебя поменяется, или добавится только первый чанк. Иначе в этом не было бы смысла. Я тебе могу сказать, что я проработал много с rdiff-backup, так вот, тот по такому принципу работая, творит натуральные чудеса...

Возможно разбивание крупных файлов на куски и сравнение контрольных сумм кусков улучшило бы ситуацию

В тех условиях, когда у тебя есть три десятка вирт. машин, и средний объём машины 20 гб. - Это кардинально бы изменило ситуацию. А так - придётся делать переодический backup VM образов, и ставить агента внутрь, для получения инкрементных backup. - С rdiff-backup/zfs - такого не пришлось бы делать. Правда в случае с rdiff-backup приходится весьма прилично ждать пока оно там прожуёт всё. А при восстановлении скрещивать пальцы. Да. :)

И вообще bacula, при самом минимальном раскладе, тебя заставит держать как минимум две копии твоих данных.

Вот тебе пример:

Дано: 20 образов qcow2, по 20 гб. каждый. Задача: иметь как минимум два последних backup этих образов.

Bacula: 20x3x20 = 1.2 TB

Rdiff-backup: 20 x 20 = 400 gb (UP)

А если требуется более глубокое хранение..? Bacula проиграет, чуть более чем полностью, пока мест не обосрётся. :)

Пусть тебе надо хранить 5 backup:

Bacula: 20x6x20 = 2.4 TB

Rdiff-backup: 20 x 20 x diff = 400-500 gb (UP)

Однако, справедливости ради, отмечу, что и rdiff, и bacula, каждый раз у тебя будут вытягивать полный qcow2 образ. В отличии от той же zfs.

Ну и чтоб, уж совсем тебя добить, представь, что у меня есть pdf файлов, объёма на 2 ТБ (именно моя ситуация). - Как мне backup выполнять через bacula? Правильно. Я ОБОСРУСЬ это ей делать. Смотри: сперва я сделаю FullBackup, потом я буду делать инкременты, пока мест не затрахаюсь, потом я сделаю: VirtualFull backup. - А теперь представь, сколько я места угрохаю на всё это? Правильно, в лучшем случае: 4 ТБ. Это в лучшем. Но, лучше подстраховаться, и сделать в bacula три тома. - А это уже 6 ТБ. А с rdiff-backup, мне потребовалось бы: 2 ТБ. Ах да... Ещё не забудь, себе представить, как отхватит мой ввод вывод, на bacula-sd, когда я буду делать VirtualFull backup.

4.2

Если ты делаешь инкрементальный backup или diff, то ещё как требуется всё то, что было сделано до.

Не требуется. В случае с Bacul'ой прошлая версия файла может лежать где-то на отключенном томе в сейфе в бункере за 300 километров, нужна только её контрольная сумма в базе Director'а.

Как в таком случае будет работать rdiff-backup?

Один НЖМД сейчас стоит 12к, на 4ТБ если брать. Что весьма не дёшего, чтобы следовать политике: «только успевай менять».

Дорого или дёшево познаётся в сравнении. Например в сравнеии со стоимостью копируемых данных. Если у вас 100 Tb данных за которые в случае ЧП контора готова выложить мегабакс, то покупка нужного количества НЖМД (или ленточной библиотеки) не есть проблема.

Если ты допишешь в начало, у тебя поменяется, или добавится только первый чанк.

Кто этим будет заниматься? Кто гарантирует, что именно добавится ещё один chunk в начале, а не границы всех chunk'ов сдвинутся?

А при восстановлении скрещивать пальцы. Да. :)

Это не бэкап, а говно!

И вообще bacula, при самом минимальном раскладе, тебя заставит держать как минимум две копии твоих данных.

Ну да, оригинал и резервная копия. В этом вся суть. Или вы что-то другое имели в виду? Если у меня есть папка весом в 100 Tb, то у меня, пусть, в понедельник Job заполнит 25 томов по 4 Tb. Эти 25 томов я могу физически отключить и положить в архив на хранение. А во вторник запустить инкрементальный бэкап и заполнить ещё какое-то количество томов. А rdiff-backup позволит так сделать? rdiff-backup не попросит дать ему возможность читать то что я записал в понедельник и уже унёс архив и запер под замок, чтобы посчитать изменения в файлах?

Bacula: 20x3x20 = 1.2 TB
Rdiff-backup: 20 x 20 = 400 gb (UP)

Что это за бред вы сейчас написали? 2 копии в Bacul'е весят как 2 копии, но никак не 3, это про первую строчку. Каким образом rdiff-backup будет хранить 2 копии данных в 400 Gb в четырёхстах гигабайтах? Это же полный бред. Это про вторую строчку.

Ну и чтоб, уж совсем тебя добить, представь, что у меня есть pdf файлов, объёма на 2 ТБ (именно моя ситуация). - Как мне backup выполнять через bacula? Правильно. Я ОБОСРУСЬ это ей делать.

У меня на позапрошлой работе была именно такая ситуация, и я не обосрался. Я по субботам делал Full, по ночам будних дней Incremental. При том что Client, Director и Storage все на разных машинах.

Что такое VirtualFullBackup? Почему «минимум 4 ТБ»? У меня Full занимал, кажися 1,8 Гб, каждый Incremental по 0,1 Гб. Всё это нормально сохранялось на двухтерабайтные НЖМД, которые я старался менять по кругу, но часть начальник увозил к себе домой и забывал вовремя привезти обратно, так что порядок замены нарушался, но это не вызывало сбоев. Как результат конторе были не страшны маски-шоу и изъятие всех ЭВМ (не менее 1 копии всегда было вдали в офиса в укромном месте).

Ещё раз, полная копия данных весит как полная копия данных независимо от того используется ли Bacula, tar или rdiff-backup. Магии не существует. Инкрементальная копия может весить меньше чем у Bacul'ы, но это добавляет требований к доступности вчерашних резервных копий.

Такс, я может тоже всячески погорячился. :) Но я не со зла, конечно. :)

Во-первых скажу, что я сам ухожу конечно от rdiff-backup, и буду пользоваться baculа, а значит я понимаю, все её достоинства. Тут спора нету, конечно. :)

Не требуется. В случае с Bacul'ой прошлая версия файла может лежать где-то на отключенном томе в сейфе в бункере за 300 километров, нужна только её контрольная сумма в базе Director'а.

Я имел ввиду, что потребуется, в случае восстановления, конечно. Спасибо за уточнение, про контрольную сумму в director. Я не задумывался об том, как оно там хранится.

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

Попросит, конечно, но только вчерашний день. Но там будет мало данных. Но в целом, да попросит.

Что это за бред вы сейчас написали? 2 копии в Bacul'е весят как 2 копии, но никак не 3

Такс... Представим ситуацию: пусть bacula записывает в один том весь job. Пишем в том А... Записали. Пишем в том Б - записали... - Вот уже имеется всего две копии. На следующий раз: пишем снова в том А - мы ведь по кругу ходим? Всё верно? Мы ведь следуем Вашей логике, что (2 копии в Bacul'е весят как 2 копии). И тут у нас случился обрыв нашего задания (не важно, сеть там отвалилась или чего-то ещё приключилось), мы имеем то, что: том А уже вычищен из каталога, том А уже имеет часть данных перезаписанными. - И таким образом, у нас осталась всего одна резервная копия, в томе Б. Как-то так. Скажем так: шанс то, что оборвётся job длинною в 2тб, весьма велик. По сему (везде пишут), и я с этим согласен: что надо всё же иметь три тома. А, Б, В - если нам надо гарантированно иметь две копии наших данных.

У меня на позапрошлой работе была именно такая ситуация, и я не обосрался. Я по субботам делал Full, по ночам будних дней Incremental

Так минус такого подхода в том, что каждую неделю бессмысленный напряг клиента, и передача по сети одного и того же трафика, очень большого объёма. Какой в этом смысл? Если только фирма не настолько богата, что может себе позволить каждую неделю иметь новые носители для томов.

Что такое VirtualFullBackup?

http://www.bacula.org/7.0.x-manuals/en/main/New_Features_in_7_0_0.html#SECTIO... как-то так. Это чтобы не делать вот такого:

Я по субботам делал Full

Ещё раз, полная копия данных весит как полная копия данных независимо от того используется ли Bacula, tar или rdiff-backup. Магии не существует. Инкрементальная копия может весить меньше чем у Bacul'ы, но это добавляет требований к доступности вчерашних резервных копий.

Всё так, если делать backup qcow2 образов, то у bacula вообще не будет никакой разницы, между Full и Incremental, а вот это уже не очень хорошо.

Всё это нормально сохранялось на двухтерабайтные НЖМД, которые я старался менять по кругу, но часть начальник увозил к себе домой и забывал вовремя привезти обратно, так что порядок замены нарушался, но это не вызывало сбоев.

Да я не вижу смысла заниматься тем, что куда-то, чего-то увозить в какие-то сейфы... А вообще, может покритикуете мой паттерн:

Я для хранения томов впиливаю:

md1 + md1 + md1, поверх этого: lvm. И гоняю по кругу vol. Таким образом, я получаю один, большой раздел, и мне не страшен отказ одного диска, и при случае даже двух дисков (если откажут, в разных md). Вроде всё годно, в целом. Мне очень хотелось бы тупо хранить разные job, на разных дисках, но мне кажется, что есть опасность того, что я могу не подняться с какого-то из job, если у меня случится отказ одного из НЖМД. По сему, приходится выплачивать n2, от полезного объёма хранилища.

Короткая песня о главном

Так, прежде чем разобрать ваш длинный ответ отмечу важные достоинства и недостатки Bacul'ы и BareOS'а о которых часто забывают или не акцентируют на них внимание.

Важное достоинство номер раз: нормальная поддержка отключенных копий, то есть off-line backup. Можно сделать резервную копию данных и положить в архив на вечное хранение или отвезти в другой город и положить в сейф. И никакая порча данных, ошибки в ПО, злонамеренный или безграмотный админ не могут этот повредить эту копию данных, раз уж она создана, отключена от всего и увезена в безопасное хранилище. В одной конторе где я работал не то чтобы прорабатывался, но брался в рассчёт следующий сценарий: контору «заказали» конкуренты или просто кому-то нехватает денег на учёбу сына в Оксфорде, в офис приходят оборотни в погонах, для проведения экспертизы изымают всю вычислительную технику. А сроки-то по контрактам поджимают. Контора имеет строительный профиль. Сегодня не начнёшь рыть котлован, завтра не зальёшь бетон, просрёшь день города, останешься без денег, да ещё и мэр и губернатор будут иметь на тебя зуб. В этом случае директор продаёт свой Lexus хачам на Южнопортовом рынке, покупает в ближайшем магазине любые готовые компы, заливаем на них данные из копии которая была у директора дома (в Подмосковье). Вуаля. Финансовые потери велики, репутационных потерь нет.

Важное достоинство номер два: возможность делать резервные копии файлов и папок превышающих размер НЖМД или лент. rsync и всё что на нём основано так не может. Никаким образом нельзя трёхтерабайтную директорию или файл rsync'нуть на двухтерабайтные НЖМД, а вот Bacul'ой сохранить можно.

Важный недостаток номер раз: Bacula работает с файлами. Если у нас есть, например, MySQL'ная база, и в одной из таблиц, в одной из строк мы заменим «Фому» на «Ерёму», то получим mysqldump с другой контрольной суммой и Bacula будет сохранять его целиком, а не только diff. Да и вообще, сама необходимость сначала сделать mysqldump в файл, а потом сохранять этот файл меня всегда бесила. Где работа с pipe'ами, где unix way?

Несущественный недостаток: Bacula не слишком хорошо шифрует резервные копии. Содержимое файлов скрыто, а вот размер и название известны. Но это можно обойти. Я сохранял нешифрованые Volumes на разделы с LUKS'ом.

Так, прежде чем разобрать ваш длинный ответ

Я тогда пока не буду отвечать. Буду ждать, ответа полного, чтобы не загромождать тред. Спасибо!

Хотя один вопрос, всё же задам: а вообще bacula/bareos сейчас хоть кто-то использует? Или я одинок?

Я bareos использую. 2ТБ довольно медленно бэкапит и иногда возникают проблемы со свободным местом. Но оно работает, работает хорошо и относительно удобно.

Где работа с pipe'ами, где unix way?

bpipe

bpipe!

Где работа с pipe'ами, где unix way?

bpipe

Это очень very good! Когда я был моложе и админил Bacul'у никакого bpipe'а ещё не было.

Резервное восстановление

2ТБ довольно медленно бэкапит и иногда возникают проблемы со свободным местом.

А восстанавливаться из вашей резервной копии на 2 Tb вы уже пробовали? Восстанавливает Bacula ещё медленнее.

Ответ

Попросит, конечно, но только вчерашний день. Но там будет мало данных. Но в целом, да попросит.

Поясните, что значит «попросит, но там будет мало данных»? То есть попросит, то толку от этого 0, потому что в резервной копии от вчерашнего дня недостаточно данных? И таки странно было бы, если бы во вторник rdiff-backup попросил бы копию за какие-то ещё дни, мы же в понедельник сделали Full. Кстати, а что попросит rdiff-backup в четверг, если в понедельник мы сделали Full, а во вторник и среду Incremental?

По сему (везде пишут), и я с этим согласен: что надо всё же иметь три тома. А, Б, В - если нам надо гарантированно иметь две копии наших данных.

Ну да. До тех пор пока Job не завершится у вас нет резервной копии. Поэтому если нужно иметь не менее двух резервных копий, то для этого понадобится 3 тома: на двух лежат резервные копии, третий рабочий. rdiff-backup как-то может обойти это ограничение? Можно на 2 НЖМД иметь корректные полные резервные копии и при этом ещё и писать на один из них третью, и старая резервная копия затрётся только в тот момент когда rdiff-backup допишет новую? Или rdiff-backup не тронет одну резервную копию, а другу будет трансормировать из состояния «такими данные были позавчера» в «такие данные сейчас» через «такими данные не были никогда»?

Так минус такого подхода в том, что каждую неделю бессмысленный напряг клиента, и передача по сети одного и того же трафика, очень большого объёма. Какой в этом смысл?

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

Если только фирма не настолько богата, что может себе позволить каждую неделю иметь новые носители для томов.

Это может позволить себе любая фирма которая реально работает, а значит её данные хоть чего-то стоят. Но на практике у меня в этом не было необходимости. У меня было, кажися, штук 7 двухтерабайтников, один рабочий, 1 у директора, 5 у меня на полке лежат. Крутились по кругу.

Всё так, если делать backup qcow2 образов, то у bacula вообще не будет никакой разницы, между Full и Incremental, а вот это уже не очень хорошо.

Не могу не согласится. Но это не самое страшное «не хорошо» из тех что встречаются на свете. В моём опыте, кстати, это вообще было не важно. Файлоотстойник весил примерно терабайт, а мускульная база всего лишь 50 мегабайтов. Если же надо хранить, как в вашем случае, образы виртуальных машин, то нужно присматриваться к более другим средствам резервного копирования нежели BareOS и Bacula.

Да я не вижу смысла заниматься тем, что куда-то, чего-то увозить в какие-то сейфы...

Всё зависит от того какие сценарии вы прорабатываете и от каких неприятностей хотите защититься. По моему мнению 1 копия вдалеке от всех остальных совершенно необходима. Помните как Gentoo Wiki упали, да так и не смогли поднятся, при том что у них сервер и все НЖМД в нём были совершенно исправны. А дело было в чём, весь ЦОД отключили и опечатали за долги хостера.

Я для хранения томов впиливаю: md1 + md1 + md1, поверх этого: lvm.

You're doing it wrong. Если у вас есть сервер система хранения которого выдерживает все тома разом, то тут лучше воспользоваться не Bacul'ой, а чем-то на основе rsync'а или чем-то ещё. Bacula нужна когда все резервные копии не влезают в диски одного сервера, когда их записывают на отдельные тома, которые подключают по очереди, по мере необходимости. Вам нужно разделить архивирование (медленное, но надёжное) и резервное копирование (менее надёжное в плане длительного хранения, но за то очень быстрое при восстановлении). Для резервного копирования надо выбрать что-то такое, что не создаёт лишнюю нагрузу для перепаковывания файлов в формат Volume, но копирует файлы и папки файлами и папками, и хранит это дело в виде файлов и папок, чтобы при восстановлении достаточно было просто скопировать, а не возится с распаковкой Volume. При необходимости можно с резервной копии делать архивную, например раз в неделю или месяц. Если на сервер можно сложить 3 полных резевных копии, то пусть на нём и лежат 3 полных резервных копии (ну или 2 полных и какое-то количество свежих инкрементальных), а ещё где-то на полке или в сейфе пусть лежат отключенные архивные копии, которые никакой хэккер не сможет повредить, потому что они ни к чему не подключены, в отличие от резервных копий.

Из платных --- TSM http://en.wikipedia.org/wiki/IBM_Tivoli_Storage_Manager

Полностью нет, только частично.

Я открыл для себя gzip сжатие. Плохо, что жмёт оно исключительно на стороне fd, однако, мою выгрузку из СУБД, со 147гб. до 33гб. спокойно пожало. Не быстро, но в целом, для меня, то, что надо. Спасибо. А то я уж, думаю, может я один такой изувер, и никто уже не пользуется bacula

Я открыл для себя gzip сжатие

Файлопомойка плохо жмется :(

Благодарю за ответ.

Позволю и себе прокомментировать, ответить:

Поясните, что значит «попросит, но там будет мало данных»? То есть попросит, то толку от этого 0, потому что в резервной копии от вчерашнего дня недостаточно данных? И таки странно было бы, если бы во вторник rdiff-backup попросил бы копию за какие-то ещё дни, мы же в понедельник сделали Full. Кстати, а что попросит rdiff-backup в четверг, если в понедельник мы сделали Full, а во вторник и среду Incremental?

Всё просто. rdiff-backup, всегда, последнюю копию держит as is, т.е. в файлах, чего получил - то и положил. Т.е. ничего для восстановления из последней успешной копии не требуется. diff на уровне файлов сжимается, и gzip'уется. Это называется обратное дифернцирование, или как-то так. Не помню точно. - Т.е.: если надо восстановиться с последней копии - просто выполняем копирование файлов обратно. Если надо с предпоследней: rdiff на голые файлы наложит вчерашний diff, если из пред-предпоследней: rdiff на голые файлы наложит вчерашний diff а затем позавчерашний. - То есть чем глубже надо вынуть backup, тем дольше ждать. Но в целом, всё работает весьма шустро и ведёт подробные логи.

Если же надо хранить, как в вашем случае, образы виртуальных машин, то нужно присматриваться к более другим средствам резервного копирования нежели BareOS и Bacula.

Мой сценарий использования bacula - это архивное хранение, прежде всего. Т.е. сами qcow образы, я копирую при помощи zfs на удалённый хост, и по необходимости, складываю в bacula (не могу полностью доверять zfs, да и вообще...). Я пока только начал всё это делать, не могу дать отчёта, насколько я был прав или не прав, при выборе своего решения. Так вот, по-крайней мере linux qcow2, оно мне пожало... С 250 гб. до 88ми. Что весьма радует. Так, что пока я доволен. Я взял ansible, раскидал bacula-fd, быстренько написал необходимые конфиг файлы для bacula, запустил всё это добро через bat, и получил результат. :)

У меня было, кажися, штук 7 двухтерабайтников, один рабочий, 1 у директора, 5 у меня на полке лежат. Крутились по кругу.

Ок. Понял. Наверно в моём случае не стоит тыкать диски туда-сюда. Так-как сценария маски-шоу, моё Руководство не рассматривает.

Всё зависит от того какие сценарии вы прорабатываете и от каких неприятностей хотите защититься.

Архивный сценарий. Т.е.: когда основные backup будут испорчены. Но и частично как основное backup решение, для физ. узлов - например, резервное копирование шлюза, и т.п..

Теперь немного вот об чём:

а ещё где-то на полке или в сейфе пусть лежат отключенные архивные копии, которые никакой хэккер не сможет повредить

Тут скрывается нюанс. Помимо самих томов, необходимо держать ещё как минимум файлы дампов от выполненных Job, а лучше и вовсе иметь весь каталог, чтобы без проблемно, и быстро восстановиться. Тоже в общем, надо всё это дело учесть...

А то я уж, думаю, может я один такой изувер, и никто уже не пользуется bacula

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

Файлопомойка плохо жмется :(

В целом, согласен. Но кучи xls, doc - пожмутся я думаю, что прекрасно.

Причем только в этом году настраивал первый раз.

Да я собственно вот и сам такой же...

RTFM

Тут скрывается нюанс. Помимо самих томов, необходимо держать ещё как минимум файлы дампов от выполненных Job, а лучше и вовсе иметь весь каталог, чтобы без проблемно, и быстро восстановиться. Тоже в общем, надо всё это дело учесть...

В руководстве к Bacul'е этот нюанс уже описан. Рекомендуют делать отдельный Job для БД Director'а, чтобы в случае серьёзного ЧП сначала восстановить БД Directora (что должно быть не слишком долго, БД не велика), а потом с ним восстановить всё остальное. Но даже если этого не сделано, то есть утилитка, которая из Volume'ов вытягивает информацию об их содержимом и может сложить её в БД Director'а. Но это довольно длительная операция, потому что Volume прочитывается от начала до конца.

rdiff-backup, всегда, последнюю копию держит as is, т.е. в файлах, чего получил - то и положил.

Отлично подойдёт для резервного копирования и быстрого восстановления. Однако всё что я говорил до этого об объёмах резервных копий остаётся верным. Если у нас 400 Гб данных, то две полных копии будут весить 800 Гб, а для того чтобы делать при этом ещё копию не повредив одну из имеющихся понадобится ещё 400 Гб.

Несжимаемость

Но кучи xls, doc - пожмутся я думаю, что прекрасно.

А они уже не пожаты?

Все пользуются Bacul'ой

А то я уж, думаю, может я один такой изувер, и никто уже не пользуется bacula

Отнюдь-отнюдь. Bacula/BareOS очень популярны. Причины я описывал выше, прежде всего это возможность правильно сделать архивирование. Тут Bacula вне конкуренции среди свободных программ. А резервное копирование, да, можно и на чём-то другом делать.

В руководстве к Bacul'е этот нюанс уже описан. Рекомендуют делать отдельный Job для БД Director'а

Bareos, уже идёт с таким преднастроенным job. Я пока его убрал, до полного понимания, как он работает. Суть я понимаю, конечно, теперь надо понять как из него восстанавливаться, и в каком виде он складывает себя. - Если он себя складывает в volume, то наверно, смысла в этом не много. В общем разберусь, надеюсь. Спасибо. Если чего, я позову Вас в тред. :)

Но даже если этого не сделано, то есть утилитка, которая из Volume'ов вытягивает информацию об их содержимом и может сложить её в БД Director'а. Но это довольно длительная операция, потому что Volume прочитывается от начала до конца.

Огромное спасибо! Буду знать.

Отлично подойдёт для резервного копирования и быстрого восстановления. Однако всё что я говорил до этого об объёмах резервных копий остаётся верным. Если у нас 400 Гб данных, то две полных копии будут весить 800 Гб, а для того чтобы делать при этом ещё копию не повредив одну из имеющихся понадобится ещё 400 Гб.

Да, всё верно! Можно довольно легко получить не консистент с rdiff-backup. От этого можно спастись, если перед запуском rdiff-backup, создавать снепшот каталога, в который он хочет писать. Но всё это мне уже показалось слишком громоздким, и я выбрал bareos.

Кстати, вопрос такой: я читал вроде в документации, что неудавшийся job, будет перезапущен, через какое-то время - и там можно задавать это время (если не устраивает настройка по-умолчанию), а так же задавать период, в течении которого bacula будет вообще пытаться этим заниматься. - В общем вопрос такой: если во время выполнения job, случится network disconnect, и job перейдёт в режим: Canceled - bacula будет его сама перезапускать?

Спасибо.

А они уже не пожаты?

Кхм... Вообще, вполне себе может быть. В общем, попробую, расскажу, как оно с gzip.

Отнюдь-отнюдь. Bacula/BareOS очень популярны.

Спасибо. Это весьма радует. Я вот хочу даже попробовать bareos mssql плагин... Боюсь конечно, но вообще говоря - довольно интересно.

теперь надо понять как из него восстанавливаться, и в каком виде он складывает себя. - Если он себя складывает в volume, то наверно, смысла в этом не много

Логический бэкап БД (в SQL формате). И складывается он в Volume :)

У Job есть настройка Write Bootstrap = "|/usr/local/bin/bareos-write-catalog-bootstrap". Можешь указать свой скрипт, который например будет по SSH заливать файл в другое надежное место (по pipe).

Для восстановления рабочий Director не обязателен. Через bextract можно просто вытащить файлы из любого volume. Можно и без bootstrap-файла, но тогда bextract вытащит все файлы без разбора где какая job.

Про Bootstrap, знаю, у меня так настроено:

Write Bootstrap = «/var/lib/bareos/%c.bsr» , но пока глубже не трогал, как оно. Спасибо всяческое, буду ковырять неспешно. Пока есть у меня ещё вопросы, нюансы, в частности по скорости приёма заливки файла в sd. Тестирую, если будут конкретные вопросы - я постучусь. :) Ок? :)

Write Bootstrap = «/var/lib/bareos/%c.bsr»

Эти файлики должны забэкапиться при бэкапе каталога (либо еще как-то нужно копировать файлы в другое место). Пригодятся, если понадобится восстановить файлы из volume без директора. При бэкапе каталога записывать bootstrap в файл на том же сервере нет смысла, он нужен для восстановления директора в случае потери бэкапного сервера.

Ок? :)

Ок. Если что я на тред подписан.