It's out of scope for file transfer protocols; it's a daemon/system-local problem. Attach pre-event or post-event scripts serverside for any special munging or protections you'd like to apply. (Such as triggering an LVM snapshot, for example...)
(sorry for the top post; in-line can be done in this client, but it's more cumbersome than I have time for atm...) ZZ On Nov 14, 2011 7:45 PM, "Grant" <emailgr...@gmail.com> wrote: > >>>>> And if I pull, none of my backed-up systems are secure because anyone > >>>>> who breaks into the backup server has root read privileges on every > >>>>> backed-up system and will thereby "gain full root privileges > quickly." > >>>> > >>>> IMO that depends on whether you also backup the authentication-related > >>>> files or not. Exclude them from backup, ensure different root > passwords > >>>> for all boxes, and now you can limit the infiltration. > >>> > >>> If you're pulling to the backup server, that backup server has to be > >>> able to log in to and read all files on the other servers. Including > >>> e.g. your swap partition and device files. > >> > >> What if I have each system save a copy of everything to be backed up > >> from its own filesystem in a separate directory and change the > >> ownership of everything in that directory so it can be read by an > >> unprivileged backup user? Then I could have the backup server pull > >> that copy from each system without giving it root access to each > >> system. Can I somehow have the correct ownerships for the backup > >> saved in a separate file for use during a restore? > >> > >> - Grant > >> > > > > You could just as well use an NFS share with no_root_squash. It is > > really more a question of finding the right combination of tools to > > ensure proper separation of concern for server and client. > > > > In fact, I think we are intermixing three distinct problems: > > 1. (Possible) limitations of rdiff-backup with regard to untrusted > > backup servers or clients. > > The limitation is real unfortunately. All backups created by > rdiff-backup more than a second ago can be deleted something like > this: > > rdiff-backup --remove-older-than 1s backup@12.34.56.78::/path/to/backup > > > 2. The purely technical question which file transfer protocols protect > > against write access from backup server to backup client and backup > > client to older backups on the server. > > rdiff-backup doesn't provide those sort of protections. Do any file > transfer protocols? > > > 3. The more or less organisational question what level of protection > > backups need and how fast security breaks have to be detected. > > I think backups should be very well protected and security breaks > should not have to be immediately detected. > > - Grant > > > > I think push vs. pull is just a secondary concern with regard to the > > second question and has practically no relevance to the third one. > > > > Regards, > > Florian Philipp > >
