[arch-dev-public] backup strategy for our servers

[Florian Pritz]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-dev-public/attachments/20120114/293cba18/attachment.asc>