Понимание Volume Retention, Maximum Volume Bytes и Maximum Volumes
sinaps
Разбираюсь с организацией резервного копирования и испытываю
затруднение с параметрами пула на файловой системе:
Volume Retention
Maximum Volume Bytes
Maximum Volumes
Собственно беспокойство вызывает ожидание ситуации, когда дисковое
пространство будет заполнено и придётся вмешиваться в работу чтобы
освободить часть.
То есть нужно подобрать параметры, когда тома будут ротироваться и
освобождаться своевременно (определить наибольшие необходимые
значения), и при этом что бы не случилось ситуации нехватки нового
тома (минимальные требования).
В статье http://www.ibm.com/developerworks/ru/library/l-Backup_4/
рекомендовано устанавливать значение Maximum Volume Jobs в единицу,
что бы каждое задание резервного копирования шло в отдельный файл. Это
выглядит разумно и с этим параметром всё выглядит понятным. Из этого
так же следует что значение Maximum Volume Bytes можно выставлять
произвольно большим, больше одного задания там всё равно не будет.
Размер же его можно выбирать исходя из объёма самого большого
возможного задания.
На всякий случай, хочется уточнить, если объём бекапа превысит размер
тома, то копирование будет просто продолжено на новый том?
А вот с количеством томов и с периодом их сохранения мне не ясно. Как
правильно подобрать эти значения, что бы с одной стороны тома не
кончались не вовремя. а с другой стороны что бы старые тома не
переполняли накопитель? По видимому при этом нужно исходить из цикла
резервного копирования. Нельзя ли дать какие нибудь рекомендации по
этому поводу? Конечно эти вопросы решаются методом тыка, но если есть
возможность то не хотелось бы впустую тратить время на то, что кому
нибудь уже может быть известно.
rogozhnik...@gmail.com
> А вот с количеством томов и с периодом их сохранения мне не ясно. Как
> правильно подобрать эти значения, что бы с одной стороны тома не
> кончались не вовремя. а с другой стороны что бы старые тома не
> переполняли накопитель? По видимому при этом нужно исходить из цикла
> резервного копирования. Нельзя ли дать какие нибудь рекомендации по
> этому поводу? Конечно эти вопросы решаются методом тыка, но если есть
> возможность то не хотелось бы впустую тратить время на то, что кому
> нибудь уже может быть известно.
Самые большие проблемы вызывают объемные задания, в основном, полного
уровня (full). Мой опыт подсказывает, что нужно:
1) замерить, какой объем займет полный бэкап файлсета (см. estimate в
Bacula Console and Operator's Guide, а также прогнать пробное задание,
если используется сжатие);
2) определиться с политикой копирования, в том числе, сколько будет
храниться полных томов. Если хранится N томов, то нужно иметь в пуле
как минимум на два тома больше (Pool: Maximum Volumes). Один - на
бэкап, чтобы не затирать самый старый из предыдущих на случай ошибки
бэкапа, и как минимум один - для свободы маневра в случае ошибок;
3) установить такие сроки хранения, чтобы "резервные тома" не
понадобились при нормальной работе; например, Volume Retention на
неделю дольше максимального срока хранения по политике, если между
бэкапами проходит примерно месяц (см. пункт 2). В таком случае тома
будут нормально ротироваться без привлечения резерва.
sinaps
On 21 июл, 19:12, "rogozhnikov.and...@gmail.com"
<rogozhnikov.and...@gmail.com> wrote:
> Я в отпуске, поэтому кратко.
>
> > А вот с количеством томов и с периодом их сохранения мне не ясно. Как
> > правильно подобрать эти значения, что бы с одной стороны тома не
> > кончались не вовремя. а с другой стороны что бы старые тома не
> > переполняли накопитель? По видимому при этом нужно исходить из цикла
> > резервного копирования. Нельзя ли дать какие нибудь рекомендации по
> > этому поводу? Конечно эти вопросы решаются методом тыка, но если есть
> > возможность то не хотелось бы впустую тратить время на то, что кому
> > нибудь уже может быть известно.
>
> Самые большие проблемы вызывают объемные задания, в основном, полного
> уровня (full). Мой опыт подсказывает, что нужно:
> 1) замерить, какой объем займет полный бэкап файлсета (см. estimate в
> Bacula Console and Operator's Guide, а также прогнать пробное задание,
> если используется сжатие);
С этим в общем понятно, вопросов быть не может. Это по сути является
началом отсчёта.
> 2) определиться с политикой копирования, в том числе, сколько будет
> храниться полных томов. Если хранится N томов, то нужно иметь в пуле
> как минимум на два тома больше (Pool: Maximum Volumes). Один - на
> бэкап, чтобы не затирать самый старый из предыдущих на случай ошибки
> бэкапа, и как минимум один - для свободы маневра в случае ошибок;
Насколько я понимаю, количество хранимых томов будет зависеть от
сочетания расписания (schedule) с периодом хранения.
Рассмотрим расписание в конфигурации по умолчанию:
Schedule {
Name = "WeeklyCycle"
Run = Full 1st sun at 23:05
Run = Differential 2nd-5th sun at 23:05
Run = Incremental mon-sat at 23:05
}
Здесь описано полное копирование каждое первое воскресенье месяца и
далее дифференциальные и инкрементальные. При использовании такого
расписания хранить резервные копии меньше месяца смысла очевидно нет,
а насколько дольше хранить - определится политикой. Можно для
наглядности рассмотреть случай, когда копии старее месяца не нужны и
их можно удалять, то есть период хранения полностью определяется этим
расписанием.
Но далее у меня возникает сложность. В конфигурации есть три
различных периода хранения: это file, job и volume retentions. Не
очень понятны их отношения и иерархия. Что например будет если файл
записан в том у которого период хранения выставлен меньше чем у файла?
И как сюда относится период для задания?
sinaps
On 25 июл, 12:30, sinaps <a.sinit...@gmail.com> wrote:
> Но далее у меня возникает сложность. В конфигурации есть три
> различных периода хранения: это file, job и volume retentions. Не
> очень понятны их отношения и иерархия. Что например будет если файл
> записан в том у которого период хранения выставлен меньше чем у файла?
> И как сюда относится период для задания?
>
Насколько я понимаю, здесь должно быть простое вложение:
File Retention должен быть меньше чем Job Retention, который в свою
очередь должен быть меньше чем Volume Retention.
Это правильно и каких то упущенных нюансов здесь нет?
Andrey Rogozhnikov
Насколько я понимаю, здесь должно быть простое вложение:
File Retention должен быть меньше чем Job Retention, который в свою
очередь должен быть меньше чем Volume Retention.
Это правильно и каких то упущенных нюансов здесь нет?
Верно.
Хотя технически возможно делать без вложения, то есть, например, File Retention больше Volume Retention. В этом случае при повторном использовании тома из каталога будут также удалены записи о файлах и задачах из этого тома, так как они теряют смысл.
sinaps
On 26 июл, 15:51, Andrey Rogozhnikov <rogozhnikov.and...@gmail.com>
wrote:
> 2011/7/26 sinaps <a.sinit...@gmail.com>
Спасибо.
Прошу посмотреть здесь: http://ru.wikibooks.org/wiki/Bacula/Использование_накопителей
, и если есть поправки то внести.
В частности, интересует правильно ли сказано о кратности срока
хранения расписанию, и можно ли что нибудь заметить о File Retention и
Job Retention.
Yuri Timofeev
> Собственно беспокойство вызывает ожидание ситуации, когда дисковое
> пространство будет заполнено и придётся вмешиваться в работу чтобы
> освободить часть.
Мониторинг свободного места:
http://tim4dev.blogspot.com/2011/08/bacula-and-disk-free-space.html
--
with best regards
sinaps
On 13 авг, 16:30, Yuri Timofeev <tim4...@gmail.com> wrote:
> 21 июля 2011 г. 12:59 пользователь sinaps <a.sinit...@gmail.com> написал:
>
> > Собственно беспокойство вызывает ожидание ситуации, когда дисковое
> > пространство будет заполнено и придётся вмешиваться в работу чтобы
> > освободить часть.
>
> Мониторинг свободного места:http://tim4dev.blogspot.com/2011/08/bacula-and-disk-free-space.html
>
Спасибо, добавил в конце со ссылкой на источник:
http://ru.wikibooks.org/wiki/Bacula/Использование_накопителей
Сам ещё не пробовал, но думаю поставлю, как станет использован
сколько нибудь заметный объём.
Была ещё идея держать накопители в нормальном случае
размонтированными. Но монтировать их в скрипте плохо тем что sd может
быть больше одного, а когда я пытался сказать "автомонтируй" у меня
что-то не вышло. Конечно следовало бы прочесть как это
автомонтирование работает, но думаю что уже не теперь.
Andrey Mylevsky
четверг, 21 июля 2011 г., 13:59:42 UTC+4 пользователь sinaps написал: