Backup and Restore in Apache Solr Cloud

Solr Cloud by design is highly available and Fault-tolerant. But there is still a possibility of a hardware failure, your collection could get corrupted because of faulty application code, operations team accidentally deleting a shard or it could be anything that leaves your collection in an unstable state.

Backup the collection data and config:

Backup for Solr in general is a very quick and easy process. If you are an operations person you would really like its simplicity.

Before we start backup in Solr Cloud there are a couple of important pointers that need to be taken into account:

• We would need a file system that is mounted on all the Solr Cloud nodes. They can be as simple as an NFS file system or an file systems like a Gluster FS / GPFS.
• The reason behind this requirement is because the backup uses the collection API to read the data across multiple shards which are hosted on different nodes.
• The backup image includes the data, Collection configuration, and Zookeeper configset which are used to restore the collection.

Backup Command:

http://localhost:8983/solr/admin/collections?action=BACKUP&name=myBackupName&location=/path/to/my/shared/drive&collection=myCollectionName

This is a sample backup script that I use to backup all my collections in a single Solr Cloud instance:

#! /bin/bash

#Declare the variables

env=$1

#This is the name of the env(UAT/DEV/SYS/PROD) DC=$2

# What is the DC does this instance of SolrCloud belong to

dt_tsmp=`date +’%Y-%m-%d:%H:%M:%S’`

#Get the list of collections that exist in this solr instance

curl -u ${solr_code} “http://`hostname -s`:8983/solr/admin/collections?action=LIST” | jq ‘.collections | .[]’ > test ; sed -e ‘s/”//g’ test > list_colelctions collection=`cat list_colelctions`

for i in ${collection}

do curl -u ${solr_code} “http://`hostname -s`:8983/solr/admin/collections?action=BACKUP&collection=${i}&location=file:////solr_backup//${env}//${DC}//&name=${i}${dt_tsmp}”

done

Restore:

Just like the backup process, the restore process also has few pointers that we need to take into account:

• The collection name that we are going to use for restoring a backup image should not belong to an existing collection.
• Delete the existing collection and clear its configset from Zookeeper when you are restoring to an already existing collection. If the configset already exists in Zookeeper then those config files will be reused by Solr.
• The restored collection will have the same number of shards as the Source collection once it’s restored.
• We still need the filesystem that has the backup image available on all the nodes that you will be restoring the collection.

Restore Command:

http://localhost:8983/solr/admin/collections?action=RESTORE&name=myBackupName&location=/path/to/my/shared/drive&collection=myRestoredCollectionName

Note:

Location: Location of the backup snapshot file. If not specified, it defaults to the data directory.

Collection: Name of the collection that you like to restore to.

name: Directory name of the backup.

Conclusion:

Having a backup and restore strategy for any data platform is a key checkpoint for successful production implementation, It applies even for a distributed system like Solr Cloud. Testing the restore process multiple times to make it fool proof and practicing it multiple times until you become familiar is very essential.