We are dipping out toes in the NDMP pool for some of our largest
Qtrees. There are some pros and cons, and I believe someone earlier
today mentioned a few and I agree with them.
In my mind, the biggest CON in using NDMP is the inability to
make copypool duplicates. This suddenly puts a HUGE hole in your DR plan
unless you start taking the primary tapes out of the library. And of
course then the data is not available for the day-to-day end-user
restores. IBM has indicated that NDMP data should be integrated into the
Storage pool hierarchy by the end of the year, so that should fix that
problem.
The single thread per NDMP process can be a performance problem,
as mentioned before.
The Full -incr -incr -incr ..-Full methodology is a step
backwards and if your retentions are very long, you will end up keeping
MUCH more data in TSM than through normal TSM backups.
I don't believe that there is any way to differentiate
retentions for files in an NDMP backup. I believe that you have to keep
the whole vol/qtree for the same amount of time, so that is also kind of
a step backwards.
Then there is the issue of needing one tape drive for every NDMP
process you have going. This can be remedied with a VTL, but for those
of us without one, it means tying up tape drives to NDMP...
The one PRO that everyone sites is : faster backup times, and
that is true, but depending on the TOC size, the restore performance may
be very poor.
So you can get tell I'm not really impressed with NDMP, however
we are still looking into it. Our reason is that we have some NT
filesystems with over 10- 24 million files that we back up using a
Windows client so we can get the ACLs, and the performance is HORRIBLE.
We are talking multiple days for an incremental backup.
- We can't use the journaling feature, because that only works
on local disks, not CIFS mounts.
- We can't use NFS mounts because we lose the ACLS. We ~could~
backup the ACLS separately and reapply them to restored files, but
operations balks that creates too much room for error in these days of
SOX/HIPPA regulations.
Ben
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Jason Lee
Sent: Wednesday, March 08, 2006 9:37 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: ndmp limitations
On Mar 8, 2006, at 7:25 AM, John Bremer wrote:
> Greetings,
>
> We've been using TSM with NDMP for over a year, and while we want our
> customers to use our service rather than Legato (the predecessor),
> there are some limitations:
>
> (1) There are situations where TSM (or NetApp/NDMP) does not translate
> certain file/path names properly, and TOC builds fail. We have been
> working with IBM quite a lot on this, and have resolved
> *most* issues;
>
> (2) TOC loads on the TSM server are *excruciatingly* slow. We have
> thrown all the hardware and memory we can at the server, and some TOC
> loads still take 4 hours (yes, that is not a typographical error).
> Granted these are multi-TB volumes with millions of files, still there
> should be a better way to get the TOC records from disk to database.
> That's another problem we have open with IBM, and we are working with
> their performance people.
>
> (3) We recommend defining as many virtual mapping points as possible:
> volume restores can be done in parallel, and above mentioned TOC loads
> are quicker. It adds another level of administration, but no big
> deal.
>
> We recently restored a 3.3TB volume which took about 29 hours, using
> one 9940B drive.
>
> Overall we are happier with TSM using NDMP than backing up these large
> filers over TCP, through a TSM backup client (though file level
> restore was/is a lot better there).
>
> John
Hi John,
you mention that overall you are happier with the TSM using NDMP rather
than TCP. Could you expand on that for me? We're looking to perhaps use
NDMP on our NetApp farm but would love to get a pro/con feel going
before committing the resources.
Thanks very much
Jason
--
Jason Lee
DreamWorks Animation
(818) 695-3782
|
