Skip to content

42619:nsrndmp_recover: NDMP Service Error: Unable to perform a single file restore on a deduplicated file. Perform a full VBB restore on a separate file system and copy the deduplicated files that you want.”

Celerra NDMP VBB (NVB) file-by-file recovery of deduplicated file system fails.

NDMP File system being backed up with VBB (aka NVB) is deduplicated using Celerra native Deduplication, while recovering those NDMP backup data using file-by-file recovery method, file names restored but files contain 0 bytes. Recovery fails with the error message:

“42619:nsrndmp_recover: NDMP Service Error: Unable to perform a single file restore on a deduplicated file. Perform a full VBB restore on a separate file system and copy the deduplicated files that you want.”

NDMP Volume backup (NVB) “which also referred to as Volume Based Backup (VBB)” can backup up Celerra Data Deduplication-enabled file systems and restore them in full by using the full destructive restore method, Because NVB operates at the block level (while preserving the history of the files it backs up), it does not cause any data reduplication when backing up a deduplicated file system. The data in the file system is backed up in its reduced form. This means that the benefits of the storage efficiency realized in the production file system flow through to backups.

However, Celerra does not support a single-file or file-by-file restore of deduplicated files from NVB backups. Hence, EMC recommends that NVB backups of deduplicated file systems should be used as part of a strategy where a single-file or file-by-file restore is done from locally or remotely replicated SnapSure checkpoints and not from tape. Because the majority of file restores happen within the first few days after their deletion, a SnapSure checkpoint is an efficient and faster way to restore most files.

The only possible way to recover Celerra VBB (NVB) backups of a deduplicated file system is to perform a Celerra Full Destructive Restore (FDR) which requires a complete save set recovery into a raw volume. The original file system of which the backup was done must be converted into a raw volume “which will destroy the production file system”, OR, another raw volume of equal or larger size must exist or be created on the Celerra to direct the save set recovery into.

Considerations & Limitations for Shared Advanced File Type Device (AFTD)

In a Network Attached Storage (NAS) environment, NetWorker operations can be performed concurrently on two storage nodes that share an AFTD. When sharing an AFTD, one storage node can save to a writable volume, while the other storage node either recovers or clones from a read-only volume.

In a Storage Area Network (SAN), NetWorker operations are performed sequentially when two storage nodes share an AFTD. Only one storage node at a time can use the shared AFTD.

So you have to check the following considerations and limitations before implementing this Shared AFTD device:

Shared AFTD considerations:

Review these considerations before sharing AFTDs:

  • Ensure that operating system permissions (directory and file) and sharing are set up properly between storage node hosts for the root user or Windows administrator, to enable proper sharing of AFTDs on the file system.
  •  Use operating system commands to create, copy, or erase directories or files on the sharing disk (such as NAS, JBOD in SAN), to ensure that sharing is possible at file system level between machines. If the operating system does not permit such sharing, then the NetWorker software cannot change that.
  •  To share an AFTD between storage nodes, ensure to:
    • Set the proper Storage Node and Clone Storage Node attributes in the Client resource.
    • Specify for the Staging resource, the proper Device attribute (the one with the read-only volume mounted).
  • To share an AFTD in NAS on Windows storage nodes, ensure to:
    • Start the nsrexecd (NetWorker Remote Exec) service is started by a Windows Administrator account on the storage node.
    • Create the CIFS-mapped AFTD with UNC pathnames that have the appropriate remote user and password specified. An example of UNC path syntax is:   rd=sn_a:\\nas1\path\shared_aftd

Shared AFTD limitations

Shared AFTDs include these limitations:

  • Read-only volumes might be auto-mounted onto the writing storage node during saves. The workaround is to un-mount all sharing instances of read-only and read-write AFTD volumes from all storage nodes, and then correctly remount them.
  •  Limitations on sharing AFTD between storage nodes in NAS/SAN:
    • Supports only homogeneous storage node platforms when sharing AFTD (such as Windows with Windows storage nodes, or UNIX with UNIX storage nodes).
  • The sharing read-write or read-only AFTD volume must be manually un-mounted from one storage node before being mounted on another, in order to prevent a potential out-of-sync state for the volume.
  •  All instances of the sharing read-write or read-only AFTD volume must be manually un-mounted from all of the sharing storage nodes before relabeling the sharing AFTD, in order to prevent potential data loss.

For SAN only:

  • One storage node at a time can perform NetWorker operations.
  • Use operating system or SAN commands to mount or enable the sharing disk on the second storage node after un-mounting or disabling from the first storage node. This ensures that file and directory sharing of the same disk is supported (set up) in the SAN from the sharing storage nodes, allowing the sequential sharing of the disk as an AFTD in the NetWorker software.

The Supported and Not Supported in NMM & Data Domain Integration

To Integrate NetWorker Module for Microsoft Application with Data Domain, Please make sure that following integration prerequisites are met:

Integration requirements:

The NMM Data Domain integration requires the following software:

– NetWorker server 7.6 SP1 or later

– NetWorker storage node 7.6 SP1 or later

– NetWorker client 7.6 SP1 or later

– Data Domain Appliance with Data Domain OS version supported by NetWorker client installed on NMM 2.3

– Data Domain OS 4.8 or later for DD Boost functionality

Supported operating systems:

The supported operating systems are as follows:

– Windows 2003 (x86, x64)

– Windows 2003 R2 (x86, x64)

– Windows 2008 SP2 (x86, x64)

– Windows 2008 R2 (x64)

The Data Domain Boost on NMM client is supported for the following Microsoft applications:

– Exchange Server 2010 (x64)

– SharePoint Server 2010

– SQL Server 2008 R2 (x64)

Data Domain Boost on NMM client is NOT supported for the following Microsoft applications:

– Exchange Server 2003

– Exchange Server 2007

– SQL Server 2005

– SQL Server 2008

– SharePoint Server 2007

– Active Directory

– DPM Server

– Hyper-V

Cumulative Hotfixes included in Build 860

Cumulative hotfix includes the following fixes

NW135020 – nsrwatch core dumps 7.6.2


NW133029 – Autochanger unlimited/32767 License is automatically deleted from NLM when the autochanger slots exceed 32767


NW131986 – Nsrexecd core dumps on Windows 2003 backup server after upgrade to NW7.6.2.2


NW135040 – GSTD Core when marking an unlabelled volume readonly


NW134973 – VADP backup failing for clients in DMZ (internal error occurred: libcurl error: Timeout was reached)


NW135221 – nsr_render_log not rendering all required information


NW132517 – Able to re-label WORM volumes


NW129960 – Save.exe uses 99% CPU usage when Avamar node is used for backup on the client


NW134618 – Image recover for VADP backup reports error “Failed to propagate handle”. Recover successful


NW133248 – lgtolmd poll() error: Invalid argument


VADP backup fails with “Identified an independent disk with label “Hard disk 1″ within the VM. This disk shall not be part of backup.” AND “Parser failed because of a non-NTFS volume inside the VM.”


82788:nsrvadp_save: Identified an independent disk with label “Hard disk 1” within the VM. This disk shall not be part of backup.

There are no available virtual disks for backup.

80432:nsrvadp_save: Parser failed because of a non-NTFS volume inside the VM.

Backup of the non-NTFS volume Success.


Independent persistent disks are not backed up:
VADP does not support the backup and recovery of independent persistent disks. If
such disks are detected during backup, they are skipped and a message is logged that
indicates the disks were skipped. However, during an image level recovery, the disk
is recovered without any data. If using independent persistent disks, you must use
the traditional NetWorker style backup for protecting the data on the independent
persistent disks via the backup client installed inside the VM.

How to mark a ssid/clone id as suspect/notsuspect without using scripts

This article if you have multiple savesets in suspect mode or not suspect mode and you want to change their mode one time without using scripts.

Firstly you will need to run the mminfo command to get the details of the savesets which are marked as suspect, run the following command:

mminfo -avot  -q suspect -r ssid,cloneid,volume

In which command will give you the set of ssid, cloneid and the volume name in which the savesets are marked as suspect.

Copy the output of the suspect save sets in an Microsoft Excel Sheet with the command on the first column and the ssid/clone id in the second column like the following example:

Command                                                 ssid/cloneid

nsrmm -y -o notsuspect  -S                      2617625/1346792

nsrmm -y -o notsuspect  -S                      3615675/1526718

nsrmm -y -o notsuspect  -S                      5317721/1746601

Then copy the list from the Microsoft Excel and then paste it in the Command Line (cmd) of the backup server where the commands will be running one by one automatically.

The list of the entire ssid/clone id will be marked as notsuspect and then can be shown for running a clone job or for a recovery.


The same method is used for deleting multiple save sets or clone id by using the nsrmm -d command

Replace the above example with the right command and the correct SSID or Clone id

Make sure the SSID’s before deletion as once deleted cannot be retrieved.

How to install Networker 7.6.2 client on Debian GNU Linux Or Ubuntu Platforms

As Debian GNU Linux &  Ubuntu are not officially supported platforms for NetWorker by EMC, Also there currently is no out of the box install procedure as there is only .rpm install files available from the NetWorker Installation Packages for Linux. So to be able to install NetWorker on Debian GNU or Ubuntu , you have to use a tool like “alian” to convert the .rpm to .deb format, Here is the steps for this UNSUPPORTED installation.

  1. Install alien package converter on the linux box by running the following :

root@bebo:~# apt-get install alien

  1. Extract the NetWorker Package, then Convert the NetWorker client from rpm format to deb format, as rpm :

root@bebo:~# alien lgtoclnt-7.6.2-5.x86_64.rpm

  1. Install the new converted deb package by running the following ( Take care that name will be changed for amd64 for the x64 packages):

root@bebo:~# dpkg -i lgtoclnt_7.6.2-5_amd64.deb

  1. Start the NetWorker client. Which will create the /nsr directory :

root@bebo:~# nsrexecd

  1. Then kill the NetWorker client daemon ( you have to get the Process ID by the ps -ef | grep nsr command )

root@bebo:~# kill PIDof nsrexecd

  1. Create the /nsr/res/servers file under the /nsr/res directory and put inside it the FQDN of the backup server to be like that:

root@bebo:~# cat /nsr/res/servers


7.   Create the /etc/init.d/networker script file under the /etc/init.d directory and paste in it the following script:

#! /bin/sh

# Copyright (c) 1990-2009, EMC Corporation

# All rights reserved.

# Required-Start: syslog network
# Required-Stop: syslog network
# X-UnitedLinux-Should-Start: portmap
# Should-Start: portmap
# Default-Start: 3 5
# Default-Stop: 0 1 2 6
# Description: EMC Networker. A backup and restoration software package.

case $1 in
        (echo 'starting NetWorker daemons:') > /dev/console
        export LD_LIBRARY_PATH
        if [ -f /usr/sbin/nsrexecd ]; then
                if [ -f /usr/sbin/NetWorker.clustersvr ]; then
                        if [ -f /nsr.NetWorker.local -o -h /nsr.NetWorker.local ]; then
                                if [ -h /nsr ]; then
                                        rm -f /nsr
                                        ln -s /nsr.NetWorker.local /nsr
            (/usr/sbin/nsrexecd) > /dev/console 2>&1
            (echo ' nsrexecd') > /dev/console
        if [ -f /usr/sbin/lgtolmd ]; then
            (/usr/sbin/lgtolmd -p /nsr/lic -n 1) > /dev/console 2>&1
            (echo ' lgtolmd') > /dev/console
        if [ -f /usr/sbin/nsrd -a \
             ! -f /usr/sbin/NetWorker.clustersvr ]; then
            (/usr/sbin/nsrd) > /dev/console 2>&1
            (echo ' nsrd') > /dev/console
        (echo 'stopping NetWorker daemons:') > /dev/console
        if [ -f /usr/sbin/nsr_shutdown ]; then
            if [ -f /usr/sbin/NetWorker.clustersvr ]; then
                (/usr/sbin/nsr_shutdown -q) > /dev/console 2>&1
                (echo ' nsr_shutdown -q') > /dev/console
                (/usr/sbin/nsr_shutdown -q) > /dev/console 2>&1
                (echo ' nsr_shutdown -q') > /dev/console
        if [ -f /usr/sbin/nsr_shutdown ]; then
            /usr/sbin/nsr_shutdown -l
        echo "usage: `basename $0` {start|stop|status}"

8.   Run the following command to update the rc script of that client:

root@bebo:~# update-rc.d networker defaults

9.  Start the NetWorker client process again:

root@bebo:~# nsrexecd

NOW, you have NetWorker running on Debian GNU or Ubuntu platforms , but still it is UNSUPPORTED by EMC.