[
https://issues.apache.org/jira/browse/OAK-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13830026#comment-13830026
]
Alex Parvulescu commented on OAK-1159:
--------------------------------------
So I went ahead and implemented a simple version of the backup:
{noformat}
current = store.retrieve(store.checkpoint(DEFAULT_LIFETIME));
backupFS = new FileStore(destination, CACHE_SIZE, CACHE_SIZE, true);
backup = new SegmentNodeStore(backupFS);
backup.merge(current.builder(), EmptyHook.INSTANCE, null);
backupFS.close();
{noformat}
I over simplified the code (no try/catch) to have a less verbose view of how
this looks like.
When I ran this against a bigger repo (CQ) I noticed a strange behavior:
This is the original repo file list (file size, file name):
* 256M, bulk00000.tar
* 183M, bulk00001.tar
* 256M, data00000.tar
* 20M, data00001.tar
... and this is the backup directory:
* 256M, data00000.tar
Anything I might have missed in the code?
> 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)
