> 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...)
I must be going about this the wrong way. Am I the only one using automated backups? If not, how is it done properly? - Grant >> >>>>> 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
