[ 
https://issues.apache.org/jira/browse/OAK-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13830151#comment-13830151
 ] 

Jukka Zitting commented on OAK-1159:
------------------------------------

Blob copying fixed in revision 1544610.

There should be no need for the {{SegmentNodeStore}} around the {{FileStore}} 
instance. For the initial backup you'd just need to add the extra initial state 
argument as discussed. And for incremental backup the following piece of code 
should be enough:

{code}
NodeState before = store.retrieve(checkpoint);
checkpoint = store.checkpoint(...);
NodeState after = store.retrieve(checkpoint);

FileStore backup = new FileStore(...);
Journal root = backup.getJournal("root");

SegmentNodeState state = new SegmentNodeState(
    backup.getWriter().getDummySegment(), root.getHead());
SegmentRootBuilder builder = state.builder();
after.compareAgainstBaseState(before, new ApplyDiff(builder));
root.setHead(builder.getNodeState().getRecordId());

backup.close();
{code}

The idea is that we keep track of the checkpoint that was last backed up, and 
then use the {{ApplyDiff}} class to copy all the changes since then to 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
>
> 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)

Reply via email to