>> >> 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 do back up the backup server to another system via rsync, but if the backups on the backup server are wiped out, rsync will wipe them out on the other system too. > 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.) I thought you were in favor of "pushing"? How do you back up to a system that can't access the backups? >> 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. So it's OK to back up a private key to another system? I just want to make sure I'm not breaking a "good admin" rule by doing this. - Grant
