[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] Vbackup feature
On Thursday 10 July 2008 16:12:56 David Boyes wrote:
> > 5. Like the Migration and Copy jobs, the input Pool (from where it
> > the
> > currently backed up data) and the output Pool (where it writes the
> > data) must be different. This ensures that the job does not attempt
> > 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
> > because you are going to need to read from Pools P2 (Full produced by
> > 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
> > the
> > most frequently (i.e. do only one Full and there after vbackups when
> > 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
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
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
This mailing list archive is a service of Copilotco.