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.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/453169

Title:
  (enhancement) backup to samba share, sshfs, ftp etc

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to