[
https://issues.apache.org/jira/browse/OAK-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831564#comment-13831564
]
Alex Parvulescu commented on OAK-1159:
--------------------------------------
Agreed on the initial backup,I'll test that and see if the blob fix is good.
bq. 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.
hmm, but if there already is a folder where we have an unknown state, why not
use that as the reference? why introduce another layer: where would I save the
last seen&backed-up checkpoint and how do I make sure that the state is still
there?
Also, what happens if the checkpoint gets recycled in the meantime? If it goes
away I might need to create a backup from scratch which might be a waste of
work.
I'd see this ApplyDiff happen automagically in the FileStore: if _journals_
contains a "root" (basically the incremental backup case) and the initial state
!= EMPTY_NODE (only mess with this in a case of a backup) somehow apply the
diff directly (this part is yet unknown).
So the only thing that I'd need is to get the current state which would be a
reflection of what is actually there instead of what I assume should be there.
> 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)
