At a customer I am still in the process of introducing Bacula:
configuring Clients, Jobs, FileSets, Schedules.
My approach is to at first get everything covered (dumps on tape at
first), then start optimizing.
So I started with the default JobDef and modified it:
JobDefs {
Name = "DefaultJob"
Type = "Backup"
Level = "Incremental"
Messages = "Standard"
Storage = "LTO7-Storage"
Pool = "Default"
Client = "pbs-fd"
Fileset = "Full Set"
Schedule = "WeeklyCycle"
WriteBootstrap = "/var/lib/bacula/%c.bsr"
SpoolAttributes = yes
SpoolData = yes
Priority = 10
}
So more or less every job uses that, which in turn uses the schedule
WeeklyCycle (modified a bit, not much).
Now that site has some huge clients to backup.
I see jobs taking 15, 17 or 20 hours to finish (for FULL). If I run
these every week, everything gets stuck ... too many jobs, too slow ...
There are rather "static jobs" (for example fileshares with stuff from
earlier years that don't change much or anymore) that are huge.
I have around 20 LTO-7 tapes to use there, and should have at least one
FULL on one tape at all times.
The more dynamic (and smaller) jobs should run a FULL every weekend, for
example.
What I currently struggle with:
I could set up a second schedule and modify the jobs for these more
static shares to (for example) only do a full every 6 weeks or so.
Or I could add a second JobDef (also?) with separate schedule and lower
prio?
I aim for the most elegant way to configure this and avoid having to
remember modifications in dozens of jobs.
I'd like to avoid 2 pools because of the limited number of tapes.
To me it looks like:
second JobDef "DynamicJob" with separate Schedule, right?
And then go through the smaller Jobs and assign that Def.
hints very welcome, I think too complicated very likely.
thanks in advance, Stefan
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users
