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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
