Hi, Yesterday there was some discussion on these mailing lists regarding NDMP and limitations on restores, etc. We'd like to thank you for your feedback and to explain what the current focus of NDMP is and in particular how NetApp's chosen long term archivable backup format (dump) works within NDMP.
Over the last few years NDMP has grown from essentially a 2 company (PDC then IntelliGuard now Legato and Network Appliance) backup solution to a community with 20+ companies participating and > 25 NDMP compliant products shipping. The community has backup software companies, tape library vendors and file system vendors working together to achieve true interoperability and a growing set of features. This was the vision of the original companies.
Recently, this has resulted in a new V4 specification that essentially is a cleanup of V2 & V3 and has added extensibility so that new features may be added without waiting for a spec change. V4 implementations will arrive this year from multiple companies and should put an end to interoperability issues that have cropped up from time to time.
NDMP (http://www.ndmp.org) is essentially a "plumbing" api for controlling data protection/management operations right now and has remained data format independant/neutral. This means that it is relatively easy for backup software companies to "plumb" a backup or restore that uses the native format(s) of each system vendor.
There are 3 basic data formats commonly used in tape backups, cpio, tar & dump (should we include MicroSoft tape format?). Some operating systems such as Solaris currently support all three. However, some systems such as WAFL support one, i.e. BSD's dump. Even though systems vendors have these native commands, most backup software companies choose to write their own agents based on one of the 3 formats discussed and tend to add some "proprietaryness" as they support more and more dissimilar file systems or add performance optimizations such as multiplexing, etc.
NetApp's dump is no stranger to this, we have added support for qtree metadata, NT ACLs, Unicode, NT Streams. However, a standard BSD restore compatible application such as Solaris' ufsrestore can still restore the data, but will only restore NFS attributes. So should you have zero filers in 10 years (heaven forbid) and a pile of NDMP/dump tapes to restore from then as long as you have access to a dump compatible restore program you should be able to manually retrieve your data.
Legato's BudTool product proved that NetApp data could be restored on non-NetApp storage either in a disaster recovery scenario or because that is what the customer wants. We'd like to think that some if not all of the current 7 NDMP-compliant backup software applications that support NetApp could add the same capability.
Marion asks for a standard backup tape format that can be interchanged between NDMP-compliant vendors and we applaud her for it. However, that is beyond the current scope of the NDMP community or the SNIA Backup working group in general.
We think its going to take an awful lot of persuading to get all the current backup software vendors to define a single format and then have all the possible system vendors support it. Most companies have chosen their solution based on trying to differentiate themselves from all the others and we see that continuing for some time.
Cheers, Grant and Greg
Greg Linn Manager, NDMP Development linn@netapp.com 408.822.3752
=========== grant@netapp.com ========== Grant Melvin === === Software Development Manager === === Data Availability & Management === |\ | __ ___ /\ __ __ === Network Appliance === | \ | |__ | /__\ |__| |__| === 475 East Java Drive === | | |__ | / \ | | (R) === Sunnyvale === === California, 94089 === === Tel:(408)822-6761 =========== Network Appliance ========== Fax:(408)822-4578