Bacula-users

Re: [Bacula-users] What causes orphaned Path/Files in database?

2008-10-16 15:03:26
Subject: Re: [Bacula-users] What causes orphaned Path/Files in database?
From: Hemant Shah <hjrrs AT yahoo DOT com>
To: baculausers <bacula-users AT lists.sourceforge DOT net>, mark.bergman AT uphs.upenn DOT edu
Date: Thu, 16 Oct 2008 11:59:59 -0700 (PDT)

--- On Thu, 10/16/08, mark.bergman AT uphs.upenn DOT edu <mark.bergman AT 
uphs.upenn DOT edu> wrote:

> From: mark.bergman AT uphs.upenn DOT edu <mark.bergman AT uphs.upenn DOT edu>
> Subject: Re: [Bacula-users] What causes orphaned Path/Files in database?
> To: "baculausers" <bacula-users AT lists.sourceforge DOT net>
> Date: Thursday, October 16, 2008, 11:53 AM
> In the message dated: Thu, 16 Oct 2008 10:08:07 +0200,
> The pithy ruminations from Arno Lehmann on 
> <Re: [Bacula-users] What causes orphaned Path/Files in
> database?> were:
> => Hi,
> => 
> => 16.10.2008 04:14, Hemant Shah wrote:
> => > 
> => 
> => > --- On Wed, 10/15/08, Arno Lehmann
> <al AT its-lehmann DOT de> wrote:
> => ...
> => > Thanks for the explanation, I will setup a cron
> job to run dbcheck.
> => 
> => I would be careful with a cron job... basically, as
> the dbcheck 
> => 
> => process can take a long time and locks the database,
> it can result in 
> => 
> => backups not running as scheduled.
> 
> A very good point.
> 
> In our environment, dbcheck takes about 3 days to run. The
> catalog is about 
> 21GB, and the server is a dual-proc 3.2GHz, 32-bit machine
> with 12GB of RAM, 
> running bacula 1.38.11 and MySQL 5.?.

  I am using PostgreSQL and database is 11GB. It only took 10-15 minutes to run 
dbcheck.

 The server has 2.0 GHz dual core Xeon and 4GB RAM. It runs 64-bit Fedora 9 and 
PostgreSQL is also 64-bit.

 
> 
> => 
> => It's better, in my opinion, to just add the
> dbcheck to your list of 
> => 
> => things to do during maintenance periods. You usually
> don't need to run 
> => 
> => it more often than a few times a year, too, so if you
> choose to do 
> => 
> => that via cron, you should schedule it to a time where
> no backups run, 
> => 
> => and only run it monthly or even less often.
> 
> Hmmm... Do you know if the time to run dbcheck is
> proportional to the number of
> catalog entries (the database size), or the number of
> orphaned entries? If it's
> the former, than I'd agree that running dbcheck
> infrequently (during a
> maintenance interval) is a good idea. However, if the time
> to run dbcheck is
> proportional to the number of orphaned entries, then
> perhaps it should be run
> much more often.
> 
> As far as running dbcheck when no backups are active,
> I'd suggest running it via
> the "RunAfterJob" directive in the BackupCatalog
> job. You could write a wrapper
> to dbcheck that looks for the presence of a file, such as:
> 
>       if [ -f /etc/run_dbcheck ] ; then
>               dbcheck ..... && rm -f /etc/run_dbcheck
>       fi
> 
> so that the RunAfterJob can execute after every backup, but
> the dbcheck is only 
> executed if the "/etc/run_dbcheck" file was
> manually created in advance.
> 
> 
> Mark
> 
> => 
> => Arno
> => 
> => > Hemant Shah
> => > E-mail: hjrrs AT yahoo DOT com
> => > 
> => 
>       [SNIP!]
> 
> => 
> => Arno Lehmann
> => IT-Service Lehmann
> => Sandstr. 6, 49080 Osnabr=FCck
> => www.its-lehmann.de
> 
> [SNIP!]
> 
> ----
> Mark Bergman                              voice:
> 215-662-7310
> mark.bergman AT uphs.upenn DOT edu                 fax:
> 215-614-0266
> System Administrator     Section of Biomedical Image
> Analysis
> Department of Radiology            University of
> Pennsylvania
>       PGP Key: https://www.rad.upenn.edu/sbia/bergman 
> 
> 
> 
> 
> The information contained in this e-mail message is
> intended only for the personal and confidential use of the
> recipient(s) named above. If the reader of this message is
> not the intended recipient or an agent responsible for
> delivering it to the intended recipient, you are hereby
> notified that you have received this document in error and
> that any review, dissemination, distribution, or copying of
> this message is strictly prohibited. If you have received
> this communication in error, please notify us immediately by
> e-mail, and delete the original message.
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK
> & win great prizes
> Grand prize is a trip for two to an Open Source event
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Bacula-users mailing list
> Bacula-users AT lists.sourceforge DOT net
> https://lists.sourceforge.net/lists/listinfo/bacula-users



Hemant Shah
E-mail: hjrrs AT yahoo DOT com



      

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users