Administrator Guide

Both supported backup types (dump and tar) support incremental backup. The algorithm for traversing the backup target directory is the
same. However, because inode-based file history generation has different requirements to support DAR, the backup data stream
generated is different:
• dump: Each directory visited will be backed up and a file history entry will be generated. It does not matter whether the directory has
changed.
• tar: Backs up and generates a file history entry only for the directories that have changed.
Therefore, the amount of data backed up using a tar backup will be less than that of a dump backup. The size difference depends on the
number of directories in the backup data set.
Handling Hard Links
NDMP backup handles hard link files in the most efficient way by default. That is, the hard link files’ data content will be backed up only
once. After the backup operation encounters the first hard link file and backs up its content, the backup process remembers the inode
number of that file. Subsequently, when the backup operation encounters files with the same inode number, only the header is backed up.
When this backup data stream is restored, the hard link files will be recovered as hard link files.
This mode of backup could create a problem in the case of a selective restore when the selected files or directories to be restored contain
hard link files that are not the first instance encountered during backup. In this case, the restore fails and an NDMP message is sent to the
DMA server indicating the first instance of the file that should also be included in the selective restore.
To work around this problem, change the behavior during backup. If a backup is started with the DEREF_HARD_LINK environment
variable set to Y, the backup will back up all instances of the hard link files as if they were regular files, rather than just backing up the first
instance of the hard link files. In this case, a selective restore will always have the file data. The disadvantage of this option is that backups
might take longer and more space is required to back up a data set with hard link files.
Backing Up NAS Volume Data Using NDMP
The FluidFS cluster does not use a dedicated IP address for backup operations; any configured client network address can be used. Data is
sent over Ethernet. Multiple NDMP backup and restore sessions can run at the same time with a maximum of 48 sessions per NAS
controller. To minimize the impact of NDMP backup processing on system performance, schedule NDMP operations during off-peak
times.
About this task
After you configure NDMP in a FluidFS cluster, the NDMP server monitors the client network for backup requests from the DMA servers.
The DMA server then accesses (mounts) the NAS volumes that it intends to back up and initiates the backup operations.
Figure 42. NDMP Backups
Keep the following considerations in mind when backing up NAS volume data using NDMP:
• NDMP does not provide high availability (HA). If a backup session is interrupted due to connection loss, the session is terminated.
• Manually deleting the temporary snapshot for the current backup session is not allowed and will immediately terminate the session.
• If a backup session is terminated with an error, the temporary snapshot might be left in place, and the system will delete the snapshot
automatically.
The following steps outline the process for backing up NAS volume data with NDMP:
Steps
1. The DMA server creates a connection to the FluidFS cluster IP address.
2. The NDMP server on the FluidFS cluster creates a temporary snapshot of each NAS volume that the DMA server designated for
backup. Alternatively, when performing a backup of replication target NAS volumes, the FluidFS cluster does not create a dedicated
NDMP snapshot. Instead, it uses the base replica snapshot from the last successful replication.
Temporary NDMP snapshots are named using the following format: ndmp_backup_session_id_controller_number
416
FluidFS Administration