FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 01-14-2012, 07:05 PM
Ionut Biru
 
Default 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Č›
 
Old 01-14-2012, 08:07 PM
Florian Pritz
 
Default backup strategy for our servers

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
 
Old 01-14-2012, 11:06 PM
Allan McRae
 
Default backup strategy for our servers

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
 
Old 01-15-2012, 04:29 AM
Myra Nelson
 
Default backup strategy for our servers

On Sat, Jan 14, 2012 at 18:06, Allan McRae <allan@archlinux.org> 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
>
> Since I'm unable to post to the dev list I'll put this here. Before you
rent an atom server I have an MSI atom (IIRC it's an atom 270) board with 1
gig of memory, dual lan ports, dvi, vga, and 4 usb ports. It doesn't have
any hard drives but would hold 5 hard drives. I'll have to check my power
supply stock to see what I've got and test the board. It's been sitting in
the closet for a while. If you're interested I'll check it out and the
price is right -- trust me. Working as it sits with no power or drives
paying for the shipping will get the box.

Myra



--
Life's fun when your sick and psychotic!
 
Old 01-15-2012, 08:31 AM
Florian Pritz
 
Default backup strategy for our servers

On 15.01.2012 06:29, Myra Nelson wrote:
> On Sat, Jan 14, 2012 at 18:06, Allan McRae <allan@archlinux.org> 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
>>
> Since I'm unable to post to the dev list I'll put this here. Before you
> rent an atom server I have an MSI atom (IIRC it's an atom 270) board with 1
> gig of memory, dual lan ports, dvi, vga, and 4 usb ports. It doesn't have
> any hard drives but would hold 5 hard drives. I'll have to check my power
> supply stock to see what I've got and test the board. It's been sitting in
> the closet for a while. If you're interested I'll check it out and the
> price is right -- trust me. Working as it sits with no power or drives
> paying for the shipping will get the box.

Thanks for the offer, but colocation is likely more expensive than
renting and it's also more work for us. Someone has to assemble the
server, bring it to the data centre, fix the hardware if it fails, ...

--
Florian Pritz
 
Old 01-15-2012, 03:26 PM
Myra Nelson
 
Default backup strategy for our servers

On Sun, Jan 15, 2012 at 03:31, Florian Pritz <bluewind@xinu.at> wrote:

> On 15.01.2012 06:29, Myra Nelson wrote:
> > On Sat, Jan 14, 2012 at 18:06, Allan McRae <allan@archlinux.org> 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
> >>
> > Since I'm unable to post to the dev list I'll put this here. Before you
> > rent an atom server I have an MSI atom (IIRC it's an atom 270) board
> with 1
> > gig of memory, dual lan ports, dvi, vga, and 4 usb ports. It doesn't have
> > any hard drives but would hold 5 hard drives. I'll have to check my power
> > supply stock to see what I've got and test the board. It's been sitting
> in
> > the closet for a while. If you're interested I'll check it out and the
> > price is right -- trust me. Working as it sits with no power or drives
> > paying for the shipping will get the box.
>
> Thanks for the offer, but colocation is likely more expensive than
> renting and it's also more work for us. Someone has to assemble the
> server, bring it to the data centre, fix the hardware if it fails, ...
>
> --
> Florian Pritz
>
>
You're welcome and I fully understand.

Myra

--
Life's fun when your sick and psychotic!
 
Old 01-15-2012, 05:58 PM
Dieter Plaetinck
 
Default backup strategy for our servers

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
 
Old 01-15-2012, 06:36 PM
Florian Pritz
 
Default backup strategy for our servers

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
 
Old 01-19-2012, 01:04 PM
Florian Pritz
 
Default backup strategy for our servers

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
 
Old 01-22-2012, 07:50 PM
Ionut Biru
 
Default backup strategy for our servers

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Č›
 

Thread Tools




All times are GMT. The time now is 06:16 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org