ARM

Use the ARM application to archive, restore, and move Relativity workspaces between Relativity installations or SQL Servers.

    Notes:
  • This guide contains information about the latest version of ARM. If you're running a previous version, we recommend upgrading to the most current version. Because of the requirement for .NET 4.6.2 to be installed on every Relativity server, ARM 9.5.4 and up is only compatible with Relativity 9.5.162.111 and above. If you are using Relativity 9.5.133.118 or below, ARM 9.5.3 is the most current.
  • The DBMT has been deprecated as of Relativity 9.5.219.30. You should now use the ARM application for archiving workspaces. ARM can no longer be used to convert DBMT exports. Please contact Support for assistance with DBMT exports.

This page includes the following content:

Job types

  • Archive – The archive function assesses a workspace’s primary and critical components and packages those components into an archive. This archive can serve multiple purposes that vary for each organization. For example, you can use this archive to migrate a workspace from one SQL Server to another.
  • Move – The move function acts as a 2-in-1 archive and restore. This function can be used to move a workspace or its components between resources on the current installations of Relativity. One way this function can be useful is in moving a workspace from one SQL Server to another.
  • Restore – The restore function restores a fresh workspace in the target installation of Relativity using an archive created with ARM or a restored SQL database. This function is dependent upon the archive function. You can use this function to restore an existing workspace on a different server.

ARM jobs are executed asynchronously by one or many agents. Multiple agents can work simultaneously to complete tasks for different jobs or can work on separate tasks for the same job. A queuing system determines the priority for jobs that are executed at the same time.

The ARM application uses a staging system that breaks up a job’s work into individual tasks. This staging system shows a job’s progress and gives you actionable information in the case of a job failure. You can see what went wrong, make adjustments, and then resume the job from where it left off.

Stages are executed sequentially; however, the tasks in each stage can be completed simultaneously. If a task fails, the job halts progress in that stage, stores the progress, and then retries the tasks that did not complete.

Security permissions

By default, only system administrators can access ARM. However, you can grant users in other Relativity groups access to ARM using instance security permissions.

See Instance security for more information.

The following minimum security permissions are required to use ARM.

Object security Tab visibility Admin operations
  • N/A
  • ARM parent tab and all child tabs
  • View Admin Repository

Unsupported Relativity data

ARM currently does not currently support the following:

  • The Move operation for Processing data (Invariant stores, job metadata, and unpublished files)
  • Collections data
  • Cached files (this table is truncated)

You should always be on the latest version of ARM for your Relativity version to take advantage of the current ARM functionality. Refer to the following table to see details on ARM / Relativity compatibility for various types of Relativity data that are partially or completely unsupported.

Relativity Version ARM Version Data Grid Analytics Processing Collections data Cached Files
10.1.290.1 10.1.4.18 Archive, Restore, Move Archive, Restore Archive, Restore N/A N/A

Considerations before using ARM

General considerations

Review the following prior to working with ARM:

  • You should ensure that the case workspace is not actively being updated at the time of archiving to prevent inconsistencies in the interim between the archive and the restore.
  • Note: While an archive operation is being performed, ARM will put a workspace into single user mode. This closes any active connections to the database to prevent inconsistencies between the workspace being backed up and the workspace that is restored.

  • You can't restore a workspace to any previous versions of Relativity, but you can restore to the same version or newer versions. For example, you can restore an archived Relativity 9.1.137.12 workspace to Relativity 9.1.172.5 or 9.3.549.1, but you cannot restore an archived Relativity 9.1.137.12 workspace to Relativity 9.1.112.9 or Relativity 8.2.601.84.
  • You can only restore a workspace to the same version of SQL Server or a higher version (this rule applies to both major and minor SQL version differences). For example, you can't restore a workspace from SQL Server 2014 to an environment that uses SQL Server 2012.
  • If a workspace that includes processing was archived before Processing was supported and the workspace is restored, processing cannot be ran again. Instead, create a new workspace, RiP the data to that new workspace, and continue processing from there.

Active Learning considerations

Review the following prior to working with Active Learning projects in ARM:

  • When you archive an Active Learning project, the associated classification index is also archived.
  • When restoring a workspace with an Active Learning project, map your users and permission groups. The users will still exist in the project, but you will need to manually add them back to the queue.
  • If you don't map your permission group, Relativity creates a permission group so the Active Learning project is still usable, but you must add reviewers to the group.
  • As of Relativity 9.7.229.5, Active Learning supports the ARM application. When you archive an Active Learning project, the associated classification index is also archived.

Analytics considerations

Review the following prior to working with Analytics indexes in ARM:

  • If your archived workspace contains Analytics archives an Analytics server must exist in the target workspace resource pool.
  • Archiving Analytics data in RelativityOne is supported as of the Relativity Bluestem release.

dtSearch considerations

Review the following prior to working with ARM:

  • If your archived workspace contains dtSearch archives, the target workspace must have a dtSearch index.

Processing data considerations

Review the following prior to working with ARM:

  • Only processing archives created after Relativity 9.5.196.102 are available to be restored.

When migrating Processing sets using ARM, please consider these items:

  • You must have the Processing Migration Agent installed and enabled in order to restore processing data. If that agent is disabled, you'll receive an error when you attempt to run the restore job.
  • To restore processing data, the Temporary directory field on the Worker Manager Server object in Relativity associated with the workspace in which you're processing data must display the BCP path and a server name (not just local host).
  • You should not have any processing jobs (inventory, discovery, or publish) running in the workspace you're archiving while performing the processing restore job.
  • If you receive an authentication error during the restore job, verify that the IdentityServerURL entry in the Invariant AppSettings table contains a valid address with a fully qualified domain name.
  • For any processing sets that you've restored but have not yet discovered (newly-created sets or sets that were inventoried only), make sure that the data source location (the Source Path field) is valid in the restored environment. If it isn't valid, make sure to update that value for all of your data sources.