search

OCFL / Use-Cases

A repository to help capture, track, and discuss use cases for OCFL. Issues-only, please.
7 stars 0 forks source link

Rebuildability #9

Closed ahankinson closed 5 years ago

ahankinson commented 6 years ago

An institution has had a flood event in its data centre, and this has wiped out the disk arrays that power its institutional repository website. However, it has maintained a Git repository of its software, and has been able to recover its most recent backups from an off-site tape storage. They restore the tapes and upload the OCFL backups to an S3 account. They adjust the settings in their software to point to the new storage system. Their institutional repository repopulates its internal database with metadata from the OCFL objects, and they are back online within a few weeks, with all object content and provenance intact.

ahankinson commented 6 years ago

Part of the specification should be the requirement that all data and metadata needed to 'rehydrate' an empty repository is available in the OCFL object.

This is unlikely to be something that we can enforce with validation or client behaviours, so it should be made very clear in the specs.

ahankinson commented 6 years ago

F2F 2018.09.05: It is a fundamental goal of the spec to support rebuildability. We will need to maintain an agnostic approach to the format of any metadata within the OCFL object, but fundamentally we will promote repository rebuildability from persistent storage (e.g., filesystems, object stores, etc).

Rebuildability is enhanced by scanning just the inventory.jsonld.

awoods commented 5 years ago

Supported since v0.1