Re: [BackupPC-users] Backup Data Volumes

2010-07-18 Thread Norbert Hoeller
John, Craig identified and fixed  a problem in File::RsyncP on ARM 
processors having to do with whether characters are considered signed or 
unsigned. 

I did stumble on another problem that I will post to the mailing list 
shortly.

I scanned the mailing list but did not see the email that you mention 
below.
Regards, Norbert
 




 From: John Rouillard rouilj-backu...@re... - 2010-06-30 18:47

 Well perhaps not. I posted an earlier email where I am tranferring a
 lot of file data for old files that are in prior level 0 backups and
 are in the cpool.



--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/


[BackupPC-users] High Backup Data Volumes After Re-adding an Excluded Directory

2010-07-18 Thread Norbert Hoeller
While trying to diagnose the high backuppc data volumes issue posted to 
the mailing list on June 14th, I had excluded a directory structure 
containing about 140MB of data.  I removed the exclude once Craig had 
provided a fix for File::RsyncP and noticed that backup volumes jumped by 
about 150MB. Tracing suggested that all the files in the previously 
excluded directory structure were being backed up on every incremental 
backup, even though the content of the files was unchanged (the first 
incremental backup after the directory was added indicated that backuppc 
had found the file in the backup pool).

Although the contents of the files had not changed, I had 'touch'ed the 
files during the period where  the directory structure has been excluded 
so that Google Sitemap would index them .  It seems that the backuppc 
incremental backup got confused and repeatedly selected the files for 
backup even though the file date was no longer changing. 

File::RsyncP/rsync should have determined that the contents of the files 
were identical to the pool copy.  Verbose logging suggests that checksums 
were exchanged, but rsync did nothing with them (the remote system 
reported false_alarms=0 hash_hits=0 matches=0).  The reason is not clear. 
I had enabled checksum caching at one point but disabling checksum caching 
it did not change the symptoms.

The problem was 'fixed' by doing a full backup.  It appears that this 
caused rsync to properly compare checksums and backuppc updated the file 
date - the next incremental backup did not check the files that previously 
had been copied in full.  I 'touch'ed one of the files and verified that 
the next incremental backup checked the file but rsync found no changed 
blocks.--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/