Brian Tao taob@risc.org writes:
I can only realistically expect a peak of 8 to 10 MB/sec from our filers (for some of them, there is only "busy" hours and "really busy"
Is that from experience or theory?
out to tape. With compression turned on, I figure I'll need about 20MB/sec per tape drive to keep them chugging along. Less
Does M2 have the streaming issues of DLT? You'll certainly never push that much data into a DLT7000 or AIT. ~10MB/sec with bursts to 12 is the best you'll get. I think M2 is probably too new to know how it really behaves in the real world.
constraints you may have. This also gives you a nearline copy of all your data. Combined with the Netapp's snapshots, I should never ever
If you're doing that, it would seem to me it would make more sense to use a second (perhaps in a cluster) toaster and mirror the volumes using snapmirror.
I haven't had an opportunity to really test out how fast rsyncworks over NFS with the particular hardware setup described above, so that's the weak link. If the results from trial runs on a non-
It's not all that fast (somewhere i have some numbers I ran). If you're syncing lots of smaller files, you'll burn through memory like mad, too.
there will be a problem. Multiple rsyncs can be fired up concurrently to keep the filers busy. For the amount of data we have (300GB at
I thought they were already quite busy. If they're so busy that you don't feel you can attach a local tape drive, I'm not really understanding how they're unbusy enough to hammer them with a bunch of rsyncs.
Frankly, I think you've made the solution much more complicated than need/should be. Backups should be done as simply as possible -- you've added lots of opportunity for things to break, which really don't need to be there.
Anyone else doing it like this?
I suspect not.
Darrell