Hi everyone,
thank you for your input, especially Jeff White for his very detailed
message :-)
So it seems like, some have NDMP working and some don't and now I'm not
sure which road to take.
Independently from which way you go (NDMP, SnapDiff,...), are 2 drives
sufficient for that or is it better to take 3 or 4 drives?
Thanks
Regards,
Michael
On Sat, Jun 8, 2013 at 1:08 AM, David Bronder <david-bronder AT uiowa DOT
edu>wrote:
> 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
>
|
