After a long break, let’s see some techie stuff.
I’ve recently found rdiff-backup, which seems to be a nice tool to create backups. (No, I don’t have time to play with neither amanda nor bacula.) Instead of the usual “targz everything” approach, which can take up a pallet of disks if You need a couple of rotations, I wanted to optimize the weekly backup schedule, and see how an incremental backup could be put together. Ability to do partial bare-metal recovery was also in the plans. Let’s see how it goes.
If you are to do bare-metal recovery backups, root access to the boxes is a criteria to copy over the correct uid/gids and to have access to everything. Doing an automated backup this way can only be done with SSH keys without password – which is not a very elegant thing -, this was opted out because I didn’t want to explicitly trust the designated backup box. Let’s do it the other way, let the boxes upload the backups to the backup box.
Also, I didn’t want to trust any box to log on as root to the backup box (again, correct uid/gids!), so I put together a chroot that holds only a dropbear and an rdiff-backup – this was something that I thought fair enough to give out SSH keys without password. Every box then would get its own chroot, its own running dropbear on a different port that it can upload its backups to. Yes, you may say that there is the chance that the backups could get compromised this way, however, thinking of the incremental backups and the fair amount of logging… The chroot still has to be ripped out further, as for example bash and a couple other commands still are there. Anyway…
I’ll upload the chroot and the scripts that does the backup sometime this week, until then I’m open for your comments on this approach.