Allen,
Thanks for your response.
I did not include your option 0, because I was thinking "large file servers".
Your point about option 0 being potentially more viable if metadata is kept on
SSD is interesting. Does anyone have any first-hand experience with this that
they can share?
Option 4 is admittedly expensive and in a different RTO class. I included it
because in some situations, it may indeed be the only viable option for offsite
protection. And as you say, if the replica can be on slower, cheaper disk,
that brings the cost down some.
..Paul
At 09:26 AM 2/14/2012, Allen S. Rout wrote:
>On 02/13/2012 11:46 AM, Paul Zarnowski wrote:
>
>
>>[...] I see the following major categorizations of how to protect
>>(large) file servers effectively. Please feel free to comment on
>>this, as I'm looking to refine my view.
>
>>I should say that our "protection goal" would be to have a copy of
>> data at our medical college campus, which is ~200+ miles away and
>> accessible via a 10Gb WAN.
>
>>1. Backup using NDMP: breaks down as data size increases, because of
>>need for periodic full backups and lack of incremental forever.
>>However, probably fast recovery times from tape. Most NAS products
>>support some version of NDMP.
>
>>2. Incremental file-level backup based on Journal Scanning, saving a
>> walk of the filesystem. Examples include Windows-based
>> fileservers, and (I think) SONAS.
>
>>3. Incremental backup based on Snapshot differencing, again saving a
>>walk of the filesystem. This would be NetApp, but not with
>>MultiStore vFilers - a problem for us.
>
>>4. Asynchronous replication to a second NAS. Fast RTO, but also
>>expensive.
>
>>Options 1-3 use TSM.
>>Options 2&3 run faster and are more scalable than option 1, but likely have
>>longer RTO.
>>Option 4 is probably most expensive.
>
>
>I'm going to assume
>
>0. Conventional TSM backup via a proxy node. Requires keeping shares
>quite small (no more than a few TB), if you want anything approaching
>daily incrementals. Bottleneck appears to be metadata scan, walk of
>tree.
>
>I mention that because Isilon (and others?) are starting to offer
>options that let you keep metadata on SSD, which may change the
>maximum size for reasonable conventional incrementals. We're
>expecting to do a POC of Isilon before too long, I intend to examine
>that.
>
>
>-----
>
>
>As for comment, I want to amplify what you said about RTO: Your option
>4 is in a completely different universe from the 0-3. For all of 0-3,
>the DR critical path includes an acquisition cycle. I'm not sure our
>heirarchy could get a PO out in a week if their hair were on
>fire... yours may be better.
>
>Option 4 has nearly immediate recovery, in degraded performance. So,
>it's more expensive, but it moves you to a totally different recovery
>mode.
>
>Our thinking abount isilon backups includes a remote "Near-line" unit,
>that has relatively large, slow, cheap drives. It would be a
>replication target for several other units, giving it good efficiency
>of scale.
>
>
>
>- Allen S. Rout
--
Paul Zarnowski Ph: 607-255-4757
Manager, Storage Services Fx: 607-255-8521
719 Rhodes Hall, Ithaca, NY 14853-3801 Em: psz1 AT cornell DOT edu
|
