Re: [BackupPC-users] Scaling BackupPC

[Timothy J. M. <tm...@mo...>]

Les Mikesell <le...@fu...> wrote on 01/17/2008 01:24:24 PM:

 > Timothy J. Massey wrote:
 >
 > > And there's no
 > > coordination between the two instances:   the moment the copy is
 > > finished, they're two separate pools with separate schedules, etc.
 >
 > Which means, of course, that if something goes horribly wrong on one
 > (like the admin typing 'rm -rf ...' in the wrong place) you'll still
 > have the other copy at its last snapshot state.
 >
 > > Which is why, of course, you have to leave BackupPC shut down on the
 > > other box.  DRDB helps:  it eliminates both shutting down BackupPC and
 > > rsync limitations for duplicating the pool.
 >
 > DRDB might help propagate the disaster in real-time.  I'm not convinced
 > that is desirable.

You are correct; but that's what my second idea (replication of 
individual backups) is for:  *automatic* and hands-off movement of 
backup data from one place to another.

 > > You could also do the same
 > > thing with breaking a RAID-1 mirror:  Les brings this up every 
time!  :)
 >
 > It works - and takes minimal down time.  You could probably do this over
 > iscsi if you wanted to eliminate the physical disk swap.

Sure, as far as it goes.  I would like to have something that is managed 
completely under BackupPC.

 > >   But you're still left with two indepenent servers, or at best an
 > > active/standby cluster.
 >
 > And in the backup business, that might be a good thing. When I
 > raid-mirror, I rotate the target disks so I never overwrite my last good
 > copy.

I want two servers with two pools, but I do not want the load on my 
*clients* of having to back up data to two different servers.  We have 
the same goals (redundant copies of the data), but different ways of 
doing it.

 > But I'm not sure it is so trivial to get the NFS performance you would
 > need from such a file server.

I am *so* *not* talking NFS.  Something more like GFS and iSCSI...  :)

Tim Massey