[
https://issues.apache.org/jira/browse/OAK-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13826601#comment-13826601
]
Alex Parvulescu commented on OAK-1159:
--------------------------------------
bq. allow a custom initial state (instead of just the current EMPTY_STATE) to
be passed to a TarMK FileStore instance.
I'm intrigued. If I pass in a NodeState I assume I'd have to add some logic for
the diff to happen?
I think that there are 2 cases:
* first run (full backup): empty directory, code might run as it is now
* second-to-n runs (incremental backup): I don't think this assumption holds
anymore [0], the journal is probably initialized already, all we need now is to
replay the changes on top of the existing state.
Otherwise I's see it as a normal (no initial state) init of the FileStore in
the backup directory, then run a diff with the current state:
{noformat}
NodeState current = // current repo state
NodeStore backup = new SegmentNodeStore(backupFS);
backup.merge(current.builder(), EmptyHook.INSTANCE, null);
{noformat}
[0]
http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/segment/file/FileStore.java?view=markup#l114
> 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)
