On Thursday 10 July 2008 16:12:56 David Boyes wrote: > > 5. Like the Migration and Copy jobs, the input Pool (from where it > > reads > > > the > > currently backed up data) and the output Pool (where it writes the > > merged > > > data) must be different. This ensures that the job does not attempt > > to > > > read > > and write to the same device, which just will not work. > > 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. 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. > > > However, it is much more likely that you will then continue doing > > incremental > > backups (no more Full or Diffs). At some point later, you want to do > > another > > vbackup to "consolidate" all the Inc backups, and now the process > > fails, > > > because you are going to need to read from Pools P2 (Full produced by > > the > > > vbackup) and P1 (new Incs), and you will attempt to write to P2, which > > will > > not work. > > > > Thus without some other mechanism to move Volumes from Pool to Pool, a > > setup > > like described above won't work, and I suspect this is what will be > > done > > > the > > most frequently (i.e. do only one Full and there after vbackups when > > there > > > are enough Incs to warrant a consolidation). > > 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. > > This is effectively what TSM does, and it works pretty well. It implies > at some point you will need versioning of objects/files if you want to > allow people to go back in time, but I would be OK with the vbackup jobs > being a one-time consolidation without the ability to go back -- I would > use it to get to a "minimum number of tapes to restore" state every so > often. Since it is a backup job, there is always the possibility of going back to a later time. Yes, it could also be used to in a sense make more copies, but then a copy can also do that. ------------------------------------------------------------------------- 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
