ADSM-L

Re: [ADSM-L] Re: Planning for NDMP backup

2013-06-07 19:10:30
Subject: Re: [ADSM-L] Re: Planning for NDMP backup
From: David Bronder <david-bronder AT UIOWA DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 7 Jun 2013 18:08:20 -0500
We finally gave up on NDMP entirely.  We replaced it with NetApp's
SnapVault solution.  Friendlier for the service owner to use, and
managing it all became Not My Problem.

When we did use NDMP with TSM, I zoned all the drives to the filers
(shared the drives with TSM and two arrays), but set a mount limit on
the device class.  That way, I didn't need to worry about an NDMP
operation consuming too many drives, nor need to dedicate one or two
drives to just NDMP operations.  I used NETAPPDUMP format tape pools,
scheduled the NDMP backups to one at a time per filer (more than that
not only consumed more tape drives, but also slowed the backups down
considerably), and scheduled the storage pool backup for about 10 days
later (took around a week to complete one set of full backups).

I did use ToCs (stored in a native format pool).  We only ran one set
of full backups, monthly, with no differentials.  We relied on filer
snapshots for restores from later than the last full, and replication
to another filer for DR recovery.  I configured the web client on a
Windows server for the service owner to have a more useful interface to
browse or restore backups.

I started playing with SnapDiff, but didn't get far with it for CIFS
shares, and had utter failure for NFS shares.  Abandoned the testing
once they started talking about switching to SnapVault.

I'm in Wanda's camp as far as NDMP goes...

=Dave


Skylar Thompson wrote:
>
> 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.
>
>
> 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


--
Hello World.                                David Bronder - Systems Architect
Segmentation Fault                                      ITS-EI, Univ. of Iowa
Core dumped, disk trashed, quota filled, soda warm.   david-bronder AT uiowa 
DOT edu