Bacula-users

Re: [Bacula-users] allways full even if incremental

2009-09-10 05:03:55
Subject: Re: [Bacula-users] allways full even if incremental
From: Cedric Tefft <logicloop AT gmail DOT com>
To: Troy Daniels <troy.daniels AT itouch.com DOT au>
Date: Thu, 10 Sep 2009 02:00:02 -0700
Troy Daniels wrote:
> Hi,
>
>>>   
>> Actually bacula uses ctime by default, not mtime.
>>
>
> Actually under the 'Level = Incremental' section of the page you 
> linked it states:
>
> "The File daemon (Client) decides which files to backup for an 
> Incremental backup by comparing start time of the prior Job (Full, 
> Differential, or Incremental) against the time each file was last 
> "modified" (st_mtime) and the time its attributes were last 
> "changed"(st_ctime). If the file was modified or its attributes 
> changed on or after this start time, it will then be backed up."
>
> So we were both right almost :)
Fair enough.
>
>> One possibility which occurs to me is that there may be some kind of 
>> time synchronization problem between the director and the client.  I 
>> suspect the problem as described could be a result of the client's 
>> clock being too far ahead of the director's.  I would suggest 
>> verifying the client and director's clocks more or less agree.  This 
>> may be a non-obvious issue if the client and director are in 
>> different time zones -- or, more to the point, if one of them is in 
>> the wrong timezone.
>>
>
> I've seen Bacula compensate for different clock times on servers a few 
> seconds/minutes apart - it logs a line at the top of the job saying 
> it's doing so.
>
Ah, interesting.  I use ntp on all my systems, so I've never seen that 
message.  Anyway, it occurred to me that simply picking a file on the 
client that is getting backed up repeatedly and doing a stat on it might 
be informative if the problem is time or timestamp related:  Stat shows 
you the mtime, ctime, and atime (among other things):

 > stat myfile
  File: `myfile'
  Size: 11603298        Blocks: 22664      IO Block: 4096   regular file
Device: fe03h/65027d    Inode: 810095      Links: 1
Access: (0644/-rw-r--r--)  Uid: (  500/  cedric)   Gid: (  500/  cedric)
Access: 2009-08-19 23:04:07.000000000 -0700
Modify: 2002-02-09 04:55:02.000000000 -0700
Change: 2009-08-19 23:04:07.721728624 -0700

In particular, doing a stat on the same file immediately before, and 
again immediately after a backup might reveal something.

- Cedric





------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users