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