Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backups broken in develop #2767

Closed
wolfgangmm opened this issue May 30, 2019 · 3 comments · Fixed by #2771
Closed

Backups broken in develop #2767

wolfgangmm opened this issue May 30, 2019 · 3 comments · Fixed by #2771
Labels
bug issue confirmed as bug high prio

Comments

@wolfgangmm
Copy link
Member

wolfgangmm commented May 30, 2019

What is the problem

Restoring a backup created with current develop will result in all binary files missing. It doesn't matter if you restore into a remote or local instance.

The __contents__.xml descriptors inside the backup are missing entries for all binary files.

Backup/restore was tested extensively not long ago, so this bug must have been introduced very recently.

Describe how to reproduce or add a test

A backup is attached. On a fresh database, install a package which is not contained by default, e.g. the demo app. Create a backup via the dashboard and check the __contents__.xml files contained inside. They should be missing entries for all binary resources. Restoring the backup will thus miss all binary resources.

Context information

Please always add the following information

  • eXist-db 96993a5
  • Java version 1.8.0_181
  • Operating system (MacOs)

full20190530-1459.zip

@wolfgangmm wolfgangmm added bug issue confirmed as bug high prio labels May 30, 2019
@wolfgangmm wolfgangmm added this to the eXist-5.0.0-RC8 milestone May 30, 2019
@adamretter
Copy link
Member

@wolfgangmm Okay so the backup process from the Java Admin Client works just fine. It seems to be just the backup process triggered from the Dashboard. I have no idea how the Dashboard works, I will try and figure it and let you know...

@adamretter
Copy link
Member

adamretter commented May 31, 2019

@wolfgangmm After a bit of a search, I have found that the Dashboard uses the ConsistencyCheckTask which itself uses the SystemExport as opposed to the backup classes used by the Java Admin Client and elsewhere.

As far as I can see, this can't have ever worked in 5.x.x. The reason being that the SystemExport will attempt to work with transactions, but because it is a system task (via ConsistencyCheckTask) it is triggered from TransactionManager#doCommitTransaction it is not possible to start a new transaction, as the current transaction is being finished. I am not quite sure how we can fix this yet...

@adamretter
Copy link
Member

I would also add that these transaction errors are logged, but it seems that files that are skipped by the backup are never reported back to the Dashboard. This seems like a bit of a failing on behalf of the Dashboard as it gives the user the idea that everything worked fine, when in fact there are serious issues they need to attend to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug issue confirmed as bug high prio
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants