BackupPC Manual mentions: ---------------------------------------------------- Each file is examined by generating block checksums (default 2K blocks) on the receiving side (that's the BackupPC side), sending those checksums to the client, where the remote rsync matches those checksums with the corresponding file. The matching blocks and new data is sent back, allowing the client file to be reassembled. A checksum for the entire file is sent to as an extra check the the reconstructed file is correct.
This results in significant disk IO and computation for BackupPC: every file in a full backup, or any file with non-matching attributes in an incremental backup, needs to be uncompressed, block checksums computed and sent. Then the receiving side reassembles the file and has to verify the whole-file checksum. Even if the file is identical, prior to 2.1.0, BackupPC had to read and uncompress the file twice, once to compute the block checksums and later to verify the whole-file checksum. ---------------------------------------------------- Why is it actually necessary to do this checksum checking? Wouldnt it be enough to find files with non-matching attributes and back them up? I think that in most cases if at least modification time is different then the file should be backed up anyway, no? at least there can be situations where the lst modification time of a file is more important than it's contents even (I dont see how but it is a possibility) Thanks, Evren ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/
