Direct attached NDMP and Remote NDMP Backup

        NDMP Direct attached Backup also known as '2-way backup'

              

              Remote NDMP Backup also known as '3-way backup'

              

               Please Note : For Remote NDMP, you can also use 'Disk Library'

                      Request : If you do copy these images, please give the credit.

Vserver tunneling in Cluster Mode Ontap with CommVault

What is Vserver tunnelling in Cluster Mode Ontap with CommVault Array Management GUI?

The mechanism of accessing Vserver APIs through a cluster-management interface is called Vserver tunnelling.  Data ONTAP responds to a tunnelled API based on the tunnel destination, target interface and the API family.

For example:
Data ONTAP Vserver APIs can be executed if they are sent through a cluster management LIF to an Admin Vserver.

How to disable NDMP File History for CommVault DMA

This articles applies to NetApp FAS, 7-mode and cDOT, and CommVault

What is file history and how is it communicated?
File history is generated during an Network Data Management Protocol (NDMP) backup of a volume hosted on NetApp storage using the dump engine. File history enables a Data Management Application (DMA) to build an index database over all the files in a backup. This database enables users to locate which backup contains a particular file, when that file was modified, and other useful meta data.

File History feature provides two benefits:
1. Provide a human-readable user interface to backup data.
2. Provide a basis for Direct Access Recovery (DAR). DAR allows a DMA to access files / directories directly on tape without having to traverse the entire backup. This allows for quicker file and directory recovery operations.

During what PHASE does File History generation occurs?
File history generation occurs in phase 3 and 4 of the dump process

File History can also lead to slower backups in certain environments due to 'backup pressure' as known in the NetApp world.
In general, file history adds overhead to a NDMP backup. A backup will typically always run faster with file history disabled than a backup with full file history capabilities, even with no other performance issues. This is due to processing overhead required to generate, communicate, and ingest the additional data.

Three main causes for slow NDMP Backup with FILE HIST = T, turned on.
1. Lack of computing resource on DMA [Physical/VM] - DMA = Media Agent
2. Slow Disk performance of the Index Drive.

TIPS:
Put Index Cache on SSD
Put Job results directory on SSD
<>:\Program Files\CommVault\Simpana\iDataAgent\JobResults

3. Slow/Lossy Network between DMA & NDMP Server.

I would like to disable FILE HIST temporarily for NDMP backups with my CommVault DMA, how can I do so ?
It's simple, just add the following regkey to your DMA [Media Agent] server.

Please note: Tested on v10, but should work on v11 as well.

Under the 'NAS' key, create another key (not a value) named "BackupHostOptions":

HKEY_LOCAL_MACHINE\SOFTWARE\CommVault Systems\Galaxy\Instance001\NAS\BackupHostOptions

In that key add a string value having exactly the name of the NAS client and set it to HIST=N, as shown in the figure below.

Could not open an NDMP connection to host. Please verify the NDMP server is running on that host when adding NAS iDA to CommVault v10 & 11.

Following error is seen when adding a NAS iDA NetApp 7-mode client in the CommCell v10.

Customer reported : Telnet to Port 10000 on the NAS Host works.

Telnet to Port 10000 is a good troubleshooting step, however in cases like this, it isn't helpful.

Reason : Telnet to Port '10000' only signifies NDMP server is listening, but we need to find out why is it refusing to speak, and reporting this error - 'Please verify NDMP server is running on that host'.

Cause: NDMP server [FILER] is definitely listening on Port 10000, but it is refusing connection requests, b'cos its NDMP memory pool is Full.

Initial troubleshooting steps:
Ensure NDMP is turned on.
FILER>options ndmpd.enable
ndmpd.enable           on

That indicates, NDMP server is definitely listening, however there is something which is preventing the communication.

First clue, as reported in EvMgrS.log: Connection refused by the NDMP server

This is the first clue, which kind of give us an indication that the NDMP server is unable to accept any more connections.

Second clue, look for stale NDMP sessions on the filer:
FILER>backup status
This will tell you if there is any existing NDMP backups running on the filer. In this case, there were none.
FILER>ndmpd status

In this particular case, we found there were lot of stale NDMP sessions sitting idle and doing nothing, in other words, they were simply holding on to NDMP memory and hence stopping NDMP to accept new connection.

Please note, If there is nothing in the backup status output, then you can safely kill all the stale ndmp sessions that are shown via ndmpd status output.

Solution:
1. Kill all the stale sessions.
FILER>ndmpd killall

2. Turn off and turn On NDMP [This step may be required, but not necessary]
FILER>options ndmpd.enable off
FILER>options ndmpd.enable on

3. Try to add the NDMP NAS iDA client once again, this time it should succeed.


Please Note: For more information on available ndmpd commands, simply type 'ndmpd' on the putty console for 7-mode;
FILER> ndmpd
usage:  ndmpd [on|off|status|probe [<session #>]|kill <session #>|killall|