[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bacula-devel] Accurate Incremental backup problem


On Wednesday 24 September 2008 11:52:41 Ulrich Leodolter wrote:
> Hi,
> I looks like Accurate Incremental backups work not like expected.
> I am using current bacula trunk, last update 2008-09-16.
> No config changes since last update.
> Below is a Job list where i tried to track down the problem.
> On Monday Sep 22 i did a system update (apt-get), so 20794 Files are ok for
> Job 3637. But i did not make major changes on Sep 23, so 21725 Files for
> Job 3669 are not expected!
> JobId JobName Status Level Client Pool StartTime EndTime Duration Files
> Bytes 3574 Backup-leodolter OK F leodolter-fd DiskBackup 08-Sep-21 02:05
> 08-Sep-21 02:26 00:21:45 178,917   4.5 GB 3605 Backup-leodolter OK I
> leodolter-fd DiskBackup 08-Sep-22 02:05 08-Sep-22 02:06 00:01:27     202 
> 13.3 MB 3637 Backup-leodolter OK I leodolter-fd DiskBackup 08-Sep-23 02:05
> 08-Sep-23 02:07 00:02:34  20,794 187.6 MB 3669 Backup-leodolter OK I
> leodolter-fd DiskBackup 08-Sep-24 02:05 08-Sep-24 02:07 00:02:42  21,725
> 192.6 MB
> Now i looked at some special file /usr/bin/wget (see mysql select below)
> As far as i can see only st_atime (11'th field in LStat) changed from 23
> Sep (JobId 3637) to 24 Sep (JobId 3669).
> Until now i thought st_atime is not used for Accurate backups.

To the best of my knowledge, st_atime is not used by Bacula to make any 
decision whether or not to backup the file.  The tests are strictly against 
st_mtime and st_ctime (depending on how you configure Bacula).

It sounds to me like you have a problem of an anti-virus program that 
is "touching" some files or some other change to your system happened.
Running verify InitCatalog, then later Catalog can verify this ... 

> For me i looks like Accurate Incremental backups are always made against
> last Full while ignoring previous Accurate Incremental jobs (maybe i am
> completely wrong)

I haven't taken a careful look at all the details you presented above, but 
Accurate works very much like existing backups -- that is it looks at 
st_mtime and st_ctime (if I am not mistaken), and if the file needs to be 
backed up for the "normal" backup reasons, it will be.  What Accurate does is 
in *addition* to the "normal" rules, it will check to see if a file has been 
deleted or has been added with an old date, and in those cases, it ensures 
that files that are deleted are so marked, and any file that is missed by the 
normal backup will also be backed up.

I'll let Eric confirm this.

If it is not working like I described above, then please let me know and we 
can look at it in more details.

Best regards,


> mysql> select File.JobId, Filename.Name,Path.Path,File.LStat,File.MD5 from
> File join Filename using (FilenameId)
>   join Path using (PathId)
>  where File.JobId in (3574,3605,3637,3669) and Filename.Name = 'wget';
> +-------+------+-----------+-----------------------------------------------
> | JobId | Name | Path      | LStat                                         
> |             | MD5                         |
> +-------+------+-----------+-----------------------------------------------
> |  3574 | wget | /usr/bin/ | P4A HEEh IHt B A A A 3PU BAA HI BIz28l BIaVNu
> | BIfhPi A A E | 8dz2rHajxE25WMWnQ2U6DUja/MI | 3637 | wget | /usr/bin/ |
> | FyVUN2j34bKjITbKF5khOovbiGs | 3669 | wget | /usr/bin/ | P4A HECd IHt B A
> | A A 3PU BAA HI BI2DL7 BIxGDt BI11Hr A A E | FyVUN2j34bKjITbKF5khOovbiGs |
> +-------+------+-----------+-----------------------------------------------
>-------------+-----------------------------+ 3 rows in set (0.00 sec)
> Please have a look at this
> Thanks

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
Bacula-devel mailing list

This mailing list archive is a service of Copilot Consulting.