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