Sorry to keep flooding the list...but I live for this stuff>:}

Situation:

1) I have multiple servers, different platforms, different functions
2) Some servers have common paths to be backed up (/etc, /var/log, etc.)
3) Some have platform/function-specific paths: (/var/adm, /opt/oracle)
4) A "Job" can only define one "fileset"
5) Per the manual: "If you want to backup multiple FileSets on the same
   Client or multiple Clients, you must define a Job for each one."
6) Multiple "Jobs" can be assigned to the same schedule
7) Multiple "Jobs" can be assigned to the same storage medium
8) Thus, multiple jobs could be started in sequence/parallel 

As an Amanda user, I'm accustomed dot a 1:1:1:1? ratio of 
 ...  media/storage:schedule:clients:paths.  I'm accustomed to the idea
that the job will start, fetch all of the files in the "disklist" to a
local disk spool, then write them to a single volume.

Now I have to bring my thinking back into alignment with Bacula.

The bacula-dir.conf syntax is perpetually more convenient.  I like the
abstraction between jobs/schedules/filesets/clients.  It's resembles
data modeling of an RDBMS.  Therein, ideally I don't want to have to
define

... a "file set" for 
... for each client
.... for each job.

Because that just leads to duplication and lack of flexibility.
However, Per #8 above, I'm trying to setup:

 two jobs...
  same client...
   different filesets
    same schedule       
     same DefJobs
      and thus the same schedule/pool/storage
        
the same might apply to:
  four jobs
   two clients
    one shared fileset
     one client-specific fileset per 
      same schedule
       same DefJobs

But in either configuration, the jobs launch at the same time in the
scheduler and run in series/serial.  Thus, if the database is purged,
and each job is configured as incremental, and there is no record of a
full backup, each job is promoted to Full, so the first job runs
completes, then asks for the next tape in the pool.

This is not the expected behavior (imho).  I'd expect it to consolidate
all jobs that are schedule to run at the same time, with the same
storage, same pool, same priority, to the same volume.

TIA,
~lava
   

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to