Я использую Bacula для удаленного подключения к серверам (в другом DC) и резервного копирования.
Из-за ограничений скорости и отсутствия перебоев в работе офисной сети в течение дня я не вижу возможности выполнять полное резервное копирование наших 4 серверов одновременно, поэтому вместо этого мы можем разделить полные резервные копии, чтобы каждую неделю на одном сервере полная резервная копия, по очереди.
Требование 1 - Распределение нагрузки при передаче полного резервного копирования
Если бы у нас было 4 сервера, мы хотим выполнить полное резервное копирование по очереди следующим образом:
Учитывая любую конкретную дату, мы хотим сохранить полную резервную копию плюс последнюю полную резервную копию перед этим. Следует сохранять все инкрементные резервные копии с этого момента до самой последней полной резервной копии.
Требование 2 - Полный и дополнительный в отдельных бассейнах
У меня есть два пула хранения, один для инкрементного и один для полного, нам нужно указать Bacula использовать полный пул, если инкрементный снимок не может найти предыдущий полный, в противном случае используйте pool-inc.
Требование 3 - масштабируемость
Возможно, в будущем могло бы быть больше серверов, если бы я хотел чередовать их по субботам и воскресеньям (давая до 8 расписаний в месяц по дням [1,2], [8,9], [15,16], [22, 23]). Есть ли более простой способ определить задания, поскольку я вижу, что он становится большим файлом конфигурации.
Принимая во внимание отдельные моменты вашего вопроса:
Требование 1 - Распределение нагрузки
Вам нужно выяснить это для вашей среды - "разумный" зависит от множества факторов (сколько машин, сколько данных, какой тип носителя вы выполняете резервное копирование, какая у вас пропускная способность, сколько деньги, которые ваш босс готов выделить на резервное копирование, независимо от того, есть ли у вас потолочный кот в вашем центре обработки данных, которого можно обучить вращать ленты ...)
Вы также можете изучить «синтетические полные резервные копии» (Bacula называет их VirtualFull резервные копии) - они могут создавать «полную» резервную копию без необходимости извлекать данные из клиента, объединяя данные, которые вы создали в последней полной копии, плюс все инкрементные / дифференциальные изменения.
Требование 2 - Полный и инкрементный в альтернативных пулах
Вы, кажется, не обнаружили FullPool, IncrementalPool и DifferentialPool директивы конфигурации. Обратитесь к руководству Bacula для получения дополнительной информации об этом.
Это то, что вам нужно для разделения резервных копий на разные пулы по типу задания.
Требование 3 - масштабируемость
Во-первых, если вы используете Bacula и делаете что-то даже средней сложности, откажитесь от небольшого файла конфигурации прямо сейчас. Конфигурация директора будет большой.
Что ты делаешь с JobDef и Schedule директивы - это правильный способ справиться с вещами. Добавьте определения по мере необходимости, чтобы удовлетворить ваши требования.
На вашем месте я бы не использовал даты резервного копирования в качестве соглашения об именах - назовите свои расписания (и параметры задания по умолчанию) «Группа A», «Группа B» и т. Д. (Или что-то в равной степени).
Документируйте, в какой группе резервного копирования находится каждый сервер, чтобы вы могли легко перебалансировать нагрузку на резервное копирование, перемещая сервер из одной группы в другую.
Конечно, вы можете сделать это с именами, основанными на дате, но мне легче думать о группах резервного копирования как об абстрактной концепции. Плюс если Group A истекает кровью Group Bвременные рамки резервного копирования Я всегда могу переместить все Group B вперед на день, изменив определение расписания, и мне не нужно менять его название.