On Friday, August 19, 2011 10:35:10 AM 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 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.
Why not use a different backup tool that doesn't have this possible problem? Rsync will clear the target is the source is emptied as well. Not sure if this can be prevented. > > 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? I am, when it comes to backing up desktops. The server is actually a xen-host with multiple xen-domains running on it. I found it easier to have the host determine the backups. The sequence of steps is basically as follows: 1) host tells domain to stop service(s) 2) host tells domain to unmount filesystem 3) hosts disconnects filesystem from domain 4) host creates snapshot (LVM) 5) host reconnect filesystem to domain 6) host tells domain to remount filesystem 7) host tells domain to stop service(s) 8) host backs up snapshot 9) host deletes snapshot I couldn't do a push-system for the virtual machines as I didn't want to expose the host. > >> 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. Yes, I don't see any problem with that. If the backup-server is compromised via a compromised other system, the keys on that system are compromised already anyway. I don't have private keys without passphrase apart from the one the host uses to send commands to the virtual machines. And the host can't be accessed by remote. -- Joost
