Pull to refresh

Comments 51

Много слышал про Bacula, но всю статью не осилил не спавши почти сутки и много конфигов :), чисто по диагонали. Пугает количество демонов и постоянные «устройства», «томы» и «raid»в тексте. Можно ли их (демонов) разместить на двух хостах (сервер и рабочий, причем рабочий за натом без возможности прокинуть порты) баз отдельных разделов, винтов и т. п.? Грубо говоря на сервере (два раздела, ext4 / и swap) что-то крутится, а клиент обращается, запускает скрипты на сервере и пишет куда-нибудь в home (разделов много, хард один, в принципе не проблема создать отдельный раздел со вложенными extended, но не хочется)? Или Bacula для такого простого случая будет стрельбой из пушки по воробьям и достаточно использовать ssh, scp/rsync?
Думаю, что в данном случае действительно «как из пушки».
Если серверов-клиентов 5-7 и в перспективе постоянный прирост, то следует взяться за bacula/.
Хехе… У меня Bacula DD и SD + Catalog установлены на моем самом обычном домашнем десктопе (Ubuntu) и бэкапят они 2 виртуалки на хостинге. В качестве GUI использую только Bat — интерфейс средней паршивости, но все задачи прекрасно можно выполнять из него, не изучая консольные команды.
Ни капли не жалею что потратил вечер на настройку — все работает как часы, пару раз даже пользовался восстановлением из бэкапа
Bacula создавалась для работы со стримерами и потому там все так замутно с устройствами/томами/etc. И именно из-за этого Bacula очень любит использовать тома повторно. Когда я поднимал bacula с хранилищем на дисках, пришлось написать специальный сервисный скрипт (Job с Type=Admin), который перед backup job'ами пробегает по всем томам, удаляя устаревшие задачи, после чего удаляет все пустые тома из базы и с диска.
Спасибо за статью! Давно хотел познакомиться с Bacul'ой поближе, да все как-то руки не доходили, а тут — такой материал :)
Жаль вы не остановились на параллельном снятии бекапов с разных серверов (т.е. одновременно лить более одного бекапа). Так и не удалось понять, возможно ли это, если бекапы с разных серверов пишутся в разные Device, Но эти самые Device смотрят на один физический раздел.

У меня все задания встают в очередь. С дифами это не страшно, а вот полные воскресные бекапы заканчиваются только к 12:00.
Увы, но в подобном функционале мы, возможно пока, не нуждаемся.
Если у вас такая хрень с полными бекапами — почитайте про дедупликацию данных. Бакула умеет её на уровне ФС, что в принципе тоже неплохо (более тяжёлые решения умеют чуть-ли не на уровне кластеров). Вкратце — вы создаёте один, основной, бекап, который принимается за базовый. Далее, в задании для полного бекапа ссылаетесь на него, и те файлы, которые в базовом и полном совпадают, бекапиться не будут. Это похоже на дифференциальный бекап, с той разницей, что базовое задание может быть общим для разных бекапов — например, если делать бекап не данных, а целого сервака, то файлы ОС часто идентичны, что и даёт возможность сэкономить.
Но и для бекапа данных, который, я так подозреваю, у вас и происходит — базовый бекап позволит немножко снять нагрузку. Я делаю так: раз в два месяца делается базовый бекап, каждые выходные — полный, каждый день — инкрементал или диффы, в зависимости от ресурса.
Это интересно. Спасибо.
А зачем каждые два месяца полный бекап? «На всякий случай» или это необходимо?
Время восстановления и размер хранимых данных вестимо
Ко времени восстановления я также добавляю параметр надёжности. Это в теории инкременталы и диффы такие замечательные — на практике быстрее и надёжнее восстанавливается из огромного, но простого полного бекапа.
Очень просто — раз в два месяца базовый, это для одного из ресурсов (для других политики и сроки другие), потому что примерно за два месяца набегает довольно много изменений в данных этого ресурса, что приводит к неэффективности дедупликации, так как полные бекапы пишут всё, что отлично от базового. В числах: на ресурсе лежат 500 Gb данных, после создания базового размер первого полного — 15-20 Gb, через месяц — 50-80 Gb, через два — до двухсот доходит, поэтому разумнее снова сделать базовый, разгрузить полные и уменьшить таким образом окно резервного копирования, чтобы успело всё сделать за выходные.
Параметр «Maximum Concurrent Jobs» позволяет контролировать кол-во параллельных бэкапов, точнее сколько одновременно запущенных заданий может выполняться. Но стоит иметь ввиду. что могут быть проблемы, если два запущенных задания будут писать на один и тот же том.

Хотя все же лучше сделать как говорит Shajtan.
Отличная статья! Давно нуждаюсь в этом! ;)
Можно попросить: Если вы работали с ZFS и LVM напишите пожалуйста о них.

Недавно поднял на домашнем ZFS pool на базе MBR разметки и решил забэкапиться. Мне нужно знать где находятся метки и можно ли их бэкапить? Вот примерно то что я хочу избежать:Восстановление ZFS-пула с помощью подручных средств. Также начал рыть по теме LVM и тоже не нашел хоть сколь нибудь развернутого ответа. ;)
Про LVM на русском языке читайте здесь — xgu.ru/wiki/LVM
лучшего источника на русском языке я не знаю.
Что же касается ZFS, для разметки я бы все таки использовал GPT, а документация по ZFS есть на сайте оракла.
Ок, скажу по другому.
К примеру по каким-то причинам у вас пул устройств полетел и вывод #zpool import показывает пул с CORRUPTED. Что делать? Запуск #zpool status вообще устройство не выводит, как будто его и не существовало! Импортировать с Fixit не получается. Что делать? Какие конкретно шаги должны быть сделаны? И самое главное, что нужно было сделать чтобы эти шаги были минимальными?

>>а документация по ZFS есть на сайте оракла.
которая раскрывает теорию, а не практику! Практику восстановления смотрите ту статью ссылку на которую я привел выше. Загляните, не поленитесь! Вы поймете о чем я и также поймете что чтение мануалов тут не сразу поможет, тут нужно точное понимание где расположены «zfs vdev labels» и как их бэкапить.

>>для разметки я бы все таки использовал GPT
Для FreeBSd 10-тки, когда реализуют «EFI booting» обязательно перейдем на GPT.
Простите, но ваши вопросы ни как не корелируют с описанным в статье.
Я не могу вам помочь в рамках комментариев к статье.
Что вы делали такого, чтобы ушатать ZFS?
А почему вопрос ко мне?
Я ZFS не шатал =)
Так вопрос и не к вам =)
Что делал? Просто тестил некоторый продукт на разных ситуациях )
а как ты создаешь во FreeBSD разделы больше 2 ТБ?
К разметке диска это не имеет никакого отношения.
zfs export mytank
zfs import mytank -f
всё

Причина такого поведения здесь.
Как говорится, пользуясь случаем, предлагаю тем, у кого есть linux-сервер с исходниками и бд, которые бы он хотел забэкапить. Можно воспользоваться моей статьёй — в ней нет описания что для чего означает каждая строчка в конфиге, но конфиг рабочий.
Хм… в таком случае у меня вопрос.
Конфигурационные файлы приведенные мною не работают? Укажите в каком месте пожалуйста.
Нет, я для тех людей, у кого есть веб-сервера и не хотели бы особо морочиться с настройками бакулы. Я, например, такую статью искал: чтобы скопировать, поправить пару моментов и пользоваться. Но таковую не нашёл. И чтобы сохранить время другим людям, похожим на меня. =)
Ваши конфиги я не проверял, думаю, что они рабочие.
@/usr/local/etc/bacula/client.conf
@/usr/local/etc/bacula/job.conf
@/usr/local/etc/bacula/pool.conf
@/usr/local/etc/bacula/fileset.conf

Конфиги можно разделить на разные файлы,
Options { signature = MD5 compression = GZIP }
и включить компрессию.
Еще у меня почему-то при попытке посмотреть в клиенте(bat,win7), в пункте bRestroe при выборе job`a вылетает пустое окно с заголовком «error». Встречались?
Спасибо за совет.
Нет не встречался, bat у меня только на Ubuntu и на Gentoo, там таких ошибок небыло.
Согласен с вами. Очень удобная фича :)
У меня один файл = одно задание. В bacula-dir.conf прописаны ресурсы Director, Catalog, Console, JobDefs, Job (задание для восстановления), Messages, т.к. они почти всегда одинаковы для всех заданий (у меня один директор и демон хранения). А в файлах все остальное (Client, FileSet, Job, Pool, Schedule, Storage).
Еще встретил очень интересный способ инклудить:
@|"sh -c 'for f in /etc/bacula/clientdefs/*.conf ; do echo @${f} ; done'"
Да, в документации где-то такое встречается. Использую с каталогом jobs-enabled, в котором лежат симлинки на jobs-available, по аналогии с конфигом апача. А bat у меня тоже колбасит, возможно из-за несоответствия версий директора и самого бата.
bat под винду вообще мегаглючная штука. У меня регулярно вылетал при попытке построить дерево каталогов для восстановления. Давал его только с третьего-четвёртого раза, и только если после выпадания с ошибкой ткнуть в закладку консоли и просмотреть все-все сообщения об ошибках. Мистика… даже непонятно, что именно в багтрекер писать. Иногда повторялось, иногда работало идеально.
Тоже использую бакулу, почти год. Очень доволен. Особенно впечатляет гибкость конфигурации.
По началу было немного сложновато с ней разобраться, а когда разобрался так стал удивляться: «А чего сложного-то?» :)

> # fqdn имя сервера
> Address = backupsrv.domain.ru

Не обязательно… Можно указать IP адрес. Это справедливо для всех полей «Address =» во всех конфигах.

Так же хотел бы заметить, что для бакулы нет разницы в пробелах и регистре в названии ресурсов и параметров. Например: «Media Type», «MediaType» и «mediatype» для бакулы одно и то же.
Согласен, но я использую доменное имя, поэтому примечание справедливо.
Пароли и имена ресурсов(такие как backupsrv.domain.ru-dir и т.д.), все таки, должны совпадать во всех конфигурационных файлах.
Заметку про «Address = » сделал, т.к. у не знающего может сложиться впечатление, что в том случае нужно только имя, а в других только ip ;)

Про второе не совсем понял к чему вы… Пароли и т.п. это ведь значения параметров и они конечно же должны совпадать. А вот названия параметров не важно как записано («Media Type», «MediaType» и «mediatype»). У меня, например, в одних конфигах «FD Port» (конфиг директора), а в других «fdport» (конфиг агента) и даже такое встречается (конфиг другого агента)
FDAddresses = {
ip = { addr = 10.3.1.3; port = 9102; }
}

и все работает отлично :)

// Просто конфиги, которые на сервере директора, я копировал из документации и правил под себя. А те что на клиентах уже писал сам.
Буду иметь ввиду, спасибо за информацию =)
А я столкнулся с тем, что наш HP Ultrium 9хх напроч не видится ядром линукса, а модули для ядра есть под старючие дистрибутивы :(
Пришлось писать скрипт на повершелле под ntbackup на 2003 файлсервере, где он из коробки :(
«Where: /usr/restore» — здесь можно уточнить, что процесс восстановления создает файлы относительно корня. То есть, если мы ресторим в /usr/restore забэкапленую ранее /etc/some/dir, то на выходе получим /usr/restore/etc/some/dir.
Иногда удобно, дабы руками аккуратно разгрести данные. Если такой необходимости нет, то можно указать «where: /»
И да, как уже сказано выше, конфиги, дабы было супер-кошерно-2.0 и красиво, лучше инклудить с помощью "@".

Сам месяц назад тоже столкнулся с необходимостью развернуть бакулу. В целом все понятно, но пулы с томами и метками по началу вводят в ступор. :)
я бы в jobs рекомендовал использовать Accurate = yes. Это включает режим, при котором в инкрементальных бэкапах производится корректный учет удаленных и переименованных файлов. Режим жрёт на сервере больше памяти и проца, но зато если вы удалили файл 1го декабря и восстановили бекап на 2е, то у вас удаленного файла в restore таки не будет.

лично мне bat показался очень глючным. Использую webacula.sourceforge.net — просто устанавливается, функционально и красиво.

ps: недавно bacula обновилась с версии 5. 0.3 (которую использует автор статьи) до 5.2.3. обещают справление многих багов и увеличение стабильности. подробности на www.bacula.org/en/?page=news
«Accurate = yes» штука хорошая и полезная. Но и вреда от нее хватает: если в винде включена индексация, то после того как винда проиндексирует файлы, большинство из них попадет в инкрементальные бэкап, т.о. инк. бэкап может весить как полный. Я с этим столкнулся когда разбирался, почему некоторые инк. бэкапы очень нужной программы весят почти как полные. Когда отключил индексацию в винде, то стало все нормально, но в программе перестал работать поиск. Пришлось включить индексацию и поставить «Accurate = no». И это при том, что в «FileSet» у меня «BaseJob», «Accurate» и «verify» выставлены в «s5» (size + md5).
Не кажется ли Вам, что в винде стоит использовать встроенный и штатный инструментарий, а не городить огород? у нас винда бекапится в файлик, файлики с бекапами уезжают на резервном файлсервере на ленточку.
Эм… ~400 гигов данных у этой программы и объем постоянно увеличивается, полный бэкап занимает 10-15 часов.
Если для вас это огород, то для чего тогда агент бакулы для винды существует?
Виндовым ntbackup'ом я бэкаплю состояние системы (реестр и т.п.), а полученный файл забираю бакулой. Но не 400 гигов же бэкапить виндовым бэкапером…
эм. в два раза больше данных ~800гб в полном бекапе у нас в компании уезжает в бекап с пятницы вечера до когда придется. daily бекап около 30 гигабайт улетает за час.
но у нас идет реорганизация сетевого диска, т.к. там валяются документа надцатилетней давности, которые не нужны, и настройка квот, так что скоро это будет раза в два меньше

400 гигов, полный бэкап занимает 10-15 часов.

Это на каком оборудовании ?

Прочитал свой коммент про эти 400 гигов и 10-15 часов и сижу ах...ю... Да как так то... Блин, я в шоке каком-то сейчас. Это же 7-10 мб/с... Похоже это было тогда, когда на дисковых массивах было отключено кэширование записи, ibm ds 35хх тогда были, если не изменяет память, либо ibm storwize какие-то.
За 10 лет и железо и сетевое оборудование поменялось не раз, поэтому точно уже причину не вспомню. Да и вообще сейчас читаю и мысль в голове: "Да, б..ть, как я могу такую х...ню сморозить".

Ох... Dmitry, спасибо за ваш вопрос. И поржал и ах...л с себя 10-летней давности :-D

Много времени назад (на черновиках хабра нет даты) взялся писать статью, но подробно описав весь пантеон демонов, и добавив в текст минимально требуемый текст конфигов с англоязычными комментариями, понял, что описать поднятие какой-либо конфигурации и задокументировать все файлы конфигурации у меня сил не хватит.
Очень рад, что у кого-то всё-таки хватило мужества написать такую статью. Отличная работа, FessAectan! Если ситуация за последнее время не поменялась, а статья так хороша, как мне кажется — это самая лучшая статья по теме на русском языке.
Only those users with full accounts are able to leave comments. Log in, please.