Historically, Fedora married the concepts of persistence and durability by choosing transparent forms of persistence. Fedora 3 wrote human-readable XML to disk, which could be indexed and manipulated by the Fedora repository software but which systems beyond the repository could also readily penetrate if needed. Transparency in support of durability is as valid a principle as ever, but there is a weakness to this strategy: transparent forms of persistence are not performant. Additionally, many users didn't particularly care for that principle, but they still incurred the performance costs associated with it. So in the move from Fedora 3 we divorced the two concepts, moving responsibility for transparent persistence away from the core repository software.
The Today, the operational form of persistence used by the core Fedora repository component - essentially a specially designed table and index within a relational database system for metadata and a curated filesystem structure for binaries - is not meant to be manipulated directly by a human except in the most unusual situations. It's designed, instead, for use by the software to provide as performant a response as possible for the repository's defined API. Comparison to a traditional RDBMS is appropriate: if you are concerned for the durability of your data in a relational database, you export/dump backups in a transparent format to disk and use those to ensure durability. You would never attempt to run your system based exclusively on a disk backup/dump sitting on disk. The Backup procedure discussed on this page serializes the metadata and binaries from persistence layer to disk principally to support the Restore procedure into a repository-specific persistence layer.
If you like to maintain transparent persistence - an export that is a simple and human-readable form of your repository - this is supported with an integration around the core. |