Re: [Bacula-users] Concurrent Jobs again

[Karl C. <ka...@ke...>]

--On Wednesday, December 17, 2003 11:23 AM +0100 Kern Sibbald
<ke...@si...> wrote:

> On Sat, 2003-12-13 at 00:31, Karl Cunningham wrote:
>> I'm testing concurrent jobs backing up different machines, and have come
>> across something I didn't expect.  I'm backing up to hard disk and want
>> each machine's backup to go into its own volume.
>> 
>> All jobs use one pool resource, shown below.  When a job is started, it
>> creates a new volume and writes to it.  If another job starts before the
>> first one finishes, it writes to the same volume instead of creating a
>> new one.  It appears concurrent jobs all write to the same volume; which
>> was named according to the job that created it (the first job to run).
>> If I let all concurrent jobs complete before starting a new job, a fresh
>> volume is created for the new job.  I thought that since Maximum Volume
>> Jobs=1, a new volume would be created for every job that starts
>> (concurrent or not). Am I all wet?
> 
> This is probably an "oversight", or bug if you want, in multiple
> concurrent jobs, and your problem occurs because the Volume information
> is only updated at the end of the job. In version 1.33 the Volume
> information is updated when anything important occurs.  However, I think
> you will still have problems as for this to work the number of jobs
> would have to be updated in the Volume record before the second job
> "starts".
> 
> I've added this to my todo list. Please don't expect a quick fix for
> this.
> 
> Many thanks for reporting it.


Kern --

Thanks for the reply.  I don't expect anything at all, and I really
appreciate your efforts on this great program.  I'd would like to put in my
two cents for a time when you might have a chance to look at this again...

My backups are only to hard disk these days, in removable bays. This is my
idea of how a backup to hard disk would work more smoothly. Some of these
things Bacula does already, but I mention them for completeness. If others
have better ways to do this, I'd like to hear about it.

1. Accommodate several disks, rotated similar to how tapes are.  Identified
by partition volume ID or perhaps by the name of a subdirectory.
2. Abort & notify the admin if the wrong disk is in the bay.
3. Write backups to different subdirectories for each machine to be backed
up.
4. Volumes (files) get created as needed in the proper subdirectory, one
for each backup.
5. When a disk is recycled, remove or zero all old backup files. This is
important as the disk being recycled may be close to full. This may be
better done manually since the backup files for many machines may be
scattered in many subdirectories.

Tnanks again.

Karl Cunningham