On Thursday 10 July 2008 15:52:59 Alan Brown wrote:
> 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.

I'm not planning to add that restriction.

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

Both those items depend on the user having specified Accurate in previous 
backups.  We've discussed this before.

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

I don't understand the above comment.



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

Yes, but I am not planning any provision for this since these jobs will almost 
certainly be run automatically rather than manually.


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