Bacula-users

[Bacula-users] Issues in Verify Job

2009-01-29 09:50:58
Subject: [Bacula-users] Issues in Verify Job
From: Olaf Zevenboom <olaf AT artefact DOT nl>
To: bacula-users AT lists.sourceforge DOT net
Date: Thu, 29 Jan 2009 15:48:38 +0100
Dear list,

I have 2 issues when running a verify job. I want to verify data that is 
just written to tape is written ok.
I have defined in director-dir.conf (Bacula 2.4.1 on Debian using Debian 
packages):

JobDefs {
  Name = "DefaultJob"
  Type = Backup
  #Level = Incremental
  Level = Full
  Client = zim-fd
  FileSet = "Full Set"
  Schedule = "WeeklyCycle"
  #Storage = File
  Storage = "DDS-4"
  Messages = Standard
  Pool = Default
  Priority = 10
}

Job {
  Name = "Client_Zim"
  JobDefs = "DefaultJob"
  # Am I allowed to be running at all today?
  RunBeforeJob = /usr/local/sbin/check_vacation.sh
  # Max Wait time: time allowed busy waiting after the time job was 
executed.
  #Max Wait Time = 18h
  Max Wait Time = 10m
  Incremental Max Wait Time = 10m
  # Let's define some Pre job activities:
  ## backup wiki
  RunBeforeJob = /usr/local/sbin/backup_wiki.sh
 
  # Now take care of starting of daemons temporarily shutdown for backup 
porpose
s
  #RunAfterJob =
  Write Bootstrap = "/var/lib/bacula/Client_Zim.bsr"
}

Job {
  Name = "Verify_Zim"
  Type = Verify
  Level = VolumeToCatalog
  Client = zim-fd
  FileSet = "Full Set"
  Messages = Standard
  Storage = "DDS-4"
  Pool = Default
  Schedule = "VerifyCycle"
  Verify Job = "Client_Zim"
}

In the Scheduler there are 3 jobs scheduled:
Client_Zim at 23.10
Verify_Zim at 23.15
Backup_Catalog at 23.20
The server has a single tapeslot drive and jobs wait for each other so 
they are executed in the sequence as defined.

There are 3 issues here.

Issue #1 :
The verify job verifies to the initial Verify job instead of the job 
just finished writing to tape. It does this every night.
Email report says for instance:
27-Jan 23:53 zim-dir JobId 18: Verifying against JobId=4 
Job=Verify_Zim.2009-01-20_23.53.08
27-Jan 23:53 zim-dir JobId 18: Start Verify JobId=18 Level=Catalog 
Job=Verify_Zim.2009-01-27_23.10.44

Yet on the subject of new files it seems to verify against the day 
before and not to the inital verify. (see below)
  Have I made an error in the verify definition?

Issue #2
The verify job reports by mail files all new files. Either files on 
disk(?) and not in the catalog and files that are in the catalog but not 
on disk.
"The following files are in the Catalog but not on disk:"
- files that were created that day: no one touches them on these hours.
  This suggests that a verify is made against yesterdays backup, not the 
just finished backup or the initial verifyjob. Now I am confused.
- This includes the mail being send (tmp file). Excluding the backup of 
/var/lib/bacula where the file is written is not a very beautiful "solution"

Issue #3
Every night the verify job reports on 2 files which are new, while in 
reality these files have been static for years (they are in a CVS 
repository) as CVS is no longer used and the project they are part of is 
no longer further developed. All other files of all projects in CVS do 
not have this issue. SVN is in use at the moment but this project is 
untouched. Details at bottom of this email.


Therefor, by definition, Verify reports: Bacula: Verify Differences of 
zim-fd Verify Catalog.
This makes verify unusable. No one will look at reports like these after 
a while.

Can I make Bacula report just on anomalies? I am not interested in new 
files (new email arriving during backup etc).

Any hints much appreciated,

Olaf


2 files are reported to be new over and over again. using "stat" and 
"md5sum" to see if they are truly static resulted in:

Backup/Verify jobs on 2009-01-26

/home/system/subversion/cvs2svn/home/cvs/CVS/xfabric3/xfabric3/jboss-3.0.0alpha/docs/api/security/org/jboss/security/plugins/class-use#
 
stat JaasSecurityManager.html,v
  File: `JaasSecurityManager.html,v'
  Size: 5085          Blocks: 16         IO Block: 4096   regular file
Device: 905h/2309d    Inode: 35520943    Links: 1
Access: (0444/-r--r--r--)  Uid: ( 1001/  marcel)   Gid: (  200/ cvsuser)
Access: 2009-01-26 23:56:01.000000000 +0100
Modify: 2001-11-24 01:59:20.000000000 +0100
Change: 2005-09-16 19:14:28.000000000 +0200
md5sum: 87d0a1c3ade021fc494f8e88df5e56f3  JaasSecurityManager.html,v

/home/system/subversion/cvs2svn/home/cvs/CVS/xfabric3/xfabric3/jboss-3.0.0alpha/docs/api/connector/org/jboss/resource/connectionmanager/class-use#
 
stat BaseConnectionManager.NoTransactionListener.html,v
  File: `BaseConnectionManager.NoTransactionListener.html,v'
  Size: 5295          Blocks: 16         IO Block: 4096   regular file
Device: 905h/2309d    Inode: 35537362    Links: 1
Access: (0444/-r--r--r--)  Uid: ( 1001/  marcel)   Gid: (  200/ cvsuser)
Access: 2009-01-26 23:56:03.000000000 +0100
Modify: 2001-11-24 01:59:13.000000000 +0100
Change: 2005-09-16 19:14:31.000000000 +0200
md5sum: 64cde259aa4161960bc198115e997884  
BaseConnectionManager.NoTransactionListener.html,v

Backup/Verify jobs on 2009-01-27

/home/system/subversion/cvs2svn/home/cvs/CVS/xfabric3/xfabric3/jboss-3.0.0alpha/docs/api/security/org/jboss/security/plugins/class-use/JaasSecurityManager.html,v'
  Size: 5085            Blocks: 16         IO Block: 4096   regular file
Device: 905h/2309d      Inode: 35520943    Links: 1
Access: (0444/-r--r--r--)  Uid: ( 1001/  marcel)   Gid: (  200/ cvsuser)
Access: 2009-01-27 23:56:59.000000000 +0100
Modify: 2001-11-24 01:59:20.000000000 +0100
Change: 2005-09-16 19:14:28.000000000 +0200
md5sum: 87d0a1c3ade021fc494f8e88df5e56f3

File:
/home/system/subversion/cvs2svn/home/cvs/CVS/xfabric3/xfabric3/jboss-3.0.0alpha/docs/api/connector/org/jboss/resource/connectionmanager/class-use/BaseConnectionManager.NoTransact
ionListener.html,v'
  Size: 5295            Blocks: 16         IO Block: 4096   regular file
Device: 905h/2309d      Inode: 35537362    Links: 1
Access: (0444/-r--r--r--)  Uid: ( 1001/  marcel)   Gid: (  200/ cvsuser)
Access: 2009-01-27 23:57:01.000000000 +0100
Modify: 2001-11-24 01:59:13.000000000 +0100
Change: 2005-09-16 19:14:31.000000000 +0200
md5sum: 64cde259aa4161960bc198115e997884

I checked everything for a few days. As expected this remains as it is.



------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users

<Prev in Thread] Current Thread [Next in Thread>
  • [Bacula-users] Issues in Verify Job, Olaf Zevenboom <=