[
https://issues.apache.org/jira/browse/OAK-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13833947#comment-13833947
]
Jukka Zitting commented on OAK-1159:
------------------------------------
+1 the patch looks good
There's a small bug in FileStore intialization:
{code}
- NodeBuilder builder = initial.builder();
+ NodeBuilder builder = EMPTY_NODE.builder();
builder.setChildNode("root", initial);
{code}
(otherwise we end up with a duplicate copy of the initial state)
In the test case, a better way to verify the backup would probably be to just
use {{NodeState.equals()}}:
{code}
- bv.verify("main", store);
- bv.verify("backup", backup);
+ assertEquals(store.getRoot(), backup.getRoot());
{code}
(then we can add as much different types of content as we like and still have
the single assertion check that the backup is an exact match of the source
repository)
I'd also drop the {{BackupManager}} interface as there's no need for multiple
different implementations.
bq. failing test
This seems to be another case of using instanceof checks with the implicit
assumption that all records are from the same segment store. I'll look into it.
bq. first-class citizen in Oak
Having the backup class publicly available is already a good start. As another
step I'd add a "backup" mode to the {{oak-run}} jar.
It would also be nice to expose the backup mechanism as a JMX/OSGi service, but
I'm not sure if directly exposing the {{backup(File)}} method is a good idea
here. A better alternative might be to make things like the backup directory,
backup interval/schedule, etc. configurable as service properties, and just
expose status information (is backup in progress, how long did the last backup
take, how much disk space is used, etc.) and possibly a manual {{backupNow()}}
override for explicitly triggering a backup at any time.
bq. MongoMK
The backup mechanism as designed is independent of the type of the source
repository (it only uses the TarMK for storing the backup), so it should work
just fine also with the MongoMK. Only the restore part would be a bit trickier,
but I think we should be able to make the MongoMK use a similar custom initial
state parameter to allow the repository state to be restored directly from the
backup.
> Backup and restore
> ------------------
>
> Key: OAK-1159
> URL: https://issues.apache.org/jira/browse/OAK-1159
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core, mk
> Reporter: Michael Marth
> Assignee: Alex Parvulescu
> Attachments: OAK-1159.patch
>
>
> We need a way to backup and restore a repository. I was thinking that the MK
> impl could expose an interface for this, as the actual implementation would
> differ quite a bit between e.g. TarMK and MongoMK.
> Also, I think we could leverage the MVCC nature of the MKs and mark a
> specific revision as "the revision to backup" (regardless of ongoing writes).
> That would allow us to prevent the ugly situation in JR2, that we need to
> stop writes for a while to produce a consistent backup.
> The restore in such a scenario would discard revisions that happened after
> said marker (but still made it into the backup).
--
This message was sent by Atlassian JIRA
(v6.1#6144)
