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

On Sat, 14 Jan 2012 22:07:43 +0100 Florian Pritz wrote:

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.

replication != backup. if you do the wrong query ('drop database', 'drop table', 'delete from', 'truncate table', and so on), it will be executed on all slaves as well. besides, mysql replication is not very robust, a better way is to make dumps of the database. Dieter

On 01/15/2012 01:06 AM, Allan McRae wrote:

On 15/01/12 06:05, Ionut Biru wrote:

...

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

Don't we have an unused server tagged for backups already?

If you mean hogni, that's Thomas's VM and it doesn't have much space left. -- Florian Pritz -- {flo,bluewind}@server-speed.net

On 01/22/2012 10:50 PM, Ionut Biru wrote:

On 01/15/2012 02:06 AM, Allan McRae wrote:

...

On 15/01/12 06:05, Ionut Biru wrote:

...

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

Don't we have an unused server tagged for backups already?

Allan

what you guys think about ovh?

http://www.ovh.co.uk/dedicated_servers/backup_fs_4To.xml

or http://www.kimsufi.co.uk/ the first one but i don't know if it has 2x500GB or 1x1TB -- Ionuț