Re: timestamp(?) problems with incremental dumps

Lasse Kliemann <[email protected]> wrote:

> Up to now, this always was the case (except for the mtime bug with special 
> files, which is now fixed). Now, as I did test on the faster machine 
> (multi-core Xeon, Linux), things sometimes look differently:
>
> - A file is touched as a timestamp, the snapshot is created, then the dump is 
>   made with `dumpdate=' pointing to the timestamp file:
>
>    Type of this level 3  dump: full
>    Date of this level 3  dump: Thu Sep 13 18:44:40 2007
>    Date of last level 2  dump: Thu Sep 13 18:27:17 2007
>    star: 14266 blocks + 0 bytes (total of 146083840 bytes = 142660.00k).
>
> - The dump is restored to a different filesystem:
>
>    Dump record  level 3  dump: Thu Sep 13 18:44:40 2007 written
>    Validating this dump against restored filesystem...
>    Dump is valid, starting restore.
>    Removing all in 'star-tmpdir'.
>    star: 14266 blocks + 0 bytes (total of 146083840 bytes = 142660.00k).
>
> - Restored version and snapshot are compared:
>
>    diffopts=perm,type,nlink,uid,gid,uname,gname,size,data,rdev,hardlink,
>    symlink,sympath,sparse,mtime,dir,acl,xattr,fflags
>
> (...)
>    var/log/debug: different size,data,mtime
>       8568 -rw-r-----   1 root/adm Sep 13 18:27 2007 var/log/debug
>       8160 -rw-r-----   1 root/adm Sep 13 18:11 2007 var/log/debug
>
> The version of 18:27 is from the snapshot and the version of 18:11 is from the 
> restored version. Note that the level 2 dump is from 18:27:17 (see above).  
> Theory: during the level 3 dump, the file appeared to star as being older than 
> 18:27:17, which meant that it was already included in the level 2 dump (but it 
> in fact was not). Hence it was not included in the level 3 dump and hence, on 
> restore, the old version (from 18:11) was not updated.

How does the file look on the snapshot?

The problem may be that the filesystem does not sync meta data fast enough.


> This looks like typical behavior when the timestamp (later given to star with 
> `dumpdate=') is made *after* the snapshot is created. But that's not how I do 
> it. Maybe it has to do with accuracy? The times in /etc/tardumps seem to only 
> have the accuracy of one second. Then, `sleep 1' between timestamp and snapshot 
> should help. I am doing more tests; results are still to be expected.

The timestamp on /etc/tardumps is using a one microsecond granularity.

If your filesystem does not give a granularity better than one second, this is a
problem of the filesystem.

Jörg

-- 
 EMail:[email protected] (home) Jörg Schilling D-13353 Berlin
       [email protected]                (uni)  
       [email protected]     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily