Всем привет!
настраиваю бакулу, столкнулся с проблемой - нужно хранить файлы за предыдущие три месяа (три полные копии), за предыдущую неделю целиком (один Full Backup + Increment.)Как все это грамотно организовать?
Дело в том что хочется динамически добавлять -удалять сервера из бекапирования, при этом хранить все в общих пулах, один на три месяца, другой недельный(инкрементарный).
Насколько это реально? изучая документацию я пока вижу только что нужно для каждой группы серверов задавать отдельный пул и жестко прописывать соответствующие переменные.
Volume Retention = 30 days
Maximum Volume Bytes = 250G
Maximum Volumes = 3
Maximum Volume Jobs = 10Хочется гибкости и минимального исправления основных конфигов в процессе дальнейшей эксплуотации.
Спасибо! прошу к обсуждению :)
> Хочется гибкости и минимального исправления основных конфигов в процессе дальнейшей эксплуотации.Документацию всю прочитали?
>> Хочется гибкости и минимального исправления основных конфигов в процессе дальнейшей эксплуотации.
> Документацию всю прочитали?ну понеслась... а на вопрос ответить слабо?
всю
други оченьнадо!
>>> Хочется гибкости и минимального исправления основных конфигов в процессе дальнейшей эксплуотации.
>> Документацию всю прочитали?
> ну понеслась... а на вопрос ответить слабо?
> всюНастоятельно рекомендую: 1 бекап = 1 пул = 1 файл.
Сразу избавляет от очень многих проблем, и добавляет гибкости.
В остальном - если нужно, не стремайтесь прописывать нужные вам параметры хоть в каждую секцию.
Вот хорошая цитата из хорошей статьи:
"Основной принцип - разделяй и властвуй, т.е. для каждого клиента определяется отдельное задание, отдельный планировщик, отдельный FileSet, отдельные пулы (для каждого типа задания отдельный пул), отдельный каталог (MediaType) и т.д. Несколько раз пробовал группировать для упрощения настройки и каждый раз жалел при первом же изменении стратегии резервного копирования."
http://www.bog.pp.ru/work/bacula.htmlТам же есть и примеры.
Раздел "Схема "перекрёстного опыления" на дисковые массивы".
>>> Хочется гибкости и минимального исправления основных конфигов в процессе дальнейшей эксплуотации.
>> Документацию всю прочитали?
> ну понеслась... а на вопрос ответить слабо?
> всюВообще поддерживаю предыдущего оратора, что лучше использовать один пул для одного задания. Сергей Богомолов очень хорошо описал бакулу и также ее хорошо настроил, после него я внес только небольшие изменения в конфигурацию, но также до сих пор использую его настройки.
Если Вы будете все класть в один пул да еще и в один файл, то может возникнуть ситуация когда у Вас случится какой-нибудь форс мажор с БД, и придется восстанавливать данные из файлов пула, вот тогда Вы получите массу удовольствия от сканирования больших файлов на получение списка job, но еще большее удовольствие Вы получите доставая из файла бэкап. Потому как он выполняется всегда в один поток и зависит от размера файла.У меня конечно 40 серверов сама бакула не обслуживает, только если все вместе взять, но везде для каждого задания указывал пулы вручную и везде указывал время хранения вручную. Даже когда делал схему Disk-to-Disk-to-Tape.
Что же, буду использовать отдельные пулы, убедили. приятно читать такие посты. Большое спасибо!