> > The key point is that Migration/Copy/vBackup/whatever jobs need to
be
> > able to force the selection of a *different* volume in the specified
> > pool for output, regardless of whether it is the same pool or a
> > different pool. If that capability is available, the scenario you
> > discuss is no longer a problem (and it fixes the ability to
consolidate
> > tapes easily within a pool, as long as there is spare space on *a*
> > volume in the pool different than the one you're reading from).
> 
> Yes, that is clear.
> 
> However, we implemented Migration and Copy using the mechanism you
> specified
> and that is a required specification of the Next Pool so there was no
need
> to
> implement any concept of a "different" volume.

I seem to remember saying in the specification discussion that the Next
Pool value could be the same pool as the source (to permit exactly this
function), but never mind. The point was that the job driving the volume
selection code needs the ability to select a volume from the specified
pool that is not in use by any other Bacula function at the time of
selection. If this becomes possible, then your problem goes away. 

> For migration and copy, it works fine, but for this case,  it doesn't
> work,
> assuming the user wants to do multiple vbackups without manual
> intervention
> from the user as I mentioned and as Alan also mentioned.

See above. The limit of the number of simultaneous vbackups is the limit
of source/output pairs of volumes that can be simultaneously mounted,
which is a function of the number of devices you have available that can
mount the volumes in question. Note that you're likely to also need the
ability to limit the number of devices used for this function to avoid
impacting backup performance (eg use no more than 2 drives for
consolidation, and delay more consolidation jobs until that limit is
satisfied)

> > I would argue that your Vbackup becomes the basis for any future
> > incrementals and the previous jobs are deleted -- think of it as a
> > "bring the base up to *this* point in time, and then start work from
> > there".
> 
> Well, this is a backup job, but it does its work without talking to
the
> client.  However, in other respects it behaves like any backup -- it
does
> not
> delete any previous jobs.

I'm suggesting that this vbackup thing change that behavior to do so. 
I want the consoldated backup to become the only copy. 



-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users