On Thu, 10 Jul 2008, Kern Sibbald 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.

> Well the problem with the above -- principally item #5 is consider the
> following:
>
> You have a job J1, which does a Full, one or more Diff backups, then any
> number of Inc backups all going to Pool P1.  At some point in time (possibly
> via the Schedule), you run a vbackup level, so it finds all the current
> backup files (Full, last Diff, and all later Inc) and copies the data from
> the input Pool (P1) to the output Pool (P2).

Moving the completed job from P2 back to P1 afterwards would take care of
the problem you describe.

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

While it would be cleanest to move volumes from P2 to P1, assuming a 2
drive setup there's nothing stopping you copying the job off P2 onto P1
Volumes, then deleting the P2 Job.

For cases where P2 would be taken offsite or archived in other manners
this kills two birds with one stone. In this case the P2 job would be
retained, but the Full backup record would point to P1

> Any comments?

A Synthetic backup _MUST_ reflect the current state of the filesystem.

IE:

Files which were in previous backups but are now deleted must not be in
the synthetic backup

Files/directory trees which have moved around must also be backed up
accurately.

In many ways this is a subset of accurate restores inasmuch as you want an
accurate picture of the filesystem at time=now, instead of time={Arbitrary
past date} - only this picture is saved to a volume rather than restored
to disk.

Given this, it should be possible to produce a synthetic full backup for
time={Arbitrary past date} too, which may be useful for some purposes.

AB


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