[MGNLBACKUP-129] Backup on running instance can corrupt indexes Created: 30/May/19  Updated: 29/Mar/22  Resolved: 26/Aug/19

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

Type: Bug Priority: Neutral
Reporter: Ondrej Chytil Assignee: Robert Šiška
Resolution: Cannot Reproduce Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relation
is related to MGNLBACKUP-140 Avoid indexing while backing up Closed
is related to MGNLBACKUP-139 Unable to commit volatile index Open
is related to MGNLBACKUP-142 RepositoryManager should be injected ... Closed
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:
Epic Link: Support
Sprint: SPA Editor 2, SPA Editor 3, SPA Editor 4
Story Points: 5
Team: Nucleus

 Description   

Performing backup on running Magnolia instance can result in index corruption. Indexes are being duplicated in the process to the point where all iNodes are used preventing Magnolia from functioning.

This is most likely related to the fact that the Jackrabbit is a single thread process and creating a copy of the repository can be interrupted by any write operation.

Affected version is set to 2.3 but the problem is most likely present since the Backup module was refactored to use Jackrabbit RepositoryCopier.

The backup process should be improved so it's possible to safely execute it on the running instance, ideally including the time of any publishing.

It's a bit harder to get to the final stage of this issue (100% iNodes usage) but it's possible to reproduce early stages of the index corruption by:
1. Creating bigger page tree.

2. Publishing it.

3. Executing the backup manually while the publishing is running.

Issue might not happen every time though.



 Comments   
Comment by Robert Šiška [ 26/Aug/19 ]

Closing this as 'Cannot reproduce'. I couldn't reproduce any inodes growth, plus from the support ticket it's not quite sure if the problem is really caused by backup as they experienced inodes growth even when the backup wasn't running...

Moreover, the documentation states that although it is possible to backup from a running instance, it is not a recommended best practice. The RepositoryCopier documentation also warns that there should not be any write operation while the copy is created.

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