On Monday 20 August 2007 17:00, Alan Brown wrote:
> On Mon, 20 Aug 2007, Kern Sibbald wrote:
> >> To my mind, these pretty much all use the same code inasmuch as one is
> >> wanting to generate a new full backup to tape (or restore to disk) based
> >> on what's in the database and in the volumes for any given backup date,
> >> while weeding files which had been deleted before that date, but since
> >> the previous backups (full/differential/incremental)
> >>
> >> In other words, solving either of #1 or #3 should pretty much
> >> automatically solve the other.
> >
> > I can see how one might think what you write is so, but in reality the
> > two projects are quite distinct and don't really involve any common code.
> >  Item 3 (merge of multiple backups) is simply a restore bootstrap file as
> > input a migration (or copy) job, which is a rather small to moderate
> > addition to the current code.  The process doesn't involve the FD at all.
>
> No it doesn't, but a synthetic full backup will also need to take account
> of which files have been deleted when creating the new backup set on
> Bacula volumes.
>
> > Item 1 is a very complex problem that has serious performance
> > implications depending on how it is implemented particularly for the FD,
> > and is a major addition to the current code. Probably the best solution
> > that scales is to push the work out to the client (FD).  However, doing
> > so risks to overrun the capacities of the FD.  The project involves
> > sending a full and accurate state of the Client as known in the Bacula
> > catalog to the client, which would then reference this information
> > (potentially very large) when backing up files.
>
> You will need this information to get accurate synthetic full backups
> anyway, else that backup is likely to contain significant numbers of files
> which no longer exist on the filesystem at the timestamp the synthetic
> backup is made.

Yes, I agree, with what you say.

However the synthetic backup is not dependent on having information about 
deleted files.  The synthetic backup will simply take what is in the catalog 
an run with it.  At the current time, no information about deleted files 
exists in the catalog.  Once project #1 is implemented, it will exist.  So 
once the deleted files info is in the catalog, the bootstrap files produced 
will be automatically handled by the low level code that creates the 
bootstrap files.

>
> > This project has certain aspects in common with Item 7 "Implement Base
> > jobs", which also must have a full and accurate state of the catalog at
> > the disposal of the Client.
>
> Wholly agreed.
>
> AB

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to