BackupPC-users

Re: [BackupPC-users] RAID and offsite

2011-04-28 23:32:00
Subject: Re: [BackupPC-users] RAID and offsite
From: Holger Parplies <wbppc AT parplies DOT de>
To: "General list for user discussion, questions and support" <backuppc-users AT lists.sourceforge DOT net>
Date: Fri, 29 Apr 2011 05:31:33 +0200
Hi,

Les Mikesell wrote on 2011-04-27 20:36:13 -0500 [Re: [BackupPC-users] RAID and 
offsite]:
> On 4/27/11 7:10 PM, Chris Parsons wrote:
> > On 28/04/2011 6:52 AM, Les Mikesell wrote:
> >> I've forgotten the original context, but if it is setting up a new
> >> system you don't have much to lose in the initial sync - and by the time
> >> you do, you should have another copy already stored offsite.
> >
> > In this case, why involve the complexities of RAID at all. Just use
> > individual disks, each with their own pool and rotate them. If a disk
> > fails, you only lose that pool. It avoids all the complexities of raid
> > - and the danger of raid corruption. I don't see any point in involving
> > raid until you need to span pools over more than one disk.
> 
> Most backups do a double duty. One use is for complete system/disaster
> recovery, one is for for when you realize the next day that you deleted
> something you need.   Backuppc is particularly good for the latter, more
> frequent occurrence, but if you've just swapped an old disk back you won't
> have access to the copy you are most likely to need.  You'll also be
> copying more than necessary with older reference copies, but that is less
> likely to be a real problem.

Aside from this very important point, some minor reasons spring to mind ...

1.) n-way RAID 1 gives you a theoretical increase of *read* throughput by a
    factor of n. Aside from that, it can save you some head seeks, further
    speeding up operation. As it happens, BackupPC prefers reading from the
    pool over writing to it, when it has a choice (actually, it prefers
    decompression over compression, but the result is the same).
    So, at least in theory, RAID 1 can speed up your backups.

2.) Although we usually forget it, RAID is about *uninterrupted* operation.
    If your disk dies, your server doesn't go down. With RAID, you *might*
    be able to go and buy a replacement disk, plug it into the computer,
    and resync the data without any of your users ever noticing anything
    (except for the slowdown due to the resync, but they'll probably just
    complain, "my internet is broken" ;-).

3.) If a disk fails, and "you only lose that pool", that pool may contain
    backups you vitally need. Though the other pools probably contain backups
    "close by", that may not be good enough. While you can't avoid losing
    "young" backups (from after the last resync), you *can* avoid losing older
    backups.

But, if these points are not important in your case, using independent pools
may very well be an option. As a variation, you could even have offsite
BackupPC servers doing backups alternately (server 1 on day 1, server 2 on
day 2, server 3 on day 3, server 1 on day 4, etc.) if your backup clients
(or network bandwidth) can't take the impact of more than one backup per
day. That way, you would have all of the backup history online (though
spread over several servers), and a disasterous event at any one site
would leave you the remaining pools.
Bandwidth permitting, of course.

Regards,
Holger

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/