We went the other route and backup our filers (Isilon and BlueARC, not
NetApp) over NFS using a pool of TSM proxy nodes and schedules that
"float" between the nodes. We have a small staff relative to the size of
our environment, and decided that while we could support one backup
environment well, we couldn't do two.

So far, it's scaled better than can be expected. At the extreme, we've
pumped over 50TB/day through the proxy nodes.

-- Skylar Thompson (skylar2 AT u.washington DOT edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine

On 06/07/13 09:16, Shawn DREW wrote:
> To paraphrase Churchill, NDMP is the worst form of NAS backups, except for 
> all the others..
>
> I keep testing snapdiff with every new TSM client and/or ONTAP update.  It's 
> just not as reliable as NDMP for me.
> Bottom line is that if you can't handle the periodic full-scan backups (like 
> journaling) then don't bother.  At least for our (250TB) environment.
>
> You can make NDMP on TSM bearable with lots of scripting and classic backup 
> thinking (i.e. regular fulls and no copypools)  Also, separate NDMP storage 
> pools and group backups with the same retention.  i.e NDMP_35day, NDMP_1year, 
> etc.  This lets the tapes expire regularly without reclamation.
>
> As far as drives per filer, it seems like a standard to not go over 4 drives 
> per filer concurrently but, as always, it depends.  Some file servers are 
> more powerful and can handle more, some less.  Some volumes are just plain 
> slower than others and you need to plan around that.
>
> Someone also mentioned something about not being to create a TOC because of 
> too many files.  During an NDMP backup, the TOC is temporarily stored in the 
> DB temp space then dumped to the actual TOCDestination after the backup 
> finishes.  (if your DB is 80% utilized, then the 20% unused space is the temp 
> space).
> I ran our NDMP TSM Server/library manager with a 150GB db that was .05 pct 
> utilized.  This solved all of our TOC issues, so may help. (This was TSM 5.5, 
> so I'm not sure how that is handled in TSM 6)
>
> That said, we scrapped TSM NDMP here.  We have a small dedicated Netbackup 
> environment just for NAS now.  It uses a heck of a lot of tapes, but it 
> finishes reliably.
> It was like magic when I was able to preview the tape I would need for a 
> restore without having to run selects against the backups/contents tables and 
> not having to wait a couple hours to load a particularly large TOC.
>
> Regards,
> Shawn
> ________________________________
> Shawn Drew
>
>> -----Original Message-----
>> From: ADSM-L AT VM.MARIST DOT EDU [mailto:ADSM-L AT VM.MARIST DOT EDU]
>> Sent: Friday, June 07, 2013 11:30 AM
>> To: ADSM-L AT VM.MARIST DOT EDU
>> Subject: Re: [ADSM-L] Planning for NDMP backup
>>
>> If you have a NetApp, is there any particular reason you're not using
>> snapdiff?  My experiences with NDMP are all bad.  Troubles with reclamation,
>> troubles with creating copy pools, having to cancel backups, reclamation and
>> backup stg because the recovery log was getting way too full.
>>
>> -
>> Cameron Hanover
>> chanover AT umich DOT edu
>>
>> Reminds me of my safari in Africa. Somebody forgot the corkscrew and for
>> several days we had to live on nothing but food and water.
>> --W. C. Fields
>>
>>
>> On Jun 7, 2013, at 3:51 AM, Michael Roesch <michael.roesch AT GMAIL DOT COM>
>> wrote:
>>
>>> Hi everyone,
>>>
>>> we're planning on implementing a TSM server that also does backup
>>> NetApp Filers and we've run into a few questions. Hope that you can
>>> help me with these.
>>>
>>> 1. Is it possible to store the NDMP backups on disk or is only tape
>>> possible?
>>> 2. If only tape, how many drives are recommended for NDMP backup? One
>>> per Filer if they backup at the same time?
>>>
>>> Thanks in advance for any hints.
>>>
>>> Regards,
>>> Michael
>
>
> This message and any attachments (the "message") is intended solely for
> the addressees and is confidential. If you receive this message in error,
> please delete it and immediately notify the sender. Any use not in accord
> with its purpose, any dissemination or disclosure, either whole or partial,
> is prohibited except formal approval. The internet can not guarantee the
> integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will)
> not therefore be liable for the message if modified. Please note that certain
> functions and services for BNP Paribas may be performed by BNP Paribas RCC, 
> Inc.
>