Dean, I think you correctly attribute your problem to network latency. You may wish to see http://en.wikipedia.org/wiki/Bandwidth-delay_product for a quick summary, and, if you have root access on both sides, http://fasterdata.es.net/TCP-tuning/linux.html for possible improvements.
<dc><snip> Restoring 6GB of data took over 12 hours. I'm located in Australia and my backups are hosted on Amazon Web Services on the east coast of the US (can't get much more offsite than that!). Investigations showed that neither the CPUs on either end nor the network link were the limiting factor. In fact, I was able to run three simultaneous restore sessions with no degraded performance before the network link became saturated. This suggests that network latency (typically 250ms in my case) is the determinate factor for the restore performance. Whilst I don't know much about the details of the protocol, it might be possible to speed up rdiff- backup by using larger blocks or windowing. </dc> Thanks, Steve Dutky _______________________________________________ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
