Search index backup

Search index backup

1 Manual backup (file copy)

It can be useful for some reason. The backup may be performed manually or using third part software.

You can make a copy of the search index ($AS_HOME/temp/jcrlucenedb). And use it to replace the current index by this copy in case of an index damage or lost.

All repository changes that are applied between the index backup and the point of time when the backup index is restored, are not in the index and those modifications will not be found when searching. The modifications exist in the repository, but do not exist in the search index. And those changes will not be automatically reindexed.

For example: You have configured the workspace index to be in the "/index/workspace" directory.

  • make a backup of the search index - copy the content of the "/index" directory;
  • add the node "/anynode" to the workspace. Now this node exists in the workspace database and the search index has information about this node, so you can find it using query select * from nt:base where jcr:path="/anynode";
  • rollback to the last backup - replace current "/index/workspace" directory by the backup;
  • node "/anynode" still exists and is accessible in the workspace (Session.getItem("/anynode")), but you can't find it via the search query select * from nt:base where jcr:path="/anynode";
If you want to find changes made after update you have to reindex whole workspace content. One way to do this is to stop the repository container and delete the "/index/workspace" folder. The workspace database content will be reindexed on repository startup.

2 Consistency Requirements

To have the workspace content consistent with the search index, the workspace database and the index directory should correspond to the same state. In case of an external (manual) backup the database backup and the index directory backup should be performed on a stopped/unmodifiable repository.

Only in that case the repository content and the search index will be consistent.

3 JCR Backup Service

To get a hot-backup, which is executed on the fly, it's possible to use the Backup service which is available as a JCR Extension.

Backup service supports full and incremental backup types. A Scheduler is available.

4 JCR Cluster

High availability and ready to heavy-load JCR repository can be implemented using the Clustering service.

Cluster service supports persistent and proxy modes.
Tags:
Created by Sergey Karpenko on 05/19/2008
Last modified by Sören Schmidt on 02/25/2009

Products

generated on Fri Sep 03 00:19:28 UTC 2010

eXo Optional Modules

eXo Core Foundations

Recently Modified


Copyright (c) 2000-2010. All Rights Reserved - eXo platform SAS
2.4.30451