also sprach martin f krafft <madd...@madduck.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.bo...@madduck.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@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/