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-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
