планирование
sinaps
Пытаюсь спланировать бекап но немного путаюсь. Хочется разобрать общий случай, что бы, в случае необходимости вернуться к теме через полгода, не нужно было мучительно вспоминать "как же это оно тут всё работает".
Думаю хранить в течении недели суточные копии, в течении месяца недельные, и в течении года ежемесячные. Это разумно или на инкрементах много не сэкономишь? Да, понимаю что инкременты могут быть разные, но хочется оглядываться на распространённый случай.
Если применять такой план то, насколько я могу видеть, разделить эти три случая можно можно только сохраняя их в разные пулы и указанием соответственного периода хранения для каждого пула.
В случае с одним расписанием, где делаются раз в сутки - инкремент, раз в неделю - декремент и раз в месяц - полный бекап мы как раз получаем соответствующий набор. Но я не вижу как можно их разделить по разным пулам. Насколько я понимаю, для такого разделения придётся использовать три разных задания с разными расписаниями? Тогда видимо не получится для инкремента в одном задании использовать как начало отсчёта полный бекап из другого задания и получится повторное копирование одного и того же.
Решаема ли такая задача или лучше так не планировать?
rogozhnik...@gmail.com
sinaps
sinaps
в задании:
Full Backup Pool = Full-Pool
Incremental Backup Pool = Inc-Pool
Differential Backup Pool = Diff-Pool
которые и распределяют копирование по пулам. Описание для этих
параметров я нашёл здесь: http://bacula.org/5.0.x-manuals/en/main/main/Configuring_Director.html
Но здесь возникает и ещё одно желание, распределить их также по разным
накопителям. В моём случае это разные винчестеры с разной надёжностью,
а в общем случае можно сочетать диски с лентами например складывая на
вторые долговременные архивы а на первые короткоживущие. Но судя по
всему для storage в секции job таких изысков уже не предусмотрено?
Или я не нашёл?
Andrey Rogozhnikov
Таки не нашли. В мануале по ссылке говорится, что Storage должен быть определен хотя бы в одном из ресурсов - Job или Pool. Storage в Job имеет приоритет над пулом, но если его не указывать, то можно в каждом пуле приписывать разные хранилища и тем самым решить задачу (секции The Job Resource и The Pool Resource).
Хотя лично мне кажется, что если разговор идет о винчестерах (для бэкапов!) с разной надежностью, то надежность всей системы оказывается равна надежности самого "плохого" винчестера. Следовательно, такие диски лучше вообще исключить ради собственного спокойствия.
--
С уважением,
Андрей Рогожников mailto:rogozhnik...@gmail.com
sinaps
On 6 авг, 09:54, Andrey Rogozhnikov <rogozhnikov.and...@gmail.com>
wrote:
> 2011/8/6 sinaps <a.sinit...@gmail.com>
> > Насколько я понял, такое поведение определяется следующими параметрами
> > в задании:
>
> > Full Backup Pool = Full-Pool
> > Incremental Backup Pool = Inc-Pool
> > Differential Backup Pool = Diff-Pool
>
> > которые и распределяют копирование по пулам. Описание для этих
> > параметров я нашёл здесь:
> >http://bacula.org/5.0.x-manuals/en/main/main/Configuring_Director.html
>
> > Но здесь возникает и ещё одно желание, распределить их также по разным
> > накопителям. В моём случае это разные винчестеры с разной надёжностью,
> > а в общем случае можно сочетать диски с лентами например складывая на
> > вторые долговременные архивы а на первые короткоживущие. Но судя по
> > всему для storage в секции job таких изысков уже не предусмотрено?
>
> > Или я не нашёл?
>
> Таки не нашли. В мануале по ссылке говорится, что Storage должен быть
> определен хотя бы в одном из ресурсов - Job или Pool. Storage в Job имеет
> приоритет над пулом, но если его не указывать, то можно в каждом пуле
> приписывать разные хранилища и тем самым решить задачу (секции The Job
> Resource и The Pool Resource).
>
Спасибо. У меня теплилась надежда :)
> Хотя лично мне кажется, что если разговор идет о винчестерах (для бэкапов!)
> с разной надежностью, то надежность всей системы оказывается равна
> надежности самого "плохого" винчестера. Следовательно, такие диски лучше
> вообще исключить ради собственного спокойствия.
>
С этим всё просто.
Можно складывать полные резервные копии на хороший винчестер и на
долгий срок, а инкрементными добивать тот, которому уже недолго
осталось. Вероятность того что одновременно понадобится бекап и
откажет накопитель не очень большая, но если это случится то самое
худшее что ждёт - последний бекап окажется чуть старее. Но смарт никто
не отменял и по идее он должен дать о себе знать заблаговременно.
В случае же с совмещением лент (впрочем, это уже не мой случай) и
дисков мне кажется разделить полные бекапы на ленты а инкрементные на
диски тоже может быть разумным. Насколько я понимаю, как бы ни были
хороши ленты - чем меньше их механически гонять тем дольше они будут
жить, тогда как для дисков постоянная перезапись это уже скорее
нормально.
И чтоб два раза не вставать, по поводу БД (дамп sql): я правильно
понимаю что в их случае инкрементные копии не имеют смысла,
оказываются такими же полными?
Собственно для того что бы организовать такое же расписание хранения
видимо нужно будет просто использовать такую же схему, при этом все
бекапы фактически будут полными но согласно названию (D, I) они
разложатся по пулам на соответственные периоды.
Сергей
Andrey Rogozhnikov
И чтоб два раза не вставать, по поводу БД (дамп sql): я правильно
понимаю что в их случае инкрементные копии не имеют смысла,
оказываются такими же полными?
Да, так как файл дампа оказывается изменившимся при каждом бэкапе.
Собственно для того что бы организовать такое же расписание хранения
видимо нужно будет просто использовать такую же схему, при этом все
бекапы фактически будут полными но согласно названию (D, I) они
разложатся по пулам на соответственные периоды.
Так как дамп каталога все равно оказывается полным бэкапом, то нет смысла заводить для него инкременты.
sinaps
On 6 авг, 18:11, Andrey Rogozhnikov <rogozhnikov.and...@gmail.com>
wrote:
> 2011/8/6 sinaps <a.sinit...@gmail.com>
> > Собственно для того что бы организовать такое же расписание хранения
> > видимо нужно будет просто использовать такую же схему, при этом все
> > бекапы фактически будут полными но согласно названию (D, I) они
> > разложатся по пулам на соответственные периоды.
>
> Так как дамп каталога все равно оказывается полным бэкапом, то нет смысла
> заводить для него инкременты.
>
Наверно я неправильно выразился.
Хочется использовать ту же схему: неделю ежедневный, месяц
еженедельный и дольше ежемесячный. Но для этого я пока знаю только
один приём: разделить на инкрементальные, декрементальные и полные.
Специфика БД видимо скажется только в том, что при разных названиях
они все фактически будут полными, но желаемое расписание хранения
должно получиться.
Andrey Rogozhnikov
> > Собственно для того что бы организовать такое же расписание храненияНаверно я неправильно выразился.
> > видимо нужно будет просто использовать такую же схему, при этом все
> > бекапы фактически будут полными но согласно названию (D, I) они
> > разложатся по пулам на соответственные периоды.
>
> Так как дамп каталога все равно оказывается полным бэкапом, то нет смысла
> заводить для него инкременты.
>
Хочется использовать ту же схему: неделю ежедневный, месяц
еженедельный и дольше ежемесячный. Но для этого я пока знаю только
один приём: разделить на инкрементальные, декрементальные и полные.
Специфика БД видимо скажется только в том, что при разных названиях
они все фактически будут полными, но желаемое расписание хранения
должно получиться.
Мне кажется, что написать отдельный ресурс Schedule для бэкапа каталога не будет большой проблемой.
sinaps
On 6 авг, 20:42, Andrey Rogozhnikov <rogozhnikov.and...@gmail.com>
wrote:
> > Хочется использовать ту же схему: неделю ежедневный, месяц
> > еженедельный и дольше ежемесячный. Но для этого я пока знаю только
> > один приём: разделить на инкрементальные, декрементальные и полные.
> > Специфика БД видимо скажется только в том, что при разных названиях
> > они все фактически будут полными, но желаемое расписание хранения
> > должно получиться.
>
> Мне кажется, что написать отдельный ресурс Schedule для бэкапа каталога не
> будет большой проблемой.
>
Да, конечно не проблема. Собственно бекап каталога бакулы задан в
конфигурационных файлах по умолчанию, и для любой другой базы данных
его легко взять за основу.
То что меня здесь задержало - это повторение странного расписания
хранения. Хочется найти компромисс между занимаемым местом и частотой
копий. И здесь хорошо выглядит рассмотренная, и описанная в Main
Reference Guide, схема, когда свежие копии хранятся все, а чем старее
- тем реже.
С дампом базы данных правда от инкрементов остаётся только название,
но по крайней мере остаётся возможность прореживать копии по мере
старения.
В общем, ещё раз спасибо.