Making and Restoring Backups

Backup API

The backup API requires sending a command to the /replication handler to back up the system.

You can trigger a back-up with an HTTP command like this (replace "gettingstarted" with the name of the core you are working with):

http://localhost:8983/solr/gettingstarted/replication?command=backup

The backup command is an asynchronous call, and it will represent data from the latest index commit point. All indexing and search operations will continue to be executed against the index as usual.

Only one backup call can be made against a core at any point in time. While an ongoing backup operation is happening subsequent calls for restoring will throw an exception.

The backup request can also take the following additional parameters:

Backup Status

The backup operation can be monitored to see if it has completed by sending the details command to the /replication handler, as in this example:

http://localhost:8983/solr/gettingstarted/replication?command=details&wt=xml

<lst name="backup">
  <str name="startTime">Sun Apr 12 16:22:50 DAVT 2015</str>
  <int name="fileCount">10</int>
  <str name="status">success</str>
  <str name="snapshotCompletedAt">Sun Apr 12 16:22:50 DAVT 2015</str>
  <str name="snapshotName">my_backup</str>
</lst>

If it failed then a snapShootException will be sent in the response.

Restore API

Restoring the backup requires sending the restore command to the /replication handler, followed by the name of the backup to restore.

You can restore from a backup with a command like this:

http://localhost:8983/solr/gettingstarted/replication?command=restore&name=backup_name

This will restore the named index snapshot into the current core. Searches will start reflecting the snapshot data once the restore is complete.

The restore request can take these additional parameters:

The restore command is an asynchronous call. Once the restore is complete the data reflected will be of the backed up index which was restored.

Only one restore call can can be made against a core at one point in time. While an ongoing restore operation is happening subsequent calls for restoring will throw an exception.

Restore Status API

You can also check the status of a restore operation by sending the restorestatus command to the /replication handler, as in this example:

http://localhost:8983/solr/gettingstarted/replication?command=restorestatus&wt=xml

<response>
  <lst name="responseHeader">
    <int name="status">0</int>
    <int name="QTime">0</int>
  </lst>
  <lst name="restorestatus">
    <str name="snapshotName">snapshot.<name></str>
    <str name="status">success</str>
  </lst>
</response>

The status value can be "In Progress", "success" or "failed". If it failed then an "exception" will also be sent in the response.

Create Snapshot API

The snapshot functionality is different from the backup functionality as the index files aren’t copied anywhere. The index files are snapshotted in the same index directory and can be referenced while taking backups.

You can trigger a snapshot command with an HTTP command like this (replace "techproducts" with the name of the core you are working with):

http://localhost:8983/solr/admin/cores?action=CREATESNAPSHOT&core=techproducts&commitName=commit1

The CREATESNAPSHOT request parameters are:

List Snapshot API

The LISTSNAPSHOTS command lists all the taken snapshots for a particular core.

You can trigger a list snapshot command with an HTTP command like this (replace "techproducts" with the name of the core you are working with):

http://localhost:8983/solr/admin/cores?action=LISTSNAPSHOTS&core=techproducts&commitName=commit1

The list snapshot request parameters are:

Delete Snapshot API

The DELETESNAPSHOT command deletes a snapshot for a particular core.

You can trigger a delete snapshot with an HTTP command like this (replace "techproducts" with the name of the core you are working with):

http://localhost:8983/solr/admin/cores?action=DELETESNAPSHOT&core=techproducts&commitName=commit1

The delete snapshot request parameters are:

LocalFileSystemRepository

LocalFileSystemRepository stores and retrieves backup files anywhere on the accessible filesystem. Files can be stored on "local" disk, or on network-mounted drives that appear local to the filesystem.

A LocalFileSystemRepository instance is used as a default by any backup and restore commands that don’t explicitly provide a repository parameter or have a default specified in solr.xml.

LocalFileSystemRepository accepts the following configuration options:

An example configuration using this property can be found below.

<backup>
  <repository name="local_repo" class="org.apache.solr.core.backup.repository.LocalFileSytemRepository">
    <str name="location">/solr/backup_data</str>
  </repository>
</backup>

HdfsBackupRepository

Stores and retrieves backup files from HDFS directories.

HdfsBackupRepository accepts the following configuration options:

An example configuration using these properties can be found below:

<backup>
  <repository name="hdfs" class="org.apache.solr.core.backup.repository.HdfsBackupRepository" default="false">
    <str name="solr.hdfs.home">hdfs://some_hdfs_host:1234/solr/backup/data</str>
    <int name="solr.hdfs.buffer.size">8192</int>
    <str name="solr.hdfs.permissions.umask-mode">0022</str>
    <str name="location">/default/hdfs/backup/location</str>
  </repository>
</backup>

GCSBackupRepository

Stores and retrieves backup files in a Google Cloud Storage ("GCS") bucket. This plugin must first be installed before using.

GCSBackupRepository accepts the following options for overall configuration:

In addition to these properties for overall configuration, GCSBackupRepository gives users detailed control over the client used to communicate with GCS. These properties are unlikely to interest most users, but may be valuable for those looking to micromanage performance or subject to a flaky network.

GCSBackupRepository accepts the following advanced client-configuration options:

An example configuration using the overall and GCS-client properties can be seen below:

<backup>
  <repository name="gcs_backup" class="org.apache.solr.gcs.GCSBackupRepository" default="false">
    <str name="gcsBucket">solrBackups</str>
    <str name="gcsCredentialPath">/local/path/to/credential/file</str>
    <str name="location">/default/gcs/backup/location</str>

    <int name="gcsClientMaxRetries">5</int>
    <int name="gcsClientHttpInitialHttpDelayMillis">1500</int>
    <double name="gcsClientHttpRetryDelayMultiplier">1.5</double>
    <int name="gcsClientMaxHttpRetryDelayMillis">10000</int>
  </repository>
</backup>

S3BackupRepository

Stores and retrieves backup files in an Amazon S3 bucket. This plugin must first be installed before using.

This plugin uses the default AWS credentials provider chain, so ensure that your credentials are set appropriately (e.g., via env var, or in ~/.aws/credentials, etc.).

S3BackupRepository accepts the following options (in solr.xml) for overall configuration:

An example configuration to enable S3 backups and restore can be seen below:

<backup>
  <repository name="s3" class="org.apache.solr.s3.S3BackupRepository" default="false">
    <str name="s3.bucket.name">my-s3-bucket</str>
    <str name="s3.region">us-west-2</str>
  </repository>
</backup>