On 14.01.2012 21:05, Ionut Biru wrote:

I was talking today with Florian about implementing a backup strategy, involving master-slave setup and dbs, pulling encrypted snapshots on the box and so on.

My idea is that we set up mysql slaves (with ssh tunnels) so we have live backups that can be restored easily. Everything combined we have around 8 write operations per second so that doesn't require powerful hardware. As for files I'd just use rsnapshot, but those backups will be protected only by filesystem permissions and will not be encrypted. rsnapshot will hardlink identical files though potentially saving lots of space. In case we want encryption we'd have to find something that allows us to pull the backup (see below) yet make them differential so we don't back up the complete svn, wiki data, bbs data, ... each time because that would become way too big if we want to keep more than a few old copies. I'd like to pull the backups instead of pushing them so in case a server is compromised the attacker can't get direct access to the backup server. It will still be possible to exploit bugs in mysql's replication, but I have no idea if there are (m)any. I would also agree to using dumps in that case. In case we require encryption and can't find a tool that allows us to pull, it should be possible to restrict the access to sftp only and have a program create lvm snapshots (if the pushing program needs the old files like duplicity) where new backups will be uploaded to and then copy only new files to the real file system or something like that.

For that we need at least to rent a new server just for this job, maybe an atom server with lots of space.

Having an extra box would certainly make things easier. (storage space and IO wise) -- Florian Pritz