[arch-dev-public] backup strategy for our servers
Hi guys, we all know that we suffer in this chapter a lot. 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. For that we need at least to rent a new server just for this job, maybe an atom server with lots of space. What do you think about this idea? Do you know a good company that has good prices, that you use and has good services? -- Ionuț
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 <bluewind@xinu.at> 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 15.01.2012 19:58, Dieter Plaetinck wrote:
On Sat, 14 Jan 2012 22:07:43 +0100 Florian Pritz <bluewind@xinu.at> 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.
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.
We could just create daily dumps on the slave then. Additionally the slave would prevent data loss in case the main server crashes and the database file there is corrupted.
besides, mysql replication is not very robust, a better way is to make dumps of the database.
Do you have something to back up that claim? -- Florian Pritz
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
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/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 -- Ionuț
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?
or http://www.kimsufi.co.uk/ the first one but i don't know if it has 2x500GB or 1x1TB -- Ionuț
participants (4)
-
Allan McRae
-
Dieter Plaetinck
-
Florian Pritz
-
Ionut Biru