V11 SP8

Overview - NetApp File Archiver Agent

Table of Contents


File Archiver for NetApp Agent is installed as a stand alone archiving agent to archive and recover data residing on a NetApp File Server. The Data is always archived on  CIFS share.

The Archived data allows preservation, transparent retrieval, and discovery of information held within file system environment. It reduces the size of data on the primary storage and decreases the duration of backup operations by the corresponding iDataAgent. Migrating data from file systems to secondary, tiered-storage maximizes storage utilization across the enterprise.

The File Archiver for NetApp can optionally create stubs that contain information about the archived data to facilitate end-users with non-browse recovery operations from third-party applications. Migrated data can also be recovered from the CommCell Console using the browse recovery operation whether the stubbing feature is enabled or disabled. Additionally, it employs centralized, policy-based storage to reduce costs and simplify management.

Key Features

The NetApp File Archiver involves the following key features:

Recall Throttling

You can configure the stub recovery parameters, such that, you can set the Maximum Number of Stubs in a Recall Job, Time between recalls and Time to wait after maximum successive recalls limit is reached.

Point-in-Time Restore

You can restore the system state of a client, backed up on a specific date and time.

Stub Pruning

In the archive phase, File Archiver for NetApp will archive files meeting the pre-set archive criteria and, if applicable, put them into a list for the stubbing phase and prune the expired stubs. This helps in secondary storage space reclamation.


The NetApp File Archiver documentation uses the following terminology:

Proxy Client

A proxy client is any computer on which the File Archiver Agent is installed to archive and recover data residing on a NetApp File Server.

Migration Archiving

Migration archiving is a process of periodically moving unused or infrequently used NetApp data on a host computer to secondary storage, thereby reducing the size of data on the primary storage.


The stubbing phase starts after the archive phase succeeds. Stubs are placeholders of the original data after it has been migrated to the secondary storage. Stubs replace the archived files in the location selected by the user during the archive.  However, stubs will only be created if the subclient properties were configured to create them during archive.

Data Recovery


The archived and migrated data can be recovered in any of the following three methods:
  • Recovery of archived files per file paths provided using the CommCell Console.
  • Browse and Recovery of archived files using the CommCell Console.
  • Recall of archived files from stubs using third-party applications like: Windows Terminal or Console window.

Stub Recovery

If the subclient is configured to create stubs, you can perform a recall operation from a Windows computers for recovering the stubs. A recall is any action that causes an open and read to be executed on the stub, which automatically initiates a recovery operation.

Persistent Recovery

Multiple stub recoveries are submitted to the Job Controller as one job called a Persistent Recovery job. The job will wait for approximately 5 seconds in order to allow other stub recovery requests being submitted on the same client to be batched into the same job.

Components of File Archiving Solution in NetApp NAS Environments

Commvault offers an extremely simple, robust and highly resilient file archiving solution for NetApp NAS environments. A typical NetApp NAS archiving solution from Commvault consists of the following components:
  1. CommServe® Master Server
  2. NetApp file server (Content Source Volumes)
  3. Archiving Server (Proxy) client that hosts the Archiver for NetApp agent
  4. Data Movement Path
  5. Tiered Storage Policies

NetApp File Server (Content Source Volumes)

NetApp volumes can be exported using CIFS, NFS or Mixed mode. Archiver for NetApp uses a CIFS protocol to scan, collect, stub and recall the items from the NetApp volumes. NetApp volumes must allow CIFS access for data archiving services (note this can be restricted to our profile); so they can use a standard profile to do this with read and write access to all the volumes.

In order to recall files, we require the alignment of the NIS - AD for end-user permissions (this is only for NFS). That is a mapping component and does not change any of the data on the file servers; rather, it resolves the user read/write requests with the permissions over the NFS and CIFS side.

Archiving Server (Proxy) Client That Hosts the Archiver for NetApp Agent

NAS devices are typically proprietary servers that prevent local installation of third party client software. We use a proxy server context to host our Archiver for NetApp agent and reach in over a CIFS protocol, and that server must be in the same domain or have a trust relationship. The Archiver for NetApp agent component for NAS is hosted on a Windows X64 Server that acts as a “Proxy” server, which can be clustered for high availability or virtualized (run in a VM). The Archiver for NetApp agent can use one or more instances to manage archiving operations against one or more NAS file servers and its shares. Each instance is configured to a NAS file server, and can contain one or more archiving policies (subclient).

  • The client can be run on Windows Server 2003 or above. We recommend using X64 servers with 2 CPUs and 2-4 GB RAM whenever possible for maximum performance. See System Requirements - File Archiver for NetApp Agent.
  • Recommended “fan-in” configuration where one Archiver for NetApp Server can support 1-5 file servers concurrently as different instances depending upon the load on the file servers.
  • Ease of installation – An Archiver for NetApp agent can be installed locally or remotely. The remote install feature provides the administrator with an avenue to install the Archiver for NetApp agent without physically going to each computer. Remote installs allow you to install software on multiple enterprise servers at the same time. When performing a remote installation or upgrade, the install program is launched from a local computer, but the software is installed over the network to other selected remote computers. The processor type need not be the same on the local and remote computers; software can be installed from either a 32-bit or 64-bit local computer to remote computers with any mix of 32-bit and 64-bit processors.
  • Ease of management – The Automatic Update feature allows for the quick and easy installation of updates in your CommCells and Client Computer Group, ensuring that the software is up-to-date. Update packages can either be downloaded automatically to the CommServe Update Cache, or manually pushed to the CommServe Update Cache.
  • High Availability: To provide high availability and resiliency, Archiver for NetApp can be installed on a clustered Windows Server as well as on a Virtual Machine server. The driver for the Archiver for NetApp Agent must first be installed onto all of the physical nodes of the cluster. Once it has been installed onto the physical nodes, the Archiver for NetApp agent can be installed on the virtual server.

Data Movement Path

All data movement operations occur between the Client and the MediaAgent components.

  • Data can be compressed and encrypted within the data pipe based upon the requirements.
  • GridStor™ architecture / alternate paths can also provide failover on those paths to prevent any MediaAgent failure.

File Access Protocols Support

Archiver for NetApp supports any NetApp volume type (i.e., CIFS, NFS or Mixed). Archiver for NetApp requires CIFS backend access; therefore, a file server must have at least a CIFS license.

While considering file archiving for NAS volumes, you also need to determine which production server "owns" the source file system where the files reside.

NFS Exports – If you have a Linux Server that mounts NFS exports (since that server does not actually own the file system at the root of the NFS shares), Archiver for NetApp cannot be used on that server. Instead, you need to determine which server is the root owner of the NFS exports:

  1. If it is another Linux server, then use File Archiver agent for Linux or;

  2. If it is a file server, check if it is NetApp or Celerra to fit our use case above under the File Archiver use case. If it is another file server, then we cannot support it at this time. In that case, please check with the Commvault product team to see if there is any API program from that NAS vendor that we can explore in the future.

NetApp Volumes Exported with CIFS or Mixed Mode

When a user requests access to a file, the file server must compare the user’s security information against the permissions associated with the file. The file server maps the ID from the user’s native system to the ID type expected by the file’s security style.

Windows supports the authentication using Active Directory (AD), whereas UNIX uses NIS (Network Information Services). Both authentication styles - AD and NIS - have their own authentication domains and are not aware of each other’s users and groups rights and permissions. It is important to understand and configure the user rights and permissions from UNIX and Windows environments to ensure recall of the files with appropriate permissions. NetApp provides a utility called “usermapcfg” where you can map an AD user/group with NIS user/group.

"John Smith" == jsmith

Access to a File by a Windows Archive client

  1. Archive client sends NTFS SID to Windows Domain Controller
  2. Archive client receives Windows credentials
  3. Archive client requests the access to the files residing on file server
  4. File server maps Windows username to Unix username using file “usermapcfg”
  5. File server looks up UNID/GID name mapping in either /etc/passwd or NIS
  6. File server grants access to File server if user permissions are validated

NetApp Volumes with NFS Archive clients: For NFS only volumes, we can archive out of the backend if they create a CIFS share restricted just to our profile. In addition, you need to align NIS to AD mapping in usermapcfg file appropriately to translate ACLs.

Access to a File by a UNIX client

  1. User logs onto the client and gets UID/GID from etc/passwd and etc/groups from LDAP or NIS server
  2. UNIX client request access to the data
  3. File server checks exports option when the exports are mounted
  4. File server checks the data requested
  5. File server maps UNIX username to Windows username using file usermap.cfg
  6. File server compares Windows SID against ACL and grants appropriate access rights
  7. If there is no usermap.cfg configured, file server compares UID/GID and grants appropriate access rights

FPolicy Overview

Fpolicy is a file screening protocol which checks for file access requests with a 3rd party (our Archiver for NetApp server). Fpolicy instances for the Archiver for NetApp agent take advantage of built-in services, available in supported Data ONTAP versions called "Fpolicy Screens", to allow archived data residing on a share to be recalled without the need for the File Share Archiver Client component to be installed on end-user computers.
  1. A client requests (read/write/delete) a file from the file server by clicking on the file stub
  2. File server receives the request and announces the screening request to Archive Server (Proxy)/Archiver for NetApp agent by Fpolicy service for write/read/delete operations
  3. Archive Server (Proxy)/Archiver for NetApp agent sends file screen response (Yes/No) to the file server
  4. We then confirm the action (allow/reject) is against our stub and recall/restore the file over the stub.

We do not send the file back over RPC (that is using the CIFS protocol) when we are done. We notify the file Fpolicy thread to release the file for access to the user. Later, re-stubbing may reset the item to a stub if it is unchanged on the next archive job. Archiving Policy Structure Defined:

After installation of the Archiver for NetApp agent, the system automatically creates a default archive set. For the Archiver for NetApp agent, you must create a user-defined subclient in order to perform archiving operations on the client.