Erik Hjertén wrote:

> Matthias Meyer skrev:
>>
>>> -----
>>> incr backup started back to 2009-06-13 10:59:37 (backup #341) for
>>> directory data Connected to eddie:873, remote version 29
>>> Negotiated protocol version 28
>>> Connected to module data
>>> Sending args: --server --sender --numeric-ids --perms --owner --group -D
>>> --links --times --block-size=2048 --recursive -D . . Checksum seed is
>>> 1244886594 Got checksumSeed 0x4a337642
>>> Got file list: 11348 entries
>>> Child PID is 13925
>>> Xfer PIDs are now 13925
>>> Sending csums, cnt = 11348, phase = 0
>>>   create d 700 4294967295/4294967295        4096 .
>>>   create d   0 4294967295/4294967295           0 2c8
>>>   create d 700 4294967295/4294967295           0 2c8/Bliwa
>>>   create d 700 4294967295/4294967295           0 2c8/Bliwa/data
>>>   create d 700 4294967295/4294967295           0 2c8/Bliwa/data/log
>>>   pool     700 4294967295/4294967295          48
>>>   2c8/Bliwa/data/log/log.ctrl
>>>   pool     700 4294967295/4294967295     1048576
>>>   2c8/Bliwa/data/log/log3.dat
>>>   pool     700 4294967295/4294967295          48
>>>   2c8/Bliwa/data/log/logmirror.ctrl
>>>   create d 700 4294967295/4294967295       81920 2c8/Bliwa/data/seg0
>>>   pool     700 4294967295/4294967295        8192
>>>   2c8/Bliwa/data/seg0/c10.dat
>>> ...
>>> -----
>>>
>>>
>>>     
> 
>>> Also noticeable is the line: "incr backup started back to 2009-06-13
>>> 10:59:37 (backup #341) for directory data" above. Does this mean this
>>> run, 342, is "compared" to 341?
>>>     
>> Yes
>>   
>>> And if so, would that explain this behaviour?
>>>     
>> What do you mean?
>>   
> My thought here was that the files not backed up in run 341 was instead
> backed up in run 342 just because they weren't in 341 and not because
> any attribute has changed. My intuition told me that an incremental run
> should be compared to the latest full, and not the latest incremental as
> it seems in this case. That's why I reacted to this line in the log.
>>> Skipped files in 341 is marked "pool" in 342.
>>>     
>> You are sure that nothing was changed at this file(s) (timestamps,
>> attributes, owner)?
>> e.g.   pool 700 4294967295/4294967295  48 2c8/Bliwa/data/log/log.ctrl
>> have    access-rights 700
>>         owner 4294967295
>>         group 4294967295
>>         size 48 bytes
>>   
> Yes. Same file from 341:
> 
> skip     700 4294967295/4294967295          48 2c8/Bliwa/data/log/log.ctrl
> 
> And I think also it's not very likely that all files have changed that
> wasn't backed up in the last run.
> 
>> Do you use --time as rsyncd parameter?
>>   
> Yes, if you mean --times, see head of log example above.
yes, sure.
> 
> As I said before, the $Conf{IncrLevels} is set to blank. To have a
> "null" value for this parameter is not described in the documentation,
> afaik,
> so I'm a bit suspicious about that. I tried to set the IncrLevel to 1
> and now I have a perfect behaviour in my tests. Also, in the summary for
> the incremental runs above the level has the value "ARRAY(0x8948138)"
> which doesn't make any sense to me. Here is the full table:
> 
> Backup#     Type     Filled     Level     Start Date     Duration/mins
>     Age/days     Server Backup Path
> 336     full     yes     0                   7/6 11:30     223.6     7.0
>     /var/lib/backuppc/pc/eddie/336
> 337     incr     no     ARRAY(0x8947f0c)     10/6 11:32     8.0     4.0
>     /var/lib/backuppc/pc/eddie/337
> 338     incr     no     ARRAY(0x8947f0c)     11/6 11:32     173.9
> 3.0     /var/lib/backuppc/pc/eddie/338
> 339     incr     no     ARRAY(0x8947ee8)     12/6 11:35     12.9     2.0
>     /var/lib/backuppc/pc/eddie/339
> 340     incr     no     ARRAY(0x89480e4)     12/6 21:07     223.2
> 1.6     /var/lib/backuppc/pc/eddie/340
> 341     incr     no     ARRAY(0x8948138)     13/6 10:59     7.3     1.0
>     /var/lib/backuppc/pc/eddie/341
> 342     incr     no     ARRAY(0x8948138)     13/6 11:16     175.2
> 1.0     /var/lib/backuppc/pc/eddie/342
> 
> So it seems the IncrLevel parameter solves this for me but I have to run
> some real backups to verify that.
> Thanks
> /Erik

I'm with you. But your incrementals will backup all files changed since last
full. Do you want that?
>>From the documentation:
$Conf{IncrLevels} is used to specify the level of each successive
incremental. The default value is all level 1, which makes the behavior the
same as earlier versions of BackupPC: each incremental will back up all the
files that changed since the last full (level 0).
---
I make a full backup each 7 days and use $Conf{IncrLevels}  = [1, 2, 3, 4,
5, 6];
So the first incremental save all files changed since last full. All
following incrementals will save changed files since last incremental
backup.
The famous backuppc GUI will fill each incremental backup with the files not
backuped since last full (sorry for my bad english;-). So each incremental
appears in the GUI like a full backup.

br
Matthias
-- 
Don't Panic


------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/