Централизованное резервное копирование данных Windows и *nix серверов средствами Bacula
Как нетрудно догадаться, речь пойдет о бекапах.
Своевременный бекап - крайне важная часть работы системного администратора. Своевременный бекап делает сон спокойным, а нервы стальными, придает сил и оберегает здоровье.
Думаю вполне резонным будет предположение, что данная тема уже набила оскомину, но все же я рискну поделиться своим опытом. На суд читателя будет представлена клиент-серверная реализация схемы резервного копирования. В качестве инструмента я выбрал open source проект Bacula. По более чем полугодовому опыту его использования остаюсь доволен своим выбором.
Bacula состоит из нескольких демонов, каждый из которых несет свою функциональную нагрузку. На рисунке ниже схематично представлена взаимосвязь этих демонов.
Под хабракатом я опишу все демоны подробно
В моем случае резервному копированию подлежат:
Конфигурационные файлы различных демонов со всех серверов.
MySQL базы данных.
Документооборот с файлового сервера Windows.
Различные важные данные с nix серверов(движки сайтов/форумов, etc..)
1.Описание демонов Bacula
Система построена по технологии клиент-сервер, и для передачи данных использует протокол TCP. Резервные копии создаются в собственном, полностью открытом формате.
Система резервирования данных Bacula состоит из четырёх основных элементов: Director Daemon, Storage Daemon, File Daemon и Bacula Console. Все эти элементы реализованы в виде самостоятельных приложений.
Director Daemon (DD) - это центральный элемент системы, осуществляющий управление её остальными компонентами. В его задачи входит управление процессом резервирования/восстановления данных, обеспечение интерфейса управления для администраторов и многое другое. Говоря проще - это диспетчер, который инициирует все процессы и отслеживает ход их выполнения.
Storage Daemon (SD) - приложение, отвечающее за чтение/запись данных непосредственно на устройства хранения информации. Принимает управляющие команды от DD, а также резервируемые данные от/к File Daemon.
File Daemon (FD) - этот элемент ещё можно назвать Агентом. Ведь именно он работает в рамках операционной системы, данные которой необходимо резервировать. File Daemon выполняет всю рутину, осуществляя обращение к резервируемым файлам и их дальнейшую передачу к SD. Также на стороне FD выполняется шифрование резервных копий, если это определено конфигурацией.
Bacula Console (BC) - интерфейс администратора сиcтемы. По своей сути, это командный интерпретатор для управления Bacula. Строго говоря, Bacula Console может быть расширена с помощью графических систем управления, которые, как правило, являются всего лишь надстройкой над BC. К таким системам можно отнести Tray Monitor и Bat. Первая устанавливается на компьютере администратора системы и осуществляет наблюдение за работой системы резервирования, а вторая обеспечивает возможность управления посредством графического интерфейса.
Bacula Catalog - база данных, в которой хранятся сведения обо всех зарезервированных файлах и их местонахождении в резервных копиях. Каталог необходим для обеспечения эффективной адресации к требуемым файлам. Поддерживаются MySql, PostgreSql и SqLite.
Такое структурное деление позволяет организовать очень гибкую систему резервирования, когда Storage Daemon разворачивается на выделенном сервере с несколькими устройствами хранения данных. Также Bacula Director может управлять несколькими экземплярами SD, обеспечивая резервирование части данных на одно устройство хранения, а части - на другое.
2. ОС и железо
Теперь, когда у читателя сформировалось представление о работе демонов Bacula, я перейду к описанию того, как я реализовал всю эту красоту у себя.
В качестве аппаратного обеспечения для DD, SD и Bacula Catalog у меня выступает PC со следующими характеристиками
Устройство
Модель
количество
Емкость/Частота
HDD
Hitachi HDS723020BLA642
3
2Tb
CPU
AMD Phenom(tm) II X4 970 Processor
1
3500 Mhz
Motherboard
Gigabyte GA-880GA-UD3H
1
-
RAM
3541 Mb
О используемых на сервере ОС и версиях ПО
# lsb_release -a
LSB Version: :core-4.0-ia32:core-4.0-noarch:graphics-
4.0-ia32:graphics-4.0-noarch:printing-4.0-ia32:printing-4.0-noarch
Distributor ID: CentOS
Description: CentOS release 5.7 (Final)
Release: 5.7
Codename: Final
# uname -a
Linux backupsrv.domain.ru 2.6.18-274.7.1.el5PAE
#1 SMP Thu Oct 20 17:03:59 EDT 2011 i686 athlon i386 GNU/Linux# rpm -qa |grep -E "syslog-ng|bacula|mysql-ser"
bacula-libs-5. 0.3-1
syslog-ng-2.1.4-9.el5
bacula-mysql-5. 0.3-1
mysql-server-5. 0.77-4.el5_6.6
Хранением данных занимаются несколько software(mdadm) RAID массивов.
Под систему три партиции на трех дисках, грузится можно с любого из них, под бекапы один массив из двух партиций.
Имя массива
из каких партиций
точка монтирования
Файловая система
Уровень массива
md0
/dev/sda1,/dev/sdb1,/dev/sdc1
boot
ext2
1
md1
/dev/sda2,/dev/sdb2,/dev/sdc2
/
ext3
1
md2
/dev/sda3,/dev/sdb3
/backup
ext4
1
3. Описание схемы резервного копирования и настроек демонов Bacula
Всего у меня сконфигурированы 19 клиентов Bacula, но подробно я остановлюсь на описании бекапа сервера биллинга и документов с файлового сервера Windows. Фокус на эти два сервера обусловлен тем, что остальные клиенты настроены аналогично, и на примере этих серверов-клиентов можно строить свои конфигурации.
Резервное копирование сервера биллинга это, по сути, бекап базы данных mysql и конфигурационных файлов демонов.
BD позволяет выполнять локальный скрипт на клиенте как до, так и после задания.
Каждую ночь, при старте задания на бекап сервере, запускается локальный(на самом сервере биллинга) скрипт, который создает архив базы биллинга, далее этот архив забирает BD и помещает на соответствующий пул томов(на самом деле операциями с чтением/записью управляет SD, но это сейчас не важно). Сразу же после выполнения задания запускается еще один скрипт, который в свою очередь, перемещает созданный архив в отдельную папку на сервере биллинга, для пущей надежности. Таким образом архив БД будет как у Bacula, так и локально на сервере биллинга(да, я параноик). Подробнее эти механизмы и скрипты будут описаны ниже.
С файлового сервера Windows сохраняем весь необходимый документооборот. В воскресенье создается Full бекап, каждый последующий день, с понедельника по субботу, Diff бекапы.
Теперь о конфигурационных файлах демонов Bacula. Начнем с самого объемного - bacula-dir.conf.
Файлы конфигурации всех демонов Bacula состоят из описаний, так называемых, ресурсов. Каждый из ресурсов характеризует определенный функционал демона.
Я буду комментировать каждую строчку в конфиге, поэтому далее будут следовать блоки-ресурсы файлов Bacula(bacula-dir.conf, bacula-sd.conf, bacula-fd.conf), если что-то нужно объяснить более подробно укажите это в комментариях.
Ресурс Dirtector
Director {
# имя bacula director'а
Name = backupsrv.domain.ru-dir
# какой порт слушать, у нас default
DIRport = 9101# путь к скрипту, где лежат sql запросы для работы с Bacula Catalog(mysql database)
QueryFile = "/usr/lib/bacula/query.sql"# здесь хранятся статус файлы демона
WorkingDirectory = "/backup/bacula-work/"# pid файл демона
PidDirectory = "/var/run"# сколько заданий может запускаться одновременно
Maximum Concurrent Jobs = 1# пароль для доступа в BC и управления демонами
Password = "bacula_paS$w0rD10*"# куда слать mail'ы, описано в ресурсе Messages
Messages = Daemon
# на какой адрес биндится процессу
DirAddress = 10.1.19.2
}
Ресурс Messages
Messages {
# это имя прописано в ресурсе Director, помните?
Name = Daemon
# команда для отправки email
mailcommand = "/usr/sbin/bsmtp -f \"\(Bacula\) \<%r\>\" -s \"Bacula daemon message\" %r"# шлем все на майл админам(root алиас на admins@domain.ru) # высылаются только алярмы, ероры и прочую важность
mail = root@backupsrv.domain.ru = alert,error,fatal,terminate, !skipped
# что выводить на консоль
console = all, !skipped, !saved
# что в лог
append = "/var/lib/bacula/log" = alert,error,fatal,terminate, !skipped
}
Для каждого клиента в заданиях указаны Pool и Storage.
Pool, извините за тавтологию, это пул томов(volume) на который размещаются резервные копии данных клиентов. У меня тома - это файлы в формате bacula, размещенные на software raid массиве. Для разных клиентов могут быть определены разные пулы томов. К примеру у меня созданы 6 пулов, для разных типов клиентов. В примере ниже описан лишь один из них, для данных биллинга.
Storage описывает какие физические устройства будут использованы в качестве томов.
(Storage BGB-ST описан в конфиге SD)
Ресурс Pool
Pool {
# имя пула, указывается в заданиях резервного копирования
Name = bgb
# тип пула, емнип этой версии только такой поддерживается
Pool Type = Backup ## повторно использовать тома(сначала пишет в 1-ый, потом в 2-ой,# потом 3-й, 3-й закончился - снова в 1-й)
Recycle = yes
# удалять записи из bacula catalog(из mysql базы бакулы)# старше нижеуказанных значений
AutoPrune = yes
# период в течении которого информация о томах(volumes)# хранится в базе данных, по истечению периода эта информация# удаляется
Volume Retention = 90 days
# максимальный объем тома
Maximum Volume Bytes = 100G
# максимальное количество томов в пуле
Maximum Volumes = 3# с каких символов начинается имя тома
LabelFormat = "Vol"
}
Ресурс Storage
Storage {
# имя хранилища и пароль (о соответствии имен и паролей в разных конфигах# демонов Bacula, я расскажу позже)
Name = BGB-F
Password = "StoRage_PaSSw0rD"# fqdn имя сервера
Address = backupsrv.domain.ru
# порт оставляем стандартный
SDPort = 9103# имя девайса описанного в конфиге SD
Device = BGB-ST
# у нас все пишется на софтовый рэйд в файлы собственного формата # bacula(например /backup/bgbilling/Vol0001)
Media Type = File
}
Задание на примере бекапа базы данных биллинга.
Ресурс Client
Client {
# имя
Name = bgbilling-fd
# ip адрес клиента
Address = 10.103.2.5# порт, который клиент слушает
FDPort = 9102# имя mysql базы данных Bacula
Catalog = MyCatalog
# пароль для FD
Password = "Fd_paSSw0rd"# период в течении которого информация о файлах задания# хранится в базе данных, по истечению периода эта информация# удаляется(но не сами данные!!)
File Retention = 45 days
# тоже самое, только для самого задания
Job Retention = 90 days
# удалять записи из каталога(бд mysql) старше вышеуказанных значений
AutoPrune = yes
}
Само задание.
Ресурс Job
Job {
# имя задания
Name = "BGBilling"# тип(backup or restore)
Type = Backup
# уровень(полный, диференциальный или инкрементный)
Level = Full
# имя клиента
Client=bgbilling-fd
# имя файл-сета(там рассказано что бекапить, а что не бекапить)
FileSet="bgbilling-set"# имя SD ресурса
Storage = BGB-F
# имя пула(для разных клиентов разные пулы томов(volume) куда пишутся сами # бекапы)
Pool = bgb
# скрипт запускающийся ДО выполнения задания (путь до скрипта -# это путь НА КЛИЕНТЕ!)
ClientRunBeforeJob = "/root/sh/before_bg_db_backup.sh"# скрипт запускающийся ПОСЛЕ выполнения задания
ClientRunAfterJob = "/root/sh/after_bg_db_backup.sh"# имя ресурса messages, который будет использоваться для этого задания
Messages = Standard
# имя шедулера
Schedule = "DaylyFullBGBilling"# в этом файле содержится информация о том, какие файлы должны будут# востанавливаться, на каком вольюме находятся файлы,# где конкретно они находятся - это очень важные файлы, их нужно бэкапить
Write Bootstrap = "/backup/bsr-files/bgbilling.bsr"
}
Я обещал подробнее остановиться на скриптах выполняющихся до и после задания.
Скрипт до задания
$ sudo cat /root/sh/before_bg_db_backup.sh
#!/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
mysql -e "flush tables with read lock" --user=root --password="ololo" bgbilling
lvcreate -L20G -s -n backup_db /dev/BGB-LVM1/billing_db
mysql -e "unlock tables" --user=root --password="ololo" bgbilling
mount /dev/BGB-LVM1/backup_db /backup
tar -czf /usr/backups/`date +%Y-%m-%d_%H-%M`.bgb.tgz /backup/bgbilling/
umount /backup
lvremove -f /dev/BGB-LVM1/backup_db
FileSet {
Name = "bgbilling-set"
Include {
Options {
# разработчики яро рекомендуют юзать это опцию, # создается сигнатура забекапленных файлов в md5
signature = MD5
}
# перечисляем то, что нужно бекапить
File = /usr/backups
File = /etc
File = /root/sh
}
Exclude {
# а это бекапить нет нужды
File = /usr/backups/after_run_bacula_backup/*
File = /usr/backups/after_run_bacula_backup
}
}
Расписание запуска задания.
Ресурс Schedule
Schedule {
# имя расписания
Name = "DaylyFullBGBilling"# когда запускать задание
Run = Full sun-sat at 1:10
}
Подробно комментировать ресурсы для резервного копирования документов с сервера Windows я не буду, приведу соответствующую часть конфига bacula-dir.conf полностью
Storage {
Name = WINDOWS-F
Address = backupsrv.domain.ru # N.B. Use a fully qualified name here
SDPort = 9103
Password = "StoRage_PaSSw0rD"
Device = WINDOWS-ST
Media Type = File
}
Pool {
Name = windows
Pool Type = Backup
Recycle = yes # Bacula can automatically recycle Volumes
AutoPrune = yes # Prune expired volumes
Volume Retention = 60 days
Maximum Volume Bytes = 30G # Limit Volume size to something reasonable
Maximum Volumes = 5# Limit number of Volumes in Pool
LabelFormat = "Vol-Windows"
}
Job {
Name = "centra-bdk"
Type = Backup
Level = Full
Client= centra-bdk-fd
FileSet="centra-bdk-fd-fs"
Storage = WINDOWS-F
Pool = windows
Messages = Standard
Schedule = "Windows_Centra-bdk"
Write Bootstrap = "/backup/bsr-files/centra-bdk.bsr"
}
FileSet {
Name = "centra-bdk-fd-fs"
Include {
Options {
signature = MD5
Compression=GZIP
}
# обратите внимание на двойной бекслэш и ковычки!
File = "D:\\Public\\!!!Абонентский\ Отдел"
File = "D:\\Public\\Отдел\ ИТ"
File = "D:\\Public\\tex\\Maps"
File = "D:\\Public\\сервис\ мены "
File = "D:\\Public\\Отдел\ продаж1"
}
Exclude {
File = "*.mp3"
File = "*.avi"
File = "*.wmv"
}
}
Client {
Name = centra-bdk-fd
Address = 10.1.19.50
FDPort = 9102
Catalog = MyCatalog
Password = "Fd_paSSw0rd"# password for FileDaemon
File Retention = 30 days # 30 days
Job Retention = 2 months # two months
AutoPrune = yes # Prune expired Jobs/Files
}
Schedule {
Name = "Windows_Centra-bdk"
Run = Level=Full on sun at 07:10
Run = Level=Differential on mon-sat at 22:15
}
Конфигурационный файл BD на этом завершен. Переходим к конфигурации SD - описанию файла bacula-sd.conf
Ресурс Storage
Storage {
# имя для SD
Name = backupsrv.domain.ru-sd
# порт стандартный
SDPort = 9103# рабочая директория процесса(для статус файлов)
WorkingDirectory = "/var/lib/bacula"# pid будет здесь
Pid Directory = "/var/run/bacula"# биндится на этом ip
SDAddress = 10.1.19.2
}
Ресурс Director(связь с BD описанном в конфиге bacula-dir.conf)
Director {
# имя DD, того самого, который был описан ранее
Name = backupsrv.domain.ru-dir
# пароль
Password = "StoRage_PaSSw0rD"
}
Начинается описание различных девайсов, всего у меня используется 4 разных девайса. Я приведу в качестве примера два, для биллинга и для Windows.
Ресурс Device для биллинга.
Device {
# имя, о соответствии имен и паролей будет сказано ниже
Name = BGB-ST
# тип
Media Type = File
# директория где лежат файлы этого устройства(тома, volumes)
Archive Device = /backup/bgbilling
# новые тома будут обзываться согласно настроек Pool'а(здесь Vol*) см. # конфиг DD
LabelMedia = yes;
# для устройства типа File должно быть так
Random Access = Yes;
# если устройство открыто, использовать его
AutomaticMount = yes;
# думаю понятно =)
RemovableMedia = no;
# открывать только тогда, когда стартует соответствующие задание
AlwaysOpen = no;
}
Ресурс Device для файлового сервера Windows
Device {
Name = WINDOWS-ST
Media Type = File
Archive Device = /backup/windows
LabelMedia = yes;
Random Access = Yes;
AutomaticMount = yes;
RemovableMedia = no;
AlwaysOpen = no;
}
Ресурс Messeges.
Messages {
# имя
Name = Standard
# отправлять DD = имя директора = слать все
director = backupsrv.domain.ru-dir = all
}
Конфигурационный файл bconsole.conf, доступ в консоль Bacula.
Director {
Name = backupsrv.ray-com.ru-dir
DIRport = 9101
address = 10.1.19.2
Password = "bacula_paS$w0rD10*"
}
Не забудьте создать соответствующие Storage папки и назначить bacula владельцем этих папок.
Конфигурирование серверной части завершено.
Конфиг клиента.
Важно отметить, что каждый из клиентов должен резолвить fqdn имя сервера в его ip адрес! Обеспечте это средствами dns или пропишите в hosts!
Ресурс Director.
Director {
# имя BD
Name = backupsrv.domain.ru-dir
# пароль для доступа к BD к клиенту(указан в ресурсе Client у BD)
Password = "Fd_paSSw0rd"
}
Ресурс FileDaemon
FileDaemon {
# имя клиента
Name = bgbilling-fd
# слушаем порт 9102
FDport = 9102
WorkingDirectory = /usr/lib/bacula
Pid Directory = /var/run/bacula
FDAddress = 10.103.2.5
}
Ресурс Messeges
Messages {
Name = Standard
director = backupsrv.domain.ru = all, !skipped, !restored
append = "/var/bacula/log" = all, !skipped
}
В комментариях конфигурационных файлов я упоминал о схеме соответствия паролей и имен демонов в различных конфирурационных файлах, так вот, если вы где-то запутались - воспользуйтесь картинкой ниже.
4. Пример процедуры востановления
Для мониторинга и востановления ваших резервных копий удобно использовать утилиту bat.
В Ubuntu она ставиться так
# sudo aptitude install bacula-console-qt
В портажах Gentoo я её не нашел, поэтому собирал из исходников. Конфигурационный файл bat.conf полностью аналогичен bconsole.conf, приведенному ранее.
Итак, к примеру я хочу востановить архив базы данных биллинга за определенное число. Алгоритм, которым пользуюсь я, таков:
1. Открываем bat и находим нужное задание
2. вводим команду list files jobid=3059 для того чтобы убедиться что в задании есть нужные файлы
3. Теперь переходим в консоль(мне так удобнее просто=)). В консоли я восстановлю архив биллинга на другого клиента
$ sudo bconsole
[sudo] password for onotole:
Connecting to Director 10.1.19.2:9101
1000 OK: backupsrv.domain.ru-dir Version: 5.0.3 (30 August 2010)
Enter a period to cancel a command.
*restore
Automatically selected Catalog: MyCatalog
Using Catalog "MyCatalog"
First you select one or more JobIds that contain files
to be restored. You will be presented several methods
of specifying the JobIds. Then you will be allowed to
select which files from those JobIds are to be restored.
To select the JobIds, you have the following choices:
1: List last 20 Jobs run
2: List Jobs where a given File is saved
3: Enter list of comma separated JobIds to select
4: Enter SQL list command
5: Select the most recent backup for a client
6: Select backup for a client before a specified time
7: Enter a list of files to restore
8: Enter a list of files to restore before a specified time
9: Find the JobIds of the most recent backup for a client
10: Find the JobIds for a backup for a client before a specified time
11: Enter a list of directories to restore for found JobIds
12: Select full restore to a specified Job date
13: Cancel
Select item: (1-13): 9
Defined Clients:
1: 192.168.15.12-fd
2: 1.1.1.1-fd
3: 1.1.1.75-fd
4: ASTERISK-configs-fd
5: DHCPD-configs-fd
6: GW1-configs-fd
7: GW2-configs-fd
8: NAS-20-configs-fd
9: NAS-21-configs-fd
10: NAS-6-configs-fd
11: NAS-ololo-configs-fd
12: NS_AND_MAIL-configs-fd
13: RADIUS-ololo-configs-fd
14: VIRTSRV1-configs-fd
15: bgbilling-fd
16: configs-fd
17: domain.ru-fd
18: mydomain.ru-fd
19: tv.domain.ru-fd
20: zabbix.domain.ru-fd
Select the Client (1-20): 15
Automatically selected FileSet: bgbilling-set
+-------+-------+----------+----------------+---------------------+------------+
| JobId | Level | JobFiles | JobBytes | StartTime | VolumeName |
+-------+-------+----------+----------------+---------------------+------------+
| 3,292 | F | 1,666 | 10,874,552,420 | 2011-12-19 02:31:08 | Vol0014 |
+-------+-------+----------+----------------+---------------------+------------+
To select the JobIds, you have the following choices:
1: List last 20 Jobs run
2: List Jobs where a given File is saved
3: Enter list of comma separated JobIds to select
4: Enter SQL list command
5: Select the most recent backup for a client
6: Select backup for a client before a specified time
7: Enter a list of files to restore
8: Enter a list of files to restore before a specified time
9: Find the JobIds of the most recent backup for a client
10: Find the JobIds for a backup for a client before a specified time
11: Enter a list of directories to restore for found JobIds
12: Select full restore to a specified Job date
13: Cancel
Select item: (1-13): 12
Enter JobId to get the state to restore: 3059
Selecting jobs to build the Full state at 2011-12-06 02:28:47
You have selected the following JobId: 3059
Building directory tree for JobId(s) 3059 ... +++++++++++++++++++++++++++++++++++++++++++++
1,535 files inserted into the tree.
You are now entering file selection mode where you add (mark) and
remove (unmark) files to be restored. No files are initially added, unless
you used the "all" keyword on the command line.
Enter "done" to leave this mode.
cwd is: /
$ ls
etc/
root/
usr/
$ ls usr
usr/
$ mark usr
1,667 files marked.
$ done
Bootstrap records written to /backup/bacula-work//backupsrv.domain.ru-dir.restore.8.bsr
The job will require the following
Volume(s) Storage(s) SD Device(s)
===========================================================================
Vol0010 BGB-F BGB-ST
Volumes marked with "*" are online.
1,667 files selected to be restored.
Run Restore job
JobName: restore
Bootstrap: /backup/bacula-work//backupsrv.domain.ru-dir.restore.8.bsr
Where: /usr/restore
Replace: always
FileSet: bgbilling-set
Backup Client: bgbilling-fd
Restore Client: bgbilling-fd
Storage: BGB-F
When: 2011-12-26 15:01:38
Catalog: MyCatalog
Priority: 10
Plugin Options: *None*
OK to run? (yes/mod/no): mod
Parameters to modify:
1: Level
2: Storage
3: Job
4: FileSet
5: Restore Client
6: When
7: Priority
8: Bootstrap
9: Where
10: File Relocation
11: Replace
12: JobId
13: Plugin Options
Select parameter to modify (1-13): 5
The defined Client resources are:
1: bgbilling-fd
2: GW1-configs-fd
3: GW2-configs-fd
4: NAS-6-configs-fd
5: NAS-20-configs-fd
6: NAS-21-configs-fd
7: NAS-ololo-configs-fd
8: DHCPD-configs-fd
9: ASTERISK-configs-fd
10: NS_AND_MAIL-configs-fd
11: VIRTSRV1-configs-fd
12: mydomain.ru-fd
13: tv.domain.ru-fd
14: domain.ru-fd
15: 1.1.1.1-fd
16: 1.1.1.75-fd
17: zabbix.domain.ru-fd
18: 192.168.15.12-fd
Select Client (File daemon) resource (1-18): 2
Run Restore job
JobName: restore
Bootstrap: /backup/bacula-work//backupsrv.ray-com.ru-dir.restore.8.bsr
Where: /usr/restore
Replace: always
FileSet: bgbilling-set
Backup Client: bgbilling-fd
Restore Client: GW1-configs-fd
Storage: BGB-F
When: 2011-12-26 15:01:38
Catalog: MyCatalog
Priority: 10
Plugin Options: *None*
OK to run? (yes/mod/no): yes
Job queued. JobId=3453
You have messages.
*
4. Ждем успешного выполнения задания, статус можно отслеживать в том же bat
Еще несколько скриншотов
Благодарю всех кто дочитал мой опус до конца.
В качестве завершения позволю себе еще несколько советов.
Важно не только делать бекапы и отслеживать что они выполнились без ошибок, но так же и регулярно их разворачивать и проверять. Подобная практика даёт еще +100 к указанным в начале спокойствию, крепкости нервов и здоровью. Так же очень хорошей практикой является регулярное резервное копирование базы данных bacula и bsr файлов.
