Skip to main content

How to Back Up and Restore Solr Using Snapshots or Scheduled Operating System Backups

Updated

How to Back Up and Restore Solr Using Snapshots or Scheduled Operating System Backups

Applies to:  This applies to DocuShare 7.5, 7.6, 7.7, 8.0, and 8.1 (when released) installations that are running Solr. The Solr core layout and backup and restore procedure described here are unchanged across these releases.

 

Before you begin:  Consider the disk space required for backups. Create and verify a current backup of the DocuShare database, document repository, configuration, and license information before performing a snapshot, restore, or other maintenance operation. Do not proceed without a usable recovery backup.

 

Two Supported Backup Methods

There are two ways to back up the Solr index. Choose the method that matches your environment and maintenance window.

  • File-level snapshot or scheduled operating system backup: stop DocuShare and Solr, then copy the Solr core directories directly. This is the simpler method but requires an outage.
  • Solr Replication API: send HTTP backup and restore requests to the running Solr instance. This method does not require stopping Solr, but it requires Solr to be running and reachable at the time of the request.
Do not mix these up:  The two methods need opposite service states. The file-level method requires DocuShare and Solr stopped. The Replication API method requires Solr running. Do not attempt the Replication API commands while Solr is stopped for a file-level snapshot.

 

Replica configurations:  This procedure assumes the default DocuShare Solr configuration. If your environment does not use replicas, or uses a different topology, a manual backup and restore process using command-line curl commands and scripts may be required instead. Confirm your configuration before relying on either method below.

 

Method 1: File-Level Snapshot or Scheduled Operating System Backup

To Prepare Solr for a Snapshot or Scheduled Backup

  1. Stop the DocuShare service.
  2. Stop the Solr service.
  3. Back up a copy of DocuShare_shard1_replica_n1 and DocuShare_shard2_replica_n2, located under <dshome>\Solr\server\solr, using your standard backup procedure of taking a snapshot or an operating system level backup.
Note:  Verify the backup file size for the directories to ensure that your backup file sizes match the original size.

 

  1. Start the Solr service.
  2. Start the DocuShare service.

To Restore Solr From a Snapshot or Scheduled Backup

  1. Stop the DocuShare service.
  2. Stop the Solr service.
  3. Restore the snapshot, or if an operating system level backup was taken, restore the <dshome>\Solr\server\solr\DocuShare_shard1_replica_n1 and <dshome>\Solr\server\solr\DocuShare_shard2_replica_n2 directories from backup.
  4. Start the Solr service.
  5. Start the DocuShare service.
  6. Open a command prompt or terminal window as Administrator and change into the <dshome>\bin directory.
Windows:
dsindextool.bat -reindexSince MM/dd/yyyy-MM/dd/yyyy index_all

Linux or Solaris:
dsindextool.sh -reindexSince MM/dd/yyyy-MM/dd/yyyy index_all

 

Date range is half-open:  Set the first date shortly before the backup was created. The start date is inclusive and the end date is exclusive. Example: dsindextool -reindexSince 05/01/2024-05/30/2024 index_all re-indexes all objects with a modified or create date at or after 05/01/2024 (inclusive) and before 05/30/2024 (exclusive). If you set the end date to the last day you need covered, that day's changes will not be reindexed; set the end date to one day past the last day you need covered.

 

Method 2: Solr Replication API (Optional Alternative)

Separate procedure with a different service state:  This optional method does not replace a complete backup of the database, document repository, configuration, and license information. It requires Solr to be running; do not use it in place of the file-level method above during a maintenance window where Solr is stopped.

 

The Solr Replication API sends HTTP requests directly to each shard's replication endpoint. Replace localhost and the port with the values configured for your environment; the default Solr port is 8983.

Backup

http://localhost:8983/solr/DocuShare_shard1_replica_n1/replication?command=backup&name=DS_shard1&location=C:\Solr\backup
http://localhost:8983/solr/DocuShare_shard2_replica_n2/replication?command=backup&name=DS_shard2&location=C:\Solr\backup

 

The name parameter generates the backup snapshot name, in the form snapshot.<name>. Confirm that the location contains files named snapshot.DS_shard1 and snapshot.DS_shard2. Check the status of a backup request with:

http://localhost:8983/solr/DocuShare_shard1_replica_n1/replication?command=details
http://localhost:8983/solr/DocuShare_shard2_replica_n2/replication?command=details

 

Restore

http://localhost:8983/solr/DocuShare_shard1_replica_n1/replication?command=restore&name=DS_shard1&location=C:\Solr\backup
http://localhost:8983/solr/DocuShare_shard2_replica_n2/replication?command=restore&name=DS_shard2&location=C:\Solr\backup

 

Confirm restore completion using the same command=details request for each shard before resuming normal use.

Support Guidance

If a backup or restore request fails, do not repeatedly retry it. Preserve the request URL, the response, Solr logs, and your DocuShare version and patch level, then contact Xerox DocuShare Support.

  • DocuShare version and patch level, operating system, and installation type.
  • Which method was used, file-level snapshot or the Replication API, and the exact commands or paths involved.
  • The Solr host, port, and collection or shard names in use.
  • Relevant Solr and DocuShare logs covering the time of the operation.

Related articles