Description

Enterprise Vault 14.2 onwards, Elasticsearch is the new indexing engine.

The Elasticsearch engine does not support backing up index data through a filesystem backup.  Instead, it recommends taking snapshots of index data stored in the Elasticsearch index location. There may be an instance where you must restore the snapshot of indexing data taken on one index server on a different index server.

To restore the indexing data snapshot on a different index server, perform the following actions:

1. Identify the snapshot which you want to restore.
2. Restore the above snapshot on the destination index server.

Resolution

1. Back up the SQL databases and the EV server.
2. Identify the snapshot available on the source index server using the command Get-EVIndexSnapshot.
   See the Enterprise Vault PowerShell Cmdlets guide for more information.
   
3. Ensure both the servers have the same index snapshot location configured.
   If the same index snapshot location is not configured on the destination server, you must set that up by using the command Set-EVIndexSnapshotLocation.
   See the Enterprise Vault PowerShell Cmdlets guide for more information.
4. Restart the Enterprise Vault Indexing Service on the destination index servers.
5. Determine the index snapshot location configured on the destination index server by using the command  Get-EVIndexSnapshotLocation.
   See the Enterprise Vault PowerShell Cmdlets guide for more information.
   
6. Manually copy the index snapshot repository folder from the source index server(path displayed on the output for step 2 above) to the index snapshot location configured on the destination index server.
7. Restore the index snapshot on the destination index server by executing Restore-EVIndexSnapshot command on that server.
   See the Enterprise Vault PowerShell Cmdlets guide for more information.
8. Stop Enterprise Vault Indexing Service on the destination index server where you have restored the index snapshot.
9. Update all the index volumes of the first index server to the other index server. Run the following SQL queries in SQL Server Management Studio:
   1. Determine the index location by running the following SQL query in SQL Server Management Studio:

      USE EnterpriseVaultDirectory

      SELECT CE.ComputerName, CE.ComputerNameAlternate, IRP.IndexRootPathEntryID, IRP.IndexRootPath, ISE.ServiceEntryID, ISE.Description

      FROM ComputerEntry CE, IndexingServiceEntry ISE, IndexRootPathEntry IRP

      WHERE CE.ComputerEntryID = ISE.ComputerEntryID AND ISE.ServiceEntryID = IRP.IndexServiceEntryID

      ORDER BY CE.ComputerName

      Note: Take note of the IndexRootPathEntryIDs for the old index root path and the new index root path.

   2. Update the index locations by running the following SQL query in SQL Server Management Studio:

      USE EnterpriseVaultDirectory
DECLARE @OrigIndexRootPathEntryId EVGUID
DECLARE @NewIndexRootPathEntryId EVGUID

      SET @OrigIndexRootPathEntryId = 'old IndexRootPathEntryId'
SET @NewIndexRootPathEntryId = 'new IndexRootPathEntryId'
            
-- Update the index volumes to point at the new location
UPDATE IndexVolume
SET IndexRootPathEntryId = @NewIndexRootPathEntryId
WHERE (IndexRootPathEntryId = @OrigIndexRootPathEntryId)

      
      Note: The old IndexRootPathEntryId should be replaced with the IndexRootPathEntryId the value returned for the old index root path in step 9-1 above. The new IndexRootPathEntryId should be replaced with the IndexRootPathEntryId the value returned for the new index root path in step 9-1.
10. Inform Enterprise Vault that it needs to update the paths of the volumes on the Enterprise Vault service startup by running the following SQL query in SQL Server Management Studio:
    UPDATE IndexingServiceEntry
SET IVSyncNeeded = 2
WHERE ServiceEntryId IN (SELECT IndexServiceEntryId FROM IndexRootPathEntry WHERE
IndexRootPathEntryId IN(@OrigIndexRootPathEntryId, @NewIndexRootPathEntryId))
11. Following completion of the SQL script, restart all the Enterprise Vault Services.
     

Note: When the Indexing Services start up, they will synchronize their respective index volume metadata, depending on the number of index volumes associated with the index root path relocation, this may take some time. The progress can be monitored in the Event Log.

From Enterprise Vault 14.5 onwards, Elasticsearch index snapshots save the State.dat index metadata to the snapshot location. Upon restoring the snapshot, the index metadata in the State.dat files is also restored. This enables the indexing engine to synchronize the index data automatically.

Note:
The snapshot and restore operation is limited only to the Elasticsearch index. If you want the Elasticsearch index and the archived items in storage to be backed up and restored at the same point in time, you must take a snapshot of the entire Enterprise Vault machine and its related machines (such as SQL server, domain controller (DC), storage server, and so on).