Comment 21 for bug 453169

My thoughts are purely from an SSH point of view, and I'm not sure how they would integrate with a general solution for network backups. I'm kind of under the impression that each network backup type would kind of need to be implemented on it's own.

One question I would have off the top of my head though; why not drop the permission saving feature completely, when doing unix based backups, if desired? Is it so that the backup is completely portable? If it is, do the permission saving thing, but still leave the file system with proper permissions in tact, perhaps?

Dan, you did mention issues with hard linking and --link-dest, regarding permissions. Doesn't --chmod solve that problem, assuming the same --chmod is used through the life-time of the network backups? And, if the --chmod is changed, maybe execute a shell call to change permission to what you want them to be?

Additionally, I think a solution for this would need to store meta-data for the remote backups locally, potentially for a variety of reasons
1. efficiency of displaying available backups
2. efficiency during the backup process, as you don't have to grab remote files to check what the last backup was, for example.

p.s.
It would be ideal for this feature to use password less ssh keys. The user can ensure that no other commands can be run on the remote side, via the authorized keys file.