[MGNLBACKUP-33] Scheduled Backups exclude versions from backup by default Created: 03/Jun/11  Updated: 29/Mar/22  Resolved: 13/Jun/11

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

Type: Bug Priority: Blocker
Reporter: Sean McMains Assignee: Jan Haderka
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File versionErrorLog.txt    
Issue Links:
causality
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   

Steps to reproduce:

1. Unzip new Enterprise bundle (tested with 4.4.1), bring up Magnolia.
2. Activate some content to create versions.
3. Set up scheduled backup. Wait for backup to run.
4. Shut down Magnolia after backups run.
5. Delete repositories. (rm -rf webapps/magnoliaAuthor/repositories/magnolia/)
6. Restore backup files using restore CLI tool. (./bin/restore -backup <backupDir> -webapp <webappDir>)
7. Restart Magnolia. (Might need to delete the indices and restart again.)
8. Modify some of the previously versioned content, activate it.

Expected result:

  • Content activates successfully.

Actual result:

  • Activation fails. (See attached log.)

Also:

9. Choose "Versions" from page popup.

Expected result:

  • List of versions displayed.

Actual result:

  • List of versions is empty.

The workaround is to add parameter backupVersions to the generated task and set its value to true



 Comments   
Comment by Sean McMains [ 03/Jun/11 ]

This issue surfaced as part of the ticket regarding CSC's issues. (Thanks to Mina for the terrific work tracking this down!) I've reproduced it on my machine (OS X); CSC is running under Windows. They're working around this issue by doing manual backups (which apparently still work), but we should get them a fix quickly.

Comment by Zdenek Skodik [ 10/Jun/11 ]

This has actually never worked.

Comment by Zdenek Skodik [ 13/Jun/11 ]

Ok, the command defines a boolean backupVersions variable, that is somehow set to false by default so that no content versions are actually backed up at these days - perhaps we should set it to true by default.

In any case you can add the backupVersions property, set to true, to your scheduled backup task (/modules/backup/config/tasks/<my_dear_backup>) to get rid of this issue.

Comment by Jan Haderka [ 13/Jun/11 ]

The fact remains that if the backup is ever made without versions, the connection to the version store is broken and can't be restored, hence such instance can no longer perform any versioning operations.

Comment by Mina Labib [X] (Inactive) [ 21/Jun/11 ]

Hello,
Should I consider the new property (backupVersions = true) as a solution for my scheduled backup version corruption, as I see the issue is marked as fixed or you still have some development effort to be done?

Thanks.

Comment by Jan Haderka [ 21/Jun/11 ]

Hi,

yes, setting the backupVersions=true is a workaround until fix can be released.

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