Организация конфига директора в бакуле
За время работы с ней выработал для себя некоторые правила организации конфига, поскольку тот со временем имеет тенденцию скатываться в треш и угар.
Основной принцип - не хранить всё в одном файле. Если существует хотя бы 2 однотипных куска конфига - они выносятся в отдельные файлы и подключаются в основной. Иначе очень скоро получим кашу.
Ну и следует следить за тем, чтобы эти "вынесенные" куски было возможно использовать больше одного раза. Например, если в 90% случаев у нас период хранения файлов составляет 2 месяца - задайте его в jobdefaults вместо самого задания1.
Некоторые особенности наименования:
# clients
@"/usr/local/etc/bacula/clients/$FQDN1-fd.conf"
@"/usr/local/etc/bacula/clients/$FQDN2-fd.conf"
@"/usr/local/etc/bacula/clients/$FQDN3-fd.conf"
...
# jobs
@"/usr/local/etc/bacula/jobs/$FQDN1/$fileset1.conf"
...
Или в пседографике:
bacula/
`-.
+-> clients/
| |-> $hostname1.conf
| `-> $hostname2.conf
+-> filesets/
| |-> fileset1.conf
| `-> fileset2.conf
+-> pools/
| `-> default-$time.conf # $time - retention time
+-> schedules/
| |-> $F-$I-$D.conf # $F, $D, $I - time specication, as [FDI][0-9][dwmy]
| `-> $F-$I.conf # F - Full, I - Incr, D, Diff; d - day, w - week, m - month, y - year
| # F3m-I1w - "backup Full each 3 month and Incremental each week"
+-> jobs/
| |-> $hostname1/
| | `-> $fileset1.conf
| `-> $hostname2/
| |-> $fileset1.conf
| `-> $fileset2.conf
...
`-> bacula-dir.conf
Дополнение из 2016го года
В процессе использования этой схемы, я внёс в неё несколько изменений:
jobdef'ы, расписания, пулы, описания стораджей лучше хранить в одном файле:
@"/etc/bacula/includes/pools.conf" @"/etc/bacula/includes/schedules.conf" @"/etc/bacula/includes/storages.conf" @"/etc/bacula/includes/jobdefs.conf" и т.д.
job'ы лучше хранить вместе с клиентами, без описания клиентов они не имеют смысла
- специфические fileset'ы тоже лучше хранить вместе с клиентами. Реиспользуемые - в отдельном. У этого типа блока достаточно большой объём.
на правах КО ↩