On Thursday 10 July 2008 16:45:22 David Boyes wrote:
> > > 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.

I think that could be done as a special option to the Migration code.

-------------------------------------------------------------------------
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