Комментарии 46
Благослови тя Господь, добрый человек.
А кто ни будь использовал эту систему для создания/восстановления резервных копий машин под windows? Интересны отзывы
Для бакулы есть отличный веб-интерфейс bacula-web.
Скриншот с сайта в адском качестве
Скриншот с сайта в адском качестве
кстати, у меня так и не получилось прикрутить этот веб-интерфейс, все зависимости соблюдены, тест какой-то встроенный в него показывает «ОК», но в итоге не работает, засранец такой. Может у кого есть положительный опыт прикручивания веб-морды к Бакула?
Да уж, надо было действительно поискать такой скрин.
Вот все на странице официально, свежие, с хорошим качеством.
www.bacula.org/en/?page=screenshot
Вот все на странице официально, свежие, с хорошим качеством.
www.bacula.org/en/?page=screenshot
Самый вменяемый вэб интерфейс к бакуле — Webacula. Юзаю уже пару лет её.
Статья рассказывает про очень интересный продукт, который хочется попробовать.
Единственное, замечание — сложно понять на какой системе и в каком файле нужно прописывать те или иные опции, а так же — какой кусок кода к чему относиться. Было бы хорошо добавить перед кодом путь к файлу. Спасибо )
А так — плюс!
Единственное, замечание — сложно понять на какой системе и в каком файле нужно прописывать те или иные опции, а так же — какой кусок кода к чему относиться. Было бы хорошо добавить перед кодом путь к файлу. Спасибо )
А так — плюс!
Хорошая статья. Особенно если учесть что рунете про нее довольно мало.
Как раз недавно с ней разбирался.
Из недостатков bacula стоит отметить недостаточно гибкий шедулер, а также некоторая недоработанность по части работы с винчестерами. Видно что система в основном под ленту делалась. Еще мне не очень понравилась скорость на множестве мелких файлов, но возможно я сам чего то не то сделал, хочу заняться оптимизацией.
К bacula кстати есть неплохой веб интерфейс Webacula webacula.sourceforge.net/index_ru.html
Как раз недавно с ней разбирался.
Из недостатков bacula стоит отметить недостаточно гибкий шедулер, а также некоторая недоработанность по части работы с винчестерами. Видно что система в основном под ленту делалась. Еще мне не очень понравилась скорость на множестве мелких файлов, но возможно я сам чего то не то сделал, хочу заняться оптимизацией.
К bacula кстати есть неплохой веб интерфейс Webacula webacula.sourceforge.net/index_ru.html
Меня шедулер полностью устроил, хотя на вкус и цвет все фломастеры разные.
Вместо веб интерфейса пользуюсь bacula-console-qt, очень удобно, особенно восстанавливать файлы.
Вместо веб интерфейса пользуюсь bacula-console-qt, очень удобно, особенно восстанавливать файлы.
bacula-console-qt тоже пользуюсь.
А с шедулерем там все хорошо если не закорачиваться. К примеру задачу делать бекап через день на разные винчестеры просто на нем сделать нельзя. Пришлось писать вот так с некоторой избыточностью.
Schedule {
Name= «WeeklyCycle-every-first»
Run = Full 1st sat at 1:00
Run = Incremental mon at 1:00
Run = Incremental wed at 1:00
Run = Incremental fri at 1:00
Run = Differential sat at 1:00
}
Schedule {
Name= «WeeklyCycle-every-second»
Run = Full 3rd sun at 2:00
Run = Incremental tue at 2:00
Run = Incremental thu at 2:00
Run = Incremental sat at 2:00
Run = Differential sun at 2:00
}
А с шедулерем там все хорошо если не закорачиваться. К примеру задачу делать бекап через день на разные винчестеры просто на нем сделать нельзя. Пришлось писать вот так с некоторой избыточностью.
Schedule {
Name= «WeeklyCycle-every-first»
Run = Full 1st sat at 1:00
Run = Incremental mon at 1:00
Run = Incremental wed at 1:00
Run = Incremental fri at 1:00
Run = Differential sat at 1:00
}
Schedule {
Name= «WeeklyCycle-every-second»
Run = Full 3rd sun at 2:00
Run = Incremental tue at 2:00
Run = Incremental thu at 2:00
Run = Incremental sat at 2:00
Run = Differential sun at 2:00
}
Следующий вопрос возник, можно ли с помощью bacula снимать образы дисков.
А системного? А с рабочей машины?
А системного? А с рабочей машины?
Напрямую нет. Можно заставить ее выполнять скрипт и забирать конкретный файл.
НЛО прилетело и опубликовало эту надпись здесь
в документации написано, как это делать
www.bacula.org/5.0.x-manuals/en/main/main/Disaster_Recovery_Using_Bac.html#SECTION003740000000000000000
www.bacula.org/5.0.x-manuals/en/main/main/Disaster_Recovery_Using_Bac.html#SECTION003740000000000000000
Если файловая система умеет делать snapshots — то да, можно. DUMP-ом снимать образ с загрузочного винта нельзя.
Может ли бакапать mysql DB?
В свое время, когда смотрел решения для бэкапа, бакула показалась ну уж слишком сложной и навороченной. В конце концов хватило bksh на сервере бэкапов и скрипта в cron на каждом резервируемом сервере:
tar --exclude=/все/ненужное -cpvf — /все/нужное | bzip2 -9 | ssh -T backups@backupserver `hostname`.tar.bz2 -t60
tar --exclude=/все/ненужное -cpvf — /все/нужное | bzip2 -9 | ssh -T backups@backupserver `hostname`.tar.bz2 -t60
НЛО прилетело и опубликовало эту надпись здесь
Добавил описание.
В данной секции определяем параметры ротации.
Исходя из конфигурации: мы используем 4 тома, в томе храниться не более 7 зданий (недельный бекап), время хранения тома 3 недели (21 день).
Таким образом мы храним каждое задание 21 день, на 22 день очищаем том с данными заданиями и используем его заново.
Так, если мы хотим хранить данные не 3 недели, а 4, то Volume Retention должны быть не 21, а 28 и Maximum Volumes должно быть 5. И не забудьте создать дополнительный том.
В данной секции определяем параметры ротации.
Исходя из конфигурации: мы используем 4 тома, в томе храниться не более 7 зданий (недельный бекап), время хранения тома 3 недели (21 день).
Таким образом мы храним каждое задание 21 день, на 22 день очищаем том с данными заданиями и используем его заново.
Так, если мы хотим хранить данные не 3 недели, а 4, то Volume Retention должны быть не 21, а 28 и Maximum Volumes должно быть 5. И не забудьте создать дополнительный том.
Pool {
Name = mainpool
Pool Type = Backup
Recycle = yes # Может ли бакула удалять задания из томов
AutoPrune = yes # Может ли бакула очищать тома
Volume Retention = 21 days # Как долго бакула должна "бояться" очистить том
Maximum Volume Jobs = 7 # Сколько заданий хранить в каждом из томов
Maximum Volumes = 4 # максимальное количество том которыми может #оперировать бакула
}
Внедряя готовую (или разрабатывая мелкую самописную) систему бакапов необходимо заранее, в спокойной обстановке, написать «восстановление из бакапов step-by-step», выполнить тестовое восстановление, а если всё нормально, то заламинировать и прибить документ гвоздиками на стену.
Надеюсь этот человек не будет против, но самый исчерпывающий мануал по бакуле и многому другому вы найдёте тут: bog.pp.ru/work/bacula.html
Как раз собирался статью писать… Ну ладно. все равно ее напишу. :)
кто-нибудь делал связку bacula — Amazon S3?
Вот когда первый раз увидел статью подумал что слишком сложная.
Когда начал с бакулой разбираться эта статья оказалась самой простой и полезной!
Вообще очень рекомендую эту систему. Мощная, не требовательная к ресурсам
Когда начал с бакулой разбираться эта статья оказалась самой простой и полезной!
Вообще очень рекомендую эту систему. Мощная, не требовательная к ресурсам
Написал статью про Bacula более расширенная и дополненная web интерфейсом.
А как у нее логгированием управлять?
при большом количестве серверов = большом объеме даных для резервного копирования, существенно увеличивается время, необходимое на бэкап.
Я находился в ситуации, когда бэкапы всех серверов LAMP (linux-apache-mysql) выполнялись около 8-ми часов. Из-за большого размера баз данных и вэб контента.
Для решения даной проблемы было решено переводить все сервера на ежедневный диференциальный бэкап. Полные бэкапы делать только в пятницу, субботу и воскресение для отдельных 3-х груп серверов. Как не странно времени это не сильно сэкономило. (~1,5 часа).
Спасло положение сжатие баз данных вызовом отдельного скрипта:
#!/bin/bash
root_pass='mysql_root_password'
databases=`echo «show databases»|mysql -u root -p$root_pass|grep -v "^D" | grep -v «information_schema»`
if [ "$1" == «full» ]; then
echo Starting full backup
for FLS in ${databases}
do
/usr/bin/mysqldump --force --single-transaction --opt -u root -p$root_pass ${FLS} |/bin/bzip2 -c -9 > /var/lib/mysql/backup/${FLS}.full.mysql.bz2
done
fi
if [ "$1" == «clean» ]; then
/bin/rm /var/lib/mysql/backup/*
fi
размещается он на клиент-сервере в папке /etc/bacula/scripts/. Устанавливаются права на выполнение (chmod +x).
Также нужно создать папку куда будут падать сжатые базы: mkdir /var/lib/mysql/backup
На сервере бакулы нужно создать отдельную джобу для бэкапа баз даных, где и указать использование скрипта:
JobDefs {
Name = «DabasesBackupJobName»
Type = Backup
Level = Full
ClientRunBeforeJob = "/etc/bacula/scripts/mysqlbackup_script_name 'full'"
ClientRunAfterJob = "/etc/bacula/scripts/mysqlbackup_script_name 'clean'"
}
На этом этапе пару сотен гигабайт предварительно сжатых и отобраных даных залетают на сервер бакулы на 2-3 часа.
Еще лучше сделать крон задание и запускать этот скрипт в одно и то же время на всех серверах, а дампы забирать вместе с другими файлами. Просто нужно включить /var/lib/mysql/backup в соответсвующий FileSet (если вы делаете бэкап выбраных папок, а не полный бэкап всего сервера. + ~1 час экономии.
Я находился в ситуации, когда бэкапы всех серверов LAMP (linux-apache-mysql) выполнялись около 8-ми часов. Из-за большого размера баз данных и вэб контента.
Для решения даной проблемы было решено переводить все сервера на ежедневный диференциальный бэкап. Полные бэкапы делать только в пятницу, субботу и воскресение для отдельных 3-х груп серверов. Как не странно времени это не сильно сэкономило. (~1,5 часа).
Спасло положение сжатие баз данных вызовом отдельного скрипта:
#!/bin/bash
root_pass='mysql_root_password'
databases=`echo «show databases»|mysql -u root -p$root_pass|grep -v "^D" | grep -v «information_schema»`
if [ "$1" == «full» ]; then
echo Starting full backup
for FLS in ${databases}
do
/usr/bin/mysqldump --force --single-transaction --opt -u root -p$root_pass ${FLS} |/bin/bzip2 -c -9 > /var/lib/mysql/backup/${FLS}.full.mysql.bz2
done
fi
if [ "$1" == «clean» ]; then
/bin/rm /var/lib/mysql/backup/*
fi
размещается он на клиент-сервере в папке /etc/bacula/scripts/. Устанавливаются права на выполнение (chmod +x).
Также нужно создать папку куда будут падать сжатые базы: mkdir /var/lib/mysql/backup
На сервере бакулы нужно создать отдельную джобу для бэкапа баз даных, где и указать использование скрипта:
JobDefs {
Name = «DabasesBackupJobName»
Type = Backup
Level = Full
ClientRunBeforeJob = "/etc/bacula/scripts/mysqlbackup_script_name 'full'"
ClientRunAfterJob = "/etc/bacula/scripts/mysqlbackup_script_name 'clean'"
}
На этом этапе пару сотен гигабайт предварительно сжатых и отобраных даных залетают на сервер бакулы на 2-3 часа.
Еще лучше сделать крон задание и запускать этот скрипт в одно и то же время на всех серверах, а дампы забирать вместе с другими файлами. Просто нужно включить /var/lib/mysql/backup в соответсвующий FileSet (если вы делаете бэкап выбраных папок, а не полный бэкап всего сервера. + ~1 час экономии.
Мне кажется, что тут используется один пул под все бекапы, что в принципе не совсем правильно.
Если у вас для хранения бекапов только один сервер, то имеет смысл делать 3 пула: для полных, дифференциальных и инкрементальных бекапов. При этом для каждого пула указывается свой Volume Retention, чтобы можно было хранить полные бекапы несколько месяцев, дифференциальные месяц, а инкрементальные за неделю (при том, что полные бекапы делаются раз в месяц, дифференциальные — раз в неделю, а инкрементальные — каждый день).
Еще удобно использовать правило, что один Volume, это одна задача и маркировать его примерно так: ${Client}_${JobId}_${Level}, в этом случае удобнее файлами управлять. Также можно использовать виртуальный AutoChanger, т.к. Device в bacula-sd умеет работать только с одним открытым Volume.
P.S. В этой статье не упоминается дедупликация на клиенте и сторадже — видимо потому что статья 2010 года. С тех пор Bacula заметно развилась, если хотите бесплатно, то советую посмотреть на свежую версию 9, в ней появилось много функций из Enterprise-версии (базовая дедупликация, Aligned Volumes, Client Initiated Backup, Progressive Virtual Full и другие). Ну или сразу взять Enterprise, в нее фичи добавляют быстрее, чем в Community версию (насколько в знаю, в русскоязычном сегменте его продает только backup-solutions.ru, или можно напрямик в baculasystems.com).
Если у вас для хранения бекапов только один сервер, то имеет смысл делать 3 пула: для полных, дифференциальных и инкрементальных бекапов. При этом для каждого пула указывается свой Volume Retention, чтобы можно было хранить полные бекапы несколько месяцев, дифференциальные месяц, а инкрементальные за неделю (при том, что полные бекапы делаются раз в месяц, дифференциальные — раз в неделю, а инкрементальные — каждый день).
Еще удобно использовать правило, что один Volume, это одна задача и маркировать его примерно так: ${Client}_${JobId}_${Level}, в этом случае удобнее файлами управлять. Также можно использовать виртуальный AutoChanger, т.к. Device в bacula-sd умеет работать только с одним открытым Volume.
P.S. В этой статье не упоминается дедупликация на клиенте и сторадже — видимо потому что статья 2010 года. С тех пор Bacula заметно развилась, если хотите бесплатно, то советую посмотреть на свежую версию 9, в ней появилось много функций из Enterprise-версии (базовая дедупликация, Aligned Volumes, Client Initiated Backup, Progressive Virtual Full и другие). Ну или сразу взять Enterprise, в нее фичи добавляют быстрее, чем в Community версию (насколько в знаю, в русскоязычном сегменте его продает только backup-solutions.ru, или можно напрямик в baculasystems.com).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Настройка и понимание Bacula