Hi,
28.05.2009 18:24, Olaf Zevenboom wrote:
> Dear List,
>
> I have a FileSet defined. This FileSet is used by a backup job and a
> verify job. However within this FileSet/Verify job there are some oddities.
> 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 FileSet is defined:
> Verify = pins5
>
> I just want to verify that what was written to tape was written
> correctly. At the time of backup there are no active users however
> daemons such as a MTA continue to work obviously.
>
> I have some question on the following issues.
> a) the verify job seems to verify against jobID 270 which was (I think)
> the last time I ran a Verify Init job. I wanted however to run it
> against the previous backup job (JobId 277). This probably explains
> oddity #4 below.
> What is going wrong here? The catalog is never updated after an Initial
> Verify?
No idea, I'm not a big user of verify jobs. But check the manual
regarding the levels for verify jobs!
> b) Logfiles from daemons are backuped "raw" (without shutting them down)
> in out setup. I know it's not the best way, but anyway... Can I
> configure director in such a way that the backupjob backs up everything
> in the FileSet definition, but does omit certain files/directories when
> verifying without defining an almost identical second FileSet?
> (the fileset definition is complex, changing it might lead to oddities
> in the future when a second FileSet has to be maintained too)
I would add another Include {} section to the fileset (before the
"normal" one!) which only captures the log files, and sets the proper
verify options. Sth. like
Include {
Options {
verify = <whatever you expect to be static - mostly permissions and
user/group id, I guess>
}
File = /var/log/messages
WildFile = /var/log/mail*
RegExFile = /var/log/httpd/.*_(access|error)_log
}
or similar - the above is untested and not even verified against the
manual :-)
> This would probably (partly) fix oddities #1, #2 and #5 below.
>
> c) There are 2 things I simply do not understand at all. Being oddity #3
> below and the strange sequence of chars in the log in oddity #5 below.
>
> Running on Debian Etch Bacula backport packages 2.4.1-1~bpo40+1 against
> MySQL.
>
> Any remarks & suggestions highly welcomed.
>
> Thanks in advance,
> Olaf
>
>
> Oddities:
> -------------
> 1. md5 digest differs on files being in use:
>
> 28-May 00:05 zim-dir JobId 278: File: /var/lib/mysql/bacula/Filename.MYI
> 28-May 00:05 zim-dir JobId 278: st_size differ. Cat: 3275776
> File: 3281920
> 28-May 00:05 zim-dir JobId 278: MD5 digest differs.
If the size differs, the chance that the checsksum matches is quite small.
> 2. New files
Compared against stale catalog information.
> 28-May 00:05 zim-dir JobId 278: New file: /var/lib/cyrus/proc/2315
> 28-May 00:06 zim-dir JobId 278: New file:
> /var/lib/postgresql/8.1/main/base/16388/pg_internal.init
> 28-May 00:23 zim-dir JobId 278: /home/xxx/SUP/xxx/
>
> 3. New files that are not new at all but are reported to be new by all jobs
> (just 2 files, always the same files, other files in the same directory
> are not reported)
Don't know... perhaps new inode numbers (I don't know if that's a
criteria for *this* comparison in a verify job)?
> 28-May 00:07 zim-dir JobId 278: New file:
> /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
> 28-May 00:08 zim-dir JobId 278: New file:
> /home/system/subversion/cvs2svn/home/cvs/CVS/xfabric3/xfabric3/jboss-3.0.0alpha/docs/api/connector/org/jboss/resource/connectionmanager/class-use/BaseConnectionManager.NoTransactionListener.html,v
>
>
> 4. New files that were created during the working day such as log files
> of user applications.
> These are never updated during the backup process as no one works at
> that time.
>
> 5. The following files are in the Catalog but not on disk:
Actually, not astonishing as that file belongs to a process instance
with a specific PID... I wouldn't even back it up as it will be
useless to restore anyway. This is basically the same problem as item
a) in your list.
Arno
> 28-May 00:23 zim-dir JobId 278:
>
> ªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªª0
> 28-May 00:23 zim-dir JobId 278:
>
> ªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªªª0
> 28-May 00:23 zim-dir JobId 278: /var/lib/cyrus/proc/5411
>
--
Arno Lehmann
IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück
www.its-lehmann.de
------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
