On Thursday, August 18, 2011 06:51:32 PM Grant wrote: > >> I'm setting up an automated rdiff-backup system and I'm stuck between > >> pushing the backups to the backup server, and pulling the backups to > >> the backup server. If I push, I have to allow read/write access of my > >> backups via SSH keys. If I pull, I have to enable root logins on each > >> system to be backed-up, allow root read access of each system via SSH > >> keys, and I have to deal with openvpn or ssh -R so my laptop can back > >> up from behind foreign routers. The conventional wisdom online seems > >> to indicate pulling is better, but pushing seems like it might be > >> better to me. Do you push or pull? > > > > I would push, to be honest. > > What can be done about the fact that any attacker who can break into a > system and wipe it out can also wipe out its backups? That negates > one of the reasons for making the backups in the first place.
True, except if, after a backup is finished, you move the actual backup to a different location. (Or you backup the backup server) I store all important files on my server and the backups there can not be accessed from the fileserver itself. (That backup is done in "pull" mode every night.) > Should private SSH keys be excluded from the backup? Should anything > else be excluded? When a host is compromised, the corresponding entries in the "authorized_keys" should be removed from all other servers/hosts. This will make those private keys useless. If you protect them with a passphrase, the private keys are not usable in any case. But this will require the backups to be started manually to allow you to enter the passphrase. Or you unlock the passphrase in memory and use ssh-agent for that. -- Joost
