From: Les M. <le...@fu...> - 2008-01-17 18:21:59
|
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 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. > 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. > There are two separate solutions I would love to see. One is the > ability to run BackupPC in an active/active cluster: two (or more) > BackupPC servers with a common pool between them. Both servers would be > able to simultaneously run jobs (but likely not on the same host, of > course). I think this would be straightforward. > This would help scalability: I have to partition into > multiple servers because I run out of time before I run out of disk > space--to create a multi-terabyte array today is trivial. But I'm not sure it is so trivial to get the NFS performance you would need from such a file server. -- Les Mikesell le...@fu... |