Netmail Archive 5.x
Electronic data loss can have a severe impact on your organization, so it is important that archived data and the corresponding indexes are properly managed with respect to integrity and recoverability. This article will explain how to properly backup and restore index server data.
Precautions before Backup
Indexes are created on the index server by Exalead (the indexing engine used by Netmail) to allow Netmail Archive to efficiently search within a huge number of files. The indexing process does not happen immediately. Instead, there is a latency period because data is cached during indexing until it can be permanently written to the system indexes. Because of this delay, it is important to consider the following essential points when preparing to back up the Indexing system:
- Netmail jobs should not be running since the indexes will be unmodifiable for the duration of the back-up and the jobs will be unable to proceed.
Ideally, the task queue of the indexers should be empty. This can be verified by logging into the Exalead Management Console on port 10001 (or through the Unified Netmail Administration Console > Netmail Platform > Index Server > Operations Overview Tab) and navigating to Home > Build Group area and verifying the Tasks in Queue counter.
- Before running a backup of the index directories, the Netmail Indexing (CloudView) service should be stopped (via the Microsoft services console) or frozen via the Exalead API Console to prevent any updates to the indexes. This is discussed in greater detail below in the Backup Procedure section of this article.
Exalead creates a timestamp so it understands when the last indexing job was run (and it only indexes content newer than that flagged with the timestamp). This means that the index server can be backed up at specific intervals, and in the event of a disaster, it will take a relatively short period of time to fully regenerate indexes if they must be restored. The recommendation would be to back up the index server once per week or once per month (depending on your organization’s requirements), so in the event of a failure and system restore, you would only have to regenerate a week/months’ worth of indexes.
Backup and restore of index data must be carried out on an entire cluster basis, meaning all index servers must be backed up at the same time and restored form the same backup set. Once indexing processes are suspended, the backup procedure may proceed. Index processes must be temporarily suspended before backup procedures are initiated to ensure the integrity of the backup. Once indexing processes are suspended, the backup procedure may proceed.
There are two methods described below that can be used to backup the Index data. The most appropriate method may be selected, based on an organization’s needs.
1. Offline Method
This is the recommended method for most organizations and is generally used when the Netmail Indexing service(s) can be suspended for a short time while index files are being copied. Netmail Search will not be accessible and archives will not be available to end users during this time. To backup up the indexes using this method, proceed as follows:
After ensuring that no archive or index jobs are running, access the Windows Services Console and stop the Netmail Indexing (CloudView) service on all index servers.
Backup the data directory from all index server(s). The data directory is typically located in D:\Netmail Indexing\CloudView (drive letter may vary).
Once the backup is complete, restart the Netmail Indexing (CloudView) service.
2. Online Method
This method involves freezing the indexes so that the data can be backed up without any service interruption for end-users. The point of the freeze is to stop/pause all disk writes to the indexes while still servicing queries in order to maintain end-user access.
It is recommended that the online method should be selected only if Netmail Search cannot be interrupted for a short time while index data is undergoing backup. Freezing the indexes can take some time, and it is difficult to predict exactly how long it will take before the process completes. During the freeze process, the indexing engine will completely empty its queues and cache all the indexes in memory, in anticipation of losing access to the data directory. Although it is not possible to track the progress of the freezing process, the Exalead administration console will change the status of the build group to 'disabled' once it has completed.
If the online method is used to backup the indexes, freezing can be done either through the GUI (API console) or using a command line tool (NetmailSearchManager). Both procedures will freeze the Indexing process so the data directories can be backed up, and will then unfreeze indexing. The two procedures are outlined below:
a) API console Method
- To use the API console method, access the Exalead Administration Console on port 10001 and click the API console link in the CloudView Service List on the landing page. It is also possible to open a browser and access the page directly via
- Log in and click the blue Manage box (or the Manage tab at the top right of the page).
Click the master link (left side of page).
Click the operation tab (right side of the page) to display the available operation tasks. On the list of tasks will be the option to freeze/unfreeze the indexes (left column, at the bottom):
Click freeze and then click the send data button. Wait for the build group status to indicate disabled:
After freezing completes, backup the Data Directory from all index server(s), i.e., including index data on any Slave/Worker Index servers in the cluster.
In the API Console, click unfreeze and then send data. This will unpause the impacted index processes.
NetmailSearchManager Command Line Tool Method
Freezing can also be carried out using the NetmailSearchManager command line tool, which is found on the Netmail Archive servers at C:\Program Files (x86)\Messaging Architects\NetmailSearchManager.exe
This tool is a standalone utility which can be copied to backup servers for use with third party backup software scripts as part of scheduled backup procedures.
The syntax of the NetmailSearchmanager utility is as follows:
To freeze operations before backup using the NetmailSearchManager utility, do the following:
- In a CMD window or from a script, freeze the services using the NetmailSearchManager syntax. For example:
NetmailSearchManager url=http://192.168.1.125:10011 command=freeze
- Backup the Data Directory from all Index Server(s) in the cluster (i.e., including all Slave/Worker servers).
- Unfreeze the services using the NetmailSearchManager syntax. For example:
NetmailSearchManager url=http://192.168.1.125:10011 command=unfreeze
As backup requires the indexes to be committed and frozen, the backup process can’t run during Netmail Archive job execution or Netmail Search eDiscovery exercises. This is why Index Server backups are normally scheduled once per week or once per month, rather than including them in daily automated backups. Some third party backup utilities may allow scripting of NetmailSearchManager commands before and after backup to help automate the process.
A restore from backup must be done on an entire index cluster basis (i.e., all Index Servers must be restored form the backup set). The restore should be followed by an incremental indexing job for each archive location that contains data newer than the data that was just restored. This will index everything from the last index checkpoint within the restored indexes.
The restore procedure is as follows:
- As described earlier in this article, stop all Netmail Indexing (CloudView) services on all index servers (ensuring that no Netmail Archive jobs are running).
- Restore the Index Data Directory folder structure from the backup to each index server in the cluster.
- Start the Netmail Indexing (CloudView) services on each index server.
- Run an incremental index job for each archive location which contains data newer than the backup that was just restored, in order to index the newer data.
For more information on Netmail indexing best practices, repair utilities, data integrity, and an index server upgrade guide, please refer to the following links: