[ https://issues.apache.org/jira/browse/OAK-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13822647#comment-13822647 ]
Jukka Zitting commented on OAK-1159: ------------------------------------ >From a chat with Alex; the easiest way to do a backup would be to allow a >custom initial state (instead of just the current EMPTY_STATE) to be passed to >a TarMK {{FileStore}} instance. With such a change it would be possible to >backup the latest state of any {{NodeStore}} with the following piece of code: {code} NodeStore store = ...; File backup = ...; File checkpoint = store.checkpoint(...); new FileStore(backup, 256 * 1024 * 1024, true, checkpoint).close(); {code} Incremental backups should be possible by using the content diff between successive checkpoints to determine how the already backed up state needs to be updated. > 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)