Date: Thu, 28 Mar 2024 04:34:37 -0400 (EDT) Message-ID: <403122842.27264.1711614877226@lyrasis1-roc-mp1> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_27263_542977699.1711614877225" ------=_Part_27263_542977699.1711614877225 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
NOTE= : The endpoints discussed below - /fcr:backup and /fcr:restore - will be mo= ving to an extension module in a future release of Fedora. The Backup= Format (also discussed below) will change at that time. |
---|
Historically, Fedora married the c= oncepts of persistence and durability by choosing transparent forms of pers= istence. Fedora 3 wrote human-readable XML to disk, which could be in= dexed and manipulated by the Fedora repository software but which systems b= eyond the repository could also readily penetrate if needed. Transparency i= n support of durability is as valid a principle as ever, but there is a wea= kness 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. <= br>
Today, the operational form of per=
sistence used by the core Fedora repository component - essentially a speci=
ally designed table and index within a relational database system for metad=
ata and a curated filesystem structure for binaries - is not meant to be ma=
nipulated directly by a human except in the most unusual situations. It's d=
esigned, instead, for use by the soft=
ware to provide as performant a response as possible for the repository's d=
efined API. Comparison to a traditional RDBMS is appropriate: =
if you are concerned for the durability of your data in a relational databa=
se, you export/dump backups in a transparent format to disk and use tho=
se to ensure durability. You would never attempt to run your sys=
tem based exclusively on a disk backup/dump sitting on disk. The Back=
up procedure discussed on this page serializes the metadata and binaries fr=
om persistence layer to disk principally to support the Restore procedure i=
nto a repository-specific persistence layer.
If you like to maintain transparen= t persistence - an export that is a simple and human-readable form of your = repository - this is supported with an integration around the core.
If a POST body specifying a writeable directory (local to Fedora server)= is not included in the request, the backup will be written to the system t= emp directory.
Perform a backup of a running Fedora repository
POST /rest/fcr:backup
> optional POST body pointing to the local filesystem backup director= y to which the export will be written.
On success
Response body
Note: Restoring a backup replaces the repository content with the conten= ts of the backup, so any data in the repository will be lost.
Perform a restore of a running Fedora repository
POST /rest/fcr:restore
> optional POST body pointing to the local filesystem backup director= y from which the export will be read.
On success
Regardless of the repository configuration, the output of the backup pro= cess creates resources of the same format. Further details on backup c= ontents and the underlying implementation can be found in ModeShape's = d= ocumentation.
The backup directory will contain
For example, binary content in the repository with a SHA-1 of "56135= 37644c4d081c1dc3530fdb1a2fe843e570170d3d054", would look like
=E2=94=9C=E2=94=80=E2=94=80 binaries =E2=94=94=E2=94=80=E2=94=80 44 =E2=94=94=E2=94=80=E2=94=80 c4 =E2=94=94=E2=94=80=E2=94=80 d0 =E2=94=94=E2=94=80=E2=94=80 44c4d081c1dc3530fdb1a2fe843e570= 170d3d054.bin
For example
{ "metadata" :=20 { "id" : "87a0a8c317f1e7/jcr:system/jcr:nodeTypes/nt:unstructured/=EF=80= =AA/undefined/1" ,=20 "contentType" : "application/json" } , "content" :=20 { "key" : "87a0a8c317f1e7/jcr:system/jcr:nodeTypes/nt:unstructured/=EF=80= =AA/undefined/1" , "parent" : "87a0a8c317f1e7/jcr:system/jcr:nodeTypes/nt:unstructured" ,= =20 "properties" :=20 { "http://www.jcp.org/jcr/1.0" :=20 { "primaryType" :=20 { "$name" : "nt:propertyDefinition" } ,=20 "onParentVersion" : "COPY" ,=20 "multiple" : false ,=20 "protected" : false ,=20 "availableQueryOperators" :=20 [ "jcr.operator.equal.to" ,=20 "jcr.operator.greater.than" ,=20 "jcr.operator.greater.than.or.equal.to" ,=20 "jcr.operator.less.than" ,=20 "jcr.operator.less.than.or.equal.to" ,=20 "jcr.operator.like" ,=20 "jcr.operator.not.equal.to" ] ,=20 "requiredType" : "UNDEFINED" ,=20 "mandatory" : false ,=20 "autoCreated" : false }=20 }=20 }=20 }
By default, files larger than 4KB are stored on disk named after their S=
HA1 digest, in the directory fcrepo.binary.directory
. (4K=
B is the default, but can be changed by updating the minimumBinarySizeInBytes
pr=
operty in r=
epository.json). That is, a file with the SHA1 "a1b2c36956=
3c0465ab82cdb2789d45ce1c3585b1" would be stored on disk in /path/to/fcrepo4-data/fcrepo.binary.directory/a1=
/b2/c3/a1b2c369563c0465ab82cdb2789d45ce1c3585b1
. So files in t=
he repository can be backed up backing up the directory fcrepo.binary.directory
.