On 9/11/07, Martin Simmons <[EMAIL PROTECTED]> wrote:
>
> >>>>> On Tue, 11 Sep 2007 17:16:23 -1000, Hydro Meteor said:
> >
> > Hello all,
> >
> > >From the User's Guide (Terminology Chapter 1.6), regarding the
> Retention
> > Period, an except that I have a question about:
> >
> > The Volume Retention Period is the minimum of time that a Volume will be
> > > kept before it is reused. Bacula will normally never overwrite a
> Volume that
> > > contains the only backup copy of a file. Under ideal conditions, the
> Catalog
> > > would retain entries for all files backed up for all current Volumes.
> Once a
> > > Volume is overwritten, the files that were backed up on that Volume
> are
> > > automatically removed from the Catalog. However, if there is a very
> large
> > > pool of Volumes or a Volume is never overwritten, the Catalog
> database may
> > > become enormous. To keep the Catalog to a manageable size, the backup
> > > information should be removed from the Catalog after the defined File
> > > Retention Period. Bacula provides the mechanisms for the catalog to be
> > > automatically pruned according to the retention periods defined.
> > >
> >
> > I just want to make sure I understand this sentence:
> >
> > To keep the Catalog to a manageable size, the backup information should
> be
> > > removed from the Catalog after the defined File Retention Period.
> > >
> >
> > The "backup information" that "should be removed" is information about
> any
> > Volume or Pool of Volumes correct?
>
> I think not. Firstly, remember that there are two kinds of information in
> the
> catalog:
>
> - Mostly static stuff about the pools and volumes. This is never pruned
> automatically and you don't generally remove it from the catalog unless
> the
> volumes have been destroyed or you want Bacula to forget about them.
>
> - Dynamic stuff about jobs that have run. This consists of the list jobs
> with
> the media contains them and also a list of the files in each job. The
> Volume, Job and File retention periods control pruning of the dynamic
> information.
>
> The sentence you quoted is talking about the list of the files in each
> job,
> which is almost always the largest part of the catalog.
Hello Martin,
Thank you for the clarification and separating out the mostly static from
the highly dynamic information that is stored in the Catalog (database).
This makes a lot of sense. Indeed, I will not want to purposefully delete
the static info about the volumes and pools (unless as you said they are
destroyed and there is a good reason for Bacula to not remember they exist).
I can understand how therefore its really critical to also back up the
Catalog itself!
Cheers,
-H
> Secondly, what do Bacula users do, strategically, when it comes to
> archiving
> > data into perpetuity? For example, what if a government agency or a law
> firm
> > wanted to use Bacula to back up files to Volumes which Volumes should
> > neverbe overwritten? Of course the Catalog still needs to be pruned,
> > but even so,
> > have I understood correctly that even if a Volume has been pruned out of
> the
> > Catalog, it can later be scanned (using the bscan tool) and data
> extracted
> > (using the bextract tool)? In doing so, no Volumes are ever overwritten
> but
> > they are still recoverable in the future and at the same time the
> Catalog
> > database won't grow to mammoth proportions?
>
> Yes, you are correct about bextract and bscan. However, the Bacula
> terminology "prune" only applies to the job and file information. To
> remove a
> volumes from the catalog, you need to use "delete".
>
> __Martin
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
