[MGNLBACKUP-100] Test stability of RepositoryCopier implementation comprehensively Created: 26/Apr/16  Updated: 29/Mar/22  Resolved: 20/May/16

Status: Closed
Project: Backup
Component/s: None
Affects Version/s: 1.6.1
Fix Version/s: 2.0, 2.1

Type: Task Priority: Major
Reporter: Ilgun Ilgun Assignee: Ilgun Ilgun
Resolution: Fixed Votes: 0
Labels: backup, restore
Remaining Estimate: 0d
Time Spent: 3d
Original Estimate: Not Specified

Issue Links:
dependency
depends upon MAGNOLIA-6658 Handle versions suffering from Incons... Closed
depends upon MGNLBACKUP-102 Implement Retry Mechanism for backup ... Closed
is depended upon by MGNLBACKUP-99 Refactor backup module to use Reposit... Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:
Sprint: Basel 44
Story Points: 8
Team: Nucleus

 Description   

This issue is addressing test-phase of new RepositoryCopier API used implementation of backup module which is done with MGNLBACKUP-99.

Acceptance Criteria:

  • Make sure we will not have corrupted data upon concurrent modification to data.
  • Deadlocks will not be an issue.
  • Testing the implementation with various PersistenceManager s therefore DataSource s.

Findings;

  • Tested with Mysql, Postgres, and Derby.
  • Below is tested with Mysql with DataStore (Dataset =~ 3gb)
  1. Tried to remove data while backing up -> Seems to be working well, basically deletion happened after backup
  2. Tried to add data while backing up -> Seems to be working well as well, backups up basically everything which is present.
  3. Tried to version a node while backing up -> Found problematic situation that might cause inconsistent versions and tackled it with MGNLBACKUP-102.


 Comments   
Comment by Vivian Steller [ 17/Nov/16 ]

Great to hear there's a new Backup module!

Question: did you try to recover the 3 GB backup using the same persistence manager setting also?

Thanks!

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