На сайте A я успешно настроил директор bacula на одном хосте, несколько File Daemons на хостах, которые я хочу создать, и, наконец, один Storage Daemon, на котором фактически хранится резервная копия.
Если в здании A случится авария, мне нужен второй Storage Daemon на другом сайте, Site B.
Наборы файлов, Директор и т. Д. Будут такими же, за исключением того, что задания будут храниться и в другом демоне хранилища.
Есть ли какие-нибудь передовые практики по этому поводу?
Вы можете либо перенести, либо скопировать задание с рабочего тома на последний:
... Термин "миграция", используемый в контексте Bacula, означает перемещение данных из одного тома в другой. В частности, это относится к заданию (похожему на задание резервного копирования), которое считывает данные, резервные копии которых были ранее на томе, и записывает их на другой том ...
... Процесс копирования по сути идентичен функции миграции, за исключением того, что копируемое задание остается без изменений ...
http://www.bacula.org/manuals/en/concepts/concepts/Migration_Copy.html
Редактировать:
В случае, если вы используете программное сжатие, было бы лучше скопировать файлы тома с одного сайта на другой (с помощью миграции он будет распакован и снова сжимается).
Вы можете использовать RunScript в ресурсе задания для запуска rsync, ftp, scp или любого другого доступного метода копирования после завершения резервного копирования.
Не забудьте скопировать базу данных каталога, иначе вам нужно будет использовать bscan или что-то еще для восстановления информации. Вы также можете использовать репликацию MySQL.
Эффективное выполнение того, что вы хотите, означает запуск резервного копирования два раза (два задания, одно резервное копирование на SD на сайте A, другое на SD на сайте B) - лучший подход (при условии, что вы выполняете резервное копирование файлов на диск) быть использовать что-то вроде DRBD (Linux) или GEOM ворота (FreeBSD) для дублирования внутреннего хранилища, которое использует ваш демон: это обеспечивает репликацию данных, не требуя второго задания резервного копирования (хотя у него есть свои проблемы, если ваше сетевое соединение ненадежно).
Другие варианты включают rsyncпередача ваших ленточных файлов стороннему провайдеру (например, rsync.netили ваш собственный вторичный центр обработки данных, если он у вас есть), который предоставляет вам локальную и удаленную копию в случае аварии, поражающей ваш основной центр обработки данных. Большое предостережение заключается в том, что ваша «удаленная» копия всегда не синхронизируется, пока ваша система пересылает файлы.
Как бы то ни было, моя реализация представляет собой вариацию второго метода, который я описал: в рамках сценариев монтирования / размонтирования Bacula сервер выполняет синхронизацию файлов виртуальной ленты (при подключении он извлекает любые изменения с удаленного сайта. При размонтировании он подталкивает изменения).
Это действительно увеличивает время монтирования / размонтирования лент, что увеличивает время, необходимое для завершения резервного копирования (резервные копии зависают, ожидая отключения «ленты» во время работы rsync), но при достаточной пропускной способности между сайтами (и интеллектуальными дельтами rsync) накладные расходы не так уж и плохи.