[MGNLBACKUP-45] Restore on Derby fails with 'Failed to persist restored nodes with message deadbeef-face-babe-cafe-babecafebabe' Created: 24/Oct/11  Updated: 29/Mar/22  Resolved: 04/Nov/15

Status: Closed
Project: Backup
Component/s: None
Affects Version/s: 1.0.2
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Edgar Vonk Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

MacOS X 10.6.8, Derby, Magnolia 3.6.8


Attachments: Text File magnolia_restore_log.txt    
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Team: Nucleus

 Description   

I am trying to use the Magnolia Backup module (v1.0.2) to sync all content from our production environment running Oracle as database to a local machine running Derby as database.

I understand from this discussion and from the documentation of the module that this should be possible?

I have tried to do this using the following steps:

  1. Export from the authoring production environment using the Magnolia backup module. This resulted in a backup of 3GB, mainly due to the BLOBs which we store on the file system (on production).
  2. Change the repoConfig.gz by replacing all instances of the Oracle persistence manager by the (default) Derby persistence manager.
  3. Install an empty Tomcat 6 on my local machine.
  4. Deploy our customized Magnolia WAR including our custom module. This is identical to the version running on production except that locally we use Derby instead of Oracle.
  5. Start the server once and perform the installation.
  6. Stop the server and remove the repositories folder.
  7. Import the backup locally into the magnoliaAuthor instance using ./restore -backup 20111019_magnolia_backup_production_derby -webapp /Applications/Dev/apache-tomcat-6.0.32/webapps/magnoliaAuthor

However this fails with the mentioned error. See the attached log file for details.

Any ideas?

I also ran into out of memory issues regarding the heap space but fixed that by increasing -Xmx to 1024M in the restore script.

Another thing I noticed is that that Magnolia backup tool does not seem to recognize that for the magnoliaAuthor instance we do not use the default/magnolia.properties but instead magnoliaAuthor/magnolia.properties:

 Loading configuration at /Applications/Dev/apache-tomcat-6.0.32/webapps/magnoliaAuthor/WEB-INF/config/default/magnolia.properties

But I fixed that by manually re-arranging some stuff for the import.



 Comments   
Comment by Jan Haderka [ 24/Oct/11 ]
ERROR  info.magnolia.module.backup.Backup Backup.java(restore:383) 24.10.2011 11:18:37  Failed to restore property data of node 429fb8b6-79ce-46a1-ac9e-34205d3e925f
java.io.IOException: /42/9f/b8b679ce46a1ac9e34205d3e925f/%7bhttp%3a%2f%2fwww.jcp.org%2fjcr%2f1.0%7ddata.0.bin: the specified resource does not exist

Seems like inconsistency in your repo (or backup) - the binary for this node is missing from the backup and can't be restored.
As for the other error:

WARN   org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager AbstractBundlePersistenceManager.java(store:592) 24.10.2011 11:19:05  Deleted node state's parent is not modified or deleted: deadbeef-cafe-babe-cafe-babecafebabe/deadbeef-face-babe-cafe-babecafebabe

That looks like if the restore was trying to recreate whole workspace as part of another workspace ( deadbeef-face-babe-cafe-babecafebabe is always UUID of the root node).
Could you attach your modified repoConfig? Please remove all your passwords from it first and/or create a support ticket and attach the file there to keep it private.

Comment by Edgar Vonk [ 25/Oct/11 ]

Hi Jan,

thanks for the quick reply!

Yes, it seems you were right about the inconsistency. I think this relates to the BLOBs. When I had a look at the Magnolia source environment I found out that the links to the BLOBs (mainly PDFs in de DMS) were all broken. We tried to find the problem but failed to find anything (nothing interesting in the logs) and ended up restarting Magnolia (Tomcat) and that resolved the issue. Either the inconsistency in the repo was already there and that explains why the backup was not correct or the backup process created the repo inconsistency. My guess is that it was the former..

Unfortunately I cannot recreate the backup easily because of time constraints but will look at it at a later stage.

About the second point: what I did was try to restore the backup in the default Derby database. But.. I first removed the entire repositories folder (as per documentation) which means I also removed the entire Derby database with it.. I guess that is not the idea of the restore process? Could this be the reason for the error? Should I configure Magnolia to keep the Derby DB outside of the repositories folder?

cheers,

Edgar

Comment by Michael Mühlebach [ 04/Nov/15 ]

Given the thousands of other issues we have open that are more highly requested, we won't be able to address this issue in the foreseeable future. Instead we will focus on issues with a higher impact, and more votes.
Thanks for taking the time to raise this issue. As you are no doubt aware this issue has been on our backlog for some time now with very little movement.
I'm going to close this to set expectations so the issue doesn't stay open for years with few updates. If the issue is still relevant please feel free to reopen it or create a new issue.

Generated at Sun Feb 11 23:25:03 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.