[
https://issues.apache.org/jira/browse/OAK-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13836606#comment-13836606
]
Jukka Zitting commented on OAK-1159:
------------------------------------
bq. v2 of the patch
+1 to committing as-is. It's easier to work on further improvements when the
baseline is already in svn.
bq. incremental backup is not efficient
See my earlier comment about the performance of comparing two checkpoints from
the same store vs. comparing states across different stores. If the previously
backed up checkpoint is still available, we'll want to retrieve it from the
source repository and do the content diff against it instead of against the
state from the backup.
bq. file size defaults to 256mb
It would probably make sense to disable memory mapping for the backup store, as
it doesn't add much value there. By not using memory mapping, the tar files
don't need to be pre-allocated and can be only as large as needed for 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-v2.patch, 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)
