Собственно из описанияMaximum Concurrent Jobs
максимальное число одновременно подключённых консолей равно 5. Рекомендуется не допускать параллельной записи нескольких заданий в один том - было множество ошибокВ качестве стораджа использую обычные диски в рейде. Так как серверов для бекапа около 30, а full занимает от 100 до 500 Гб, то задание выполняется от 3х до 6 часов. Если разносить по времени, то за выходные не получается сделать full для всех серверов. Разносить по неделям не хотелось бы.
> для реальной параллельности дисковые тома должны лежать в разных каталогах
кто то может поделиться рабочим конфигом. Чтобы один том могло использовать 2-4 джоба одновременно.
P.S.
bacula-5.2.13
А кто запрещает для каждого джоба сделать свой том?
> А кто запрещает для каждого джоба сделать свой том?Это как? Ведь в джобе мы указываем только pool. Или я что то упустил?
>> А кто запрещает для каждого джоба сделать свой том?
> Это как? Ведь в джобе мы указываем только pool. Или я что
> то упустил?Наверное вы упустили что в пуле может быть один том, зато самих пулов- может быть по количеству джобов.
То есть не один пул с одним томом на 500Тб в который ломятся все джобы,а 10000 пулов в каждом из которых по одному тому на 500Гб.
PS:30 серверов по 500Гб.. 15 Тб.. мелкое хранилище какое то...но тем не менее.. при таких объемах данных - имеет смысл подумать о чем нибудь более серьезном..Например Дата Протекторе...
> Наверное вы упустили что в пуле может быть один томс каких это делов? У меня сейчас так
Pool {
Name = DefaultPool
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Volume Retention = 60 days
Maximum Volume Bytes = 10G
Maximum Volumes = 5т.е. в пуле 5 томов каждый по 10Gb. Или мы говорим о разных вещах?
> зато самих пулов- может быть по количеству джобов.это понятно
> То есть не один пул с одним томом на 500Тб в
> который ломятся все джобы, а 10000 пулов в каждом из которых по
> одному тому на 500Гб.да, вот к этому и прихожу. Для каждого клиента в его джобе задавать
Full Backup Pool = Client1_Full
Incremental Backup Pool = Client1_Inc
Differential Backup Pool = Client1_DiffИ каждому пулу задавать свой storage/device. Ну или как минимум, для full один пул, а для diff/inc другой. Так как проблемы с пересечение, думаю, будут только на полных бекапах.
Но как потом все это ротировать ...
> PS:30 серверов по 500Гб.. 15 Тб.. мелкое хранилище какое то...но тем не
> менее.. при таких объемах данных - имеет смысл подумать о чем
> нибудь более серьезном..Например Дата Протекторе...full надо хранить только за последний месяц, так что должно хватать.
>[оверквотинг удален]
> В качестве стораджа использую обычные диски в рейде. Так как серверов для
> бекапа около 30, а full занимает от 100 до 500 Гб,
> то задание выполняется от 3х до 6 часов. Если разносить по
> времени, то за выходные не получается сделать full для всех серверов.
> Разносить по неделям не хотелось бы.
>> для реальной параллельности дисковые тома должны лежать в разных каталогах
> кто то может поделиться рабочим конфигом. Чтобы один том могло использовать 2-4
> джоба одновременно.
> P.S.
> bacula-5.2.13Вообще для bacula зачастую даже один sotrage device это уже как отдельная ленточная библиотека, в которой может быть активна только одна пленка, а пленка это один том.
Для себя данную проблему решил так.
Для каждого задания создаю новый storage.
<code>
Job {
Name = proxy-os
....
Storage = proxy-os-storage
}Storage {
Name = proxy-os-storage
.....
Device = proxy-os-device
Media Type = proxy-os-file
}
</code>Далее создаю Pool такого вида
<code>
Pool {
Name = proxy-os-full
Pool Type = Backup
Volume Retention = 2 month
Maximum Volume Jobs = 1
AutoPrune = yes
Recycle = yes
Recycle Oldest Volume = yes
RecyclePool = proxy-os-full
Action on Purge = Truncate
Label Format = "proxy-os-full-${Year}${Month:p/2/0/r}${Day:p/2/0/r}-${Hour:p/2/0/r}${Minute:p/2/0/r}${Second:p/2/0/r}"
}Pool {
Name = proxy-os-diff
Volume Retention = 1 month
Maximum Volume Jobs = 1
AutoPrune = yes
Recycle = yes
Recycle Oldest Volume = yes
RecyclePool = proxy-os-diff
Action on Purge = Truncate
Label Format = "proxy-os-diff-${Year}${Month:p/2/0/r}${Day:p/2/0/r}-${Hour:p/2/0/r}${Minute:p/2/0/r}${Second:p/2/0/r}"
}Pool {
Name = proxy-os-incr
Pool Type = Backup
Volume Retention = 2 weeks
Maximum Volume Jobs = 1
AutoPrune = yes
Recycle = yes
Recycle Oldest Volume = yes
RecyclePool = proxy-os-incr
Action on Purge = Truncate
Label Format = "proxy-os-incr-${Year}${Month:p/2/0/r}${Day:p/2/0/r}-${Hour:p/2/0/r}${Minute:p/2/0/r}${Second:p/2/0/r}"
}
</code>Ну и сам storage на storage сервере
<code>
Device {
Name = proxy-os-device
Archive Device = /mnt/backup/bacula/proxy-os-storage
Device Type = file
Media Type = proxy-os-file
RemovableMedia = no
Random Access = yes
Block Positioning = yes
LabelMedia = yes
AutomaticMount = yes
Maximum Concurrent Jobs = 50
}
</code>В итоге каждое задание пишет в свой каталог и в свой отдельный сторадж и никак не пересекаются.
Да и удобнее отслеживать бекапы по количеству файлов и тп.
Особенно если есть необходимость копировать полные бекапы на диск и отвозить их в отдельное удаленное хранилище.
Да, вот сейчас сам пришел к такой схеме. Вроде проблем нет. Единственное неудобство - под каждого клиента создавать и описывать свой pool/storage/device, но с учетом что клиентов всего около 30, то можно смириться.P.S.
а влияет ли на что то размер тома? Например если я знаю, что full для данного клиента занимает 100Gb +-20gb, то чтобы хранить 1 бекап + второй на перезаписи мне надо выделить 250Gb под пул. Что будет оптимальнейMaximum Volume Bytes = 25G
Maximum Volumes = 10или просто
Maximum Volume Bytes = 250G
Maximum Volumes = 1Я так понимаю, что размер тома имеет смысл задавать, если затем эти тома будут записывать на dvd, например? Т.е. если у меня все пишется на диск, то особого смысла "разбивать" pool на кусочки (тома) нет?
>[оверквотинг удален]
> пул. Что будет оптимальней
> Maximum Volume Bytes = 25G
> Maximum Volumes = 10
> или просто
> Maximum Volume Bytes = 250G
> Maximum Volumes = 1
> Я так понимаю, что размер тома имеет смысл задавать, если затем эти
> тома будут записывать на dvd, например? Т.е. если у меня все
> пишется на диск, то особого смысла "разбивать" pool на кусочки (тома)
> нет?Я пришел к выводу что не стоит делать в pool много томов. На каждое задание один том. И достаточно. Так легко отслеживать на уровне ФС работу да и другие вещи. Опять же, были случаи когда необходимо было почистить место на сервере резервирования. Если для задания создалось более 1 тома то получается что надо довольно долго сидеть и выяснять какие файлы томов можно удалить а какие нет. А так можно посмотреть какие тома использовались заданием и после удаления задания можно просто удалить и сами файлы томов.
А есть опыт использования 7й ветки? Насколько она стабильна? Собственно интересует только Job Bandwidth Limitation.