Hello,
On 12.10.2005 23:00, Oliver Koch wrote:
Hello,
I have a problem with incremental backups. During an incremental
backup many files a backuped again although they haven't been changed
since the last full backup. Most of the backuped files are located
under /home which is mounted with the following mount options:
/dev/mapper/vg00-lvol6 on /home type ext3
(rw,noexec,sync,usrquota,data=journal)
Does that matter? Are there other reasons which can cause an
incremental backup of a file or directory although there haven't been
any changes?
Usually, there _has_ something changed. Even if you don't see it. What
does stat filename tell you about the timestamps?
Or have you set up different jobs for the different levels?
no there are no different jobs. What can cause a chance of a file? Could
it be a scan of 'quotacheck' or a virus scanner which runs on the /home
filesystem?
Virus scanner could be.
Here is an example for a file which was backuped again although it
should not:
*status client=laigle
Running Jobs:
Director connected at: 12-Oct-05 22:46
JobId 36 Job laigle.2005-10-12_22.00.01 is running.
Backup Job started: 12-Oct-05 22:00
Files=54,994 Bytes=2,504,530,649 Bytes/sec=895,434
Files Examined=321,972
Processing file: /home/mf/profile/NTUSER.DAT
SDReadSeqNo=5 fd=5
====
[EMAIL PROTECTED]:/etc/bacula# ls -la /home/mf/profile/NTUSER.DAT
-rw------- 1 mf senioren 630784 Oct 7 17:46 /home/mf/profile/NTUSER.DAT
[EMAIL PROTECTED]:/etc/bacula# stat /home/mf/profile/NTUSER.DAT
File: `/home/mf/profile/NTUSER.DAT'
Size: 630784 Blocks: 1240 IO Block: 4096 regular file
Device: fd05h/64773d Inode: 4604370 Links: 1
Access: (0600/-rw-------) Uid: ( 1027/ mf) Gid: ( 4100/senioren)
Access: 2005-10-12 22:46:40.000000000 +0200
Modify: 2005-10-07 17:46:17.000000000 +0200
Change: 2005-10-11 23:12:42.000000000 +0200
What file stat options does matter for bacula backups? 'Modify' or 'Change'?
I guess you found the reason, right?
Bacula looks at both st_mtime and st_ctime. From the manual:
mtimeonly=yes|no
If enabled, tells the Client that the selection of files during
Incremental and Differential backups should based only on the st_mtime
value in the stat() packet. The default is no which means that the
selection of files to be backed up will be based on both the st_mtime
and the st_ctime values. In general, it is not recommended to use this
option.
keepatime=yes|no
The default is no. When enabled, Bacula will reset the st_atime
(access time) field of files that it backs up to their value prior to
the backup. This option is not generally recommended as there are very
few programs that use st_atime, and the backup overhead is increased
because of the additional system call necessary to reset the times.
However, for some files, such as mailboxes, when Bacula backs up the
file, the user will notice that someone (Bacula) has accessed the file.
In this, case keepatime can be useful. (I'm not sure this works on Win32).
Note, if you use this feature, when Bacula resets the access time,
the change time (st_ctime) will automatically be modified by the system,
so on the next incremental job, the file will be backed up even if it
has not changed. As a consequence, you will probably also want to use
mtimeonly = yes as well as keepatime (thanks to Rudolf Cejka for this tip).
Kind regards,
Oliver Koch
Arno
--
IT-Service Lehmann [EMAIL PROTECTED]
Arno Lehmann http://www.its-lehmann.de
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
