Andreas Olsson wrote: > Luckily there is a workaround in sshfs you can apply (-o workaround=rename) > > Perhaps that sshfs-workaround should be mentioned in rdiff-backup's > documentation? Myself I plan to write a page on sshfs in the wiki, but as for > the official documentation, that is for someone else to decide.
Great! Thanks for finding that workaround option. It turns out that the -o workaround=rename option is enabled by default in the MacOSX version of sshfs, which is why I didn't not run into the issue. I have added a note about it the official FAQ, as well as a link to the Wiki entry. > Obviously sshfs couldn't create hard links. They were instead stored as > separate files. Perhaps information on hard links could be saved as metadata > and then the hard links would be recreated on a restore? To my knowledge, they are stored in the metadata as hard links, and are recreated as such during the restore. > I also took the opportunity to do some performance test comparing running > rdiff-backup against an sshfs-mount and running rdiff-backup the "normal" way > through an ssh-tunnel. In those cases which primarily involves transferring > files, such as an initial backup or a restore, it always took conciderable > longer time when sshfs was involved, no matter the amount of files, the speed > of the link, etc. When doing an incremental backup, in other words mostly > comparing files, updating metadata and transferring a few files, the results > vary depending on the changes in question, the speed of the link, etc. Excellent. Do you think you can add the performance testing notes to the Wiki entry? Thanks, Andrew -- Andrew Ferguson - [EMAIL PROTECTED] _______________________________________________ rdiff-backup-users mailing list at [email protected] http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
