Skip to main content
NetApp Knowledgebase

Network Data Management Protocol (NDMP) / dump phases description

 

Applies to

  • Data ONTAP 7mode
  • clustered Data ONTAP 8
  • ONTAP 9

Answer

Terms

Some key terms used in the description of the dump phases are:

  1. Inode: Every file on a file system has an identifier associated with it. This id is called the inode. A file system typically has inodes pre-allocated on it. The output for df -i in ONTAP shows volume's total number of used inodes and total number of free inodes. For the purpose of this document we will use the terms inode and file interchangeably.
  2. Inode file: This is a special file on the file system that contains a list of all the inodes in a volume and their details.
  3. Inode map: An array that has as many elements as the number of inodes on the volume. The inode number serves as the index for its corresponding entry in the array. A value of 1 in any entry indicates that the corresponding file will be present in a given backup.
  4. Offset map: An array that has as many elements as the number of inodes on the volume. The inode number serves as the index for its corresponding entry in the array. If an inode exists in a backup, its corresponding entry contains the physical address on tape that marks the beginning of the file data within the backup image.
Dump phases

For backups that are initiated by NDMP with file history turned on, dump must generate File History in Phase III and IV as well as the offset Map in Phase IIIb. Generating file history and the offset map adds some cost to NDMP backups in these Phases, but allows NDMP to provide invaluable features such as backup indexing, DAR, and Enhanced DAR. For more information about file history, see FAQ: NDMP File History.

  • Phase I: dump generates the list of files that need to be backed up. The output of this phase is what is called an inode map. The inode map contains an entry for every inode on the volume. The inode that is to be backed up has its corresponding entry set to 1 whereas the inode that is not to be backed up has its entry set to 0.
  • Phase II: dump writes the inode map generated in Phase I to the tape.
  • Phase III: dump writes the entire directory structure for the backup dataset to tape. If enabled, file history for directories is generated and communicated to the backup application during this phase.
    • Phase IIIa: ACLs Phase: In this phase dump backs up ACLs for the data set to the tape. This step may take more time if a lot of files within the data set have ACLs.
    • Phase IIIb: This Phase is executed only for NDMP backups that have File History turned on.The output of this phase is the offset map. For each file on any given backup, the offset map contains the physical address on the tape that marks the beginning of the file within the backup image.
  • Phase IV: This phase dumps the actual file data on tape. This phase operates in the inode order. As a result, a smaller inode number is guaranteed to be found before a larger inode number. If enabled, file history for files is generated and communicated to the backup application during this phase.
  • Phase V: This is a duplicate of Phase IIIa. This is what traditionally existed in NetApp native dump. This phase is retained for reasons of backward compatibility, but is a no-op in modern versions of ONTAP.
Qtree/Volume dump vs. non-Qtree sub-directory dump

Phase I of dump behaves differently based on whether the user initiated the backup of a Volume/Qtree or a non-Qtree sub-directory.

With sub-directory dumps, each directory and file below the specified root of the backup must be examined to determine whether it should be included in the backup.
This is a time-consuming operation especially if the sub-directory contains several million inodes (files).

With Volume and Qtree based backups, it is not necessary to go through the entire directory tree to determine what needs to be backed up. Instead ONTAP can go through the inode file for the backup snapshot. By just looking at the inode file, it is possible to determine whether the inode exists and whether it is a part of a given qtree/volume.

Using the inode file is a much faster and efficient process as compared to the directory traversal. The inode file does not contain enough information to be able to do the same for non-qtree sub-directory dumps, so it is recommended to backup Qtrees and Volumes whenever possible rather than non-Qtree sub-directories.

Note that using the exclude NDMP environment variable causes Qtree and Volume dumps to perform the slower directory traversal method as well. If backup speed is a factor, avoid using exclusions in NDMP-initiated dump backups..

Additional Information

Add your text here.