also sprach martin f krafft <madduck AT madduck DOT net> [2016-08-04 22:16 
+0200]:
> Right now, I am staring at the lsof output of the rsync process on
> a backup client, spawned by BackupPC. It's processing a 3.5G file
> that has not been touched in 5 years and has been backed up numerous
> times. According to strace, the entire file is being read, and it's
> taking a toll:

I also can't help but notice that the pool file is open on the
server, and that the corresponding dump process does continuious
reading (according to strace) on a socket, presumably linked to the
SSH process connected with the client.

Maybe reliance on file metadata isn't good enough for a backup.
After all, a backup should care about file content, not metadata.

But instead of (what seems to be) chunk-wise checksum transmission,
why don't we (also) store the whole-file checksum on the server (can
be computed in the same pass) and at least give people the option to
risk reading every file once to compute this checksum, if it means
being able to skip files without further ado or large data
transfers?

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"he gave me his card
 he said, 'call me if they die'
 i shook his hand and said goodbye
 ran out to the street
 when a bowling ball came down the road
 and knocked me off my feet"
                                                        -- bob dylan
 
spamtraps: madduck.bogus AT madduck DOT net

digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

------------------------------------------------------------------------------

_______________________________________________
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/