[
https://issues.apache.org/jira/browse/OAK-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13832710#comment-13832710
]
Jukka Zitting commented on OAK-1159:
------------------------------------
bq. why wouldn't the ids match?
The SegmentMK doesn't use content hashes as identifiers. Thus storing the same
state twice (once in the main repository, once in the backup) results in two
different identifiers.
bq. I'm afraid this will make us lose the ability to have the backup as a
drop-in replacement
Ah, good point. Note that the {{SegmentNodeStore}} actually also keeps such a
"super-root" node for extra bookkeeping purposes (the idea is to keep track of
past checkpoints, etc.), so the drop-in feature should still be doable.
> 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
>
> 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)
