Every time NDMP comes up, I wince.  It seems to be very a very popular
idea, but it has some important problems.  NDMP vendors are nibbling
away at these, but nibbling is the best you can say for it.  And the
rate of nibble isn't even that great; you'll find that the NDMP
organization's homepage has their last news entry in January of 2005.


First and foremost: NDMP is not a "backup program" or a "backup
protocol", though the verbage likes to claim otherwise.  It's a method
for providing a remote interface to a tape.  Unixoids who are familiar
with rmt are familliar with the fundamentals concepts of NDMP.

This means that the 'backup program' is something DATA-server
specific.  If you find three products which advertise NDMP support, do
not expect their backup behavior to be similar in other ways; it's
like saying that the products have SSH support or can be configured
via a web interface.


Most of the problems with NDMP are reflections of this fact.  For
instance, all of your DATA servers have to support your TAPE devices.
When I tried to find out the 3592 support status for a given mail
application which advertised NDMP support, I got a blank look and a
never-fulfilled promise to get back to me on that.

There were promises that device-specificity would change in the
future.  It may have since then, I don't know.  But again, the NDMP
protocol isn't moving too fast; I'd doubt it offhand.


The problems with the copypool concept spring directly from this: TSM
doesn't (didn't?) _know_ what was on the tapes, how could TSM copy it
somewhere else?

We're all familliar with the TSM incrementals-forever vs.
full/diff/incr debate.  In NDMP land, you are constrained by the
choices each DATA server manufacturer has made.

These by themselves seemed sufficient to me, to discourage adoption of
NDMP the last time it was suggested.  I wanted to have a good reason
to try it: it's been a buzzword I've seen enough.  But I couldn't
justify it.



- Allen S. Rout