Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
2.6
-
None
-
None
-
Linux 2.6.18-308.el5 #1 SMP Fri Jan 27 17:17:51 EST 2012 x86_64 x86_64 x86_64 GNU/Linux
Description
We have been requested to implement a backup/restore mechanism for our JCR repository. As we are using versioning for a given set of nodes we need to restore the entire version storage. As the JCR import/export API does not cope well with overwriting/updating the version storage, the only solution for us was to backup and restore the database (Oracle) + backup/restore of indexes (to avoid time spent in recreating indexes if the DB data volume is high).
After doing the above mentioned database restore + indexes restore, we have found that one frozen node corresponding to version 1.0 of a node cannot be located using a JCR SQL2 (the query is used by our app logic and works for all other cases). We had a look on the indexes but we cannot find any information related to that frozen node.
We tried to start the JCR repository with consistencyEnabled/consistencyFix (for persistence manager) as true and checkConsistencyEnabled/forceConsistencyCheck/autoRepair as true (for search index component). No errors have been reported so there was nothing to fix.
We tried also with an offline checker tool from Hippo CMS (http://maven.onehippo.com/maven2/org/onehippo/cms7/hippo-addon-checker/) but again no errors have been reported.
If I am using the JCR API and accesing the node with the jcr uuid identifier I have no problems in location the node (probably because indexes are not involved in the process).
For us the problem is major because this is data inconsistency between the database and the indexes.
We would appreciate any suggestion.
Thanks.