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";
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.4 JCR Cluster
High availability and ready to heavy-load JCR repository can be implemented using the Clustering service.
on 25/02/2009 at 07:16