John, the other problem I had is posted at
with a response by Josh Malone. I think my situation is rather unique,
unless your backuppc system lost track of some full backups and your
problems did not go away after a full backup.
Until I did a full backup, the incremental backups were transferred 140MB
of data and the files were marked as 'pool'. The full backup on the 16th
marked the files as 'same'. An incremental backup on the same day did not
check the files. I 'touch'ed one of the files on the 17th - it was
checked by the incremental backup on the 18th, the file was marked as
'same' but no data was transferred. The incremental backup on the 19th
failed (connectivity). The incremental backup on the 20th also checked
the file, marked it as 'same' but again no data was transferred.
I do not know enough about what backuppc does with a file that is in the
pool but not in any full backup. I increased logging to '-vvv' and
enabled '--stats' which is what led me to believe that checksum
information was not properly sent to the remote site (the remote system
reported false_alarms=0 hash_hits=0 matches=0).
From: Les Mikesell <lesmikesell@gm...> - 2010-07-22 17:19:59
On 7/20/2010 2:58 PM, nhoeller@... wrote:
> I do not know enough about what backuppc does with a file that is in the
> pool but not in any full backup.
They stay in the pool as long as they appear in any incremental run(s).
Unless you are using incremental levels, they aren't used for rsync
comparison during the transfer, but after getting a new copy of
duplicate content, the match in the pool would be found and the
duplicate file replaced with a link.
Get latest updates about Open Source Projects, Conferences and News.