British Film Institute National Archive

Born-digital workflows for long-term preservation

This page reflects is based on a point-in-time understanding of how thing work at the BFI National Archive, as of 2026, based on publicly available resources and some discussions with BFI staff during and after a site visit. If you have any comments or corrections please let me know via: andrew.jackson [at] dpconline.org

Introduction

The BFI's own Data and Digital Preservation teams web page provides a concise introduction to their digital preservation activities. The Further Information section below has links to more detailed information.

In this overview, the focus on the acquisition of born-digital A/V material and images. Digitisation is recognised as a source, but is not covered in any detail. Born-digital documents do not appear in the diagrams as those are not being actively preserved at this time.

Ingest & Preservation

The following dataflow diagram summarises the flow of data into the BFI National Archive's Digital Preservation Infrastructure (DPI).

dataflow 1.0
title "BFI National Archive Digital Preservation Infrastructure (DPI) Workflow"
zoom 2.0
offset 33 32
height 600

data item "Item" grey
data data "Data" black
data bd-data "Born-Digital Data" black
data carrier "Carrier" brown
data carrier-data "Carrier Data" black
data record "CID Record" blue
data cid "CID Preservation Package Identifier" blue
data pp "Preservation Package" red
data ppmd "Preservation Package Metadata" blue
data checksum "Checksum" orange
data ar "Access Rendition" green
data replica_3 "Tape 3" darkred

place rr "Reading Room"
place website "BFI Website"

place depositors "Third-Party\nPartners"
place internet "Internet"
place cc "BFI National Archive\nPhysical Collection"
place ts "Transfer Station"
place cdi "Collections\nInformation\nDatabase (CID)"
place access "Access Storage"
place nas "NAS Storage in Archive Network (PB-scale)"
place tape1 "Tape Robot 1"
place tape2 "Tape Robot 2"
place vault "Tape Vault"


start item@cc "BFI Holdings"
"""The BFI National Archive holds a large collection of film and television media and associated artefacts. Some of these may be selected for digitisation and digital preservation."""

derive item@cc data@cc "Digitise"
"""The BFI National Archive’s Conservation Centre is where items from the National Archive are digitised. See e.g. <a href="https://www.bfi.org.uk/features/day-life-bfi-national-archive">this blog post</a> to find out more."""

move data@cc data@nas "Internal\nTransfer"
"""The digitised items from the Conservation Centre are transferred to the PB-scale Network-Attached Storage (NAS) on the archive network."""

# ----

start item@depositors
"""The BFI also works with external partners to add born-digital productions to the national collections."""

derive item@depositors bd-data@depositors "Internet\nTransfer"@N
"""Born digital content may be delivered over the internet, where the external partner initiates the upload of a collection item."""

move bd-data@depositors bd-data@internet "Upload\nSent"
"""The upload happens over a dedicated physical connection."""

merge bd-data@internet bd-data@nas "Upload\nReceived"@W@0.82
"""The upload lands in the PB-scale Network-Attached Storage (NAS) on the archive network."""

space

derive item@depositors carrier@depositors "Copy To\nTransfer\nMedia"@N [0,1]
"""Born digital content can also be submitted on portable carriers (HDD/SSD/data tape).  For example, some submissions can be as large as 10TB in size, making internet transfer impractical."""
move carrier@depositors carrier@ts "Post/Courier\nTransfer Media"@E@0.4
"""The portable carrier is send to the BFI National Archive."""

derive carrier@ts carrier-data@ts "Extract\nDigital Media" [0,0]
"""The files held on the physical carrier are extracted on a network-isolated Transfer Station."""

merge carrier-data@ts carrier-data@nas "Internal\nTransfer"@W@0.7
"""The digital files are then transferred to the PB-scale Network-Attached Storage (NAS) on the archive network."""

delete carrier@ts "Return/Dispose\nTransfer Media"@E [0,1]
"""The physical media are then returned or disposed of in an appropriate manner."""

space

space 
start record@cdi "Basic\nDocumentation"@S [0,1]
"""A Basic Documentation metadata record is created for the item in the Collections Information Database (CID)."""

copy record@cdi uid@nas "Retrieve\n UID"@W [0,1]
"""A unique identifier (UID) for the item is retrieved from the CID."""


space 
combine uid@nas "Rename\nusing UID"@N [0,0]
"""
The root folder of the digital media is renamed using the unique identifier from the CID. Note that all original file and folder names will be recorded in the CID.
"""
space
transform data@nas pp@nas "QC &\nValidation\n(& Wrapping)"@S
"""
The digital media undergoes validation and quality control, as appropriate based on the kind of content and the visual and audio encoding standards it is expected to meet. Usually a manifest is present, either added at source or included via the relevant standard, and this is used to verify completeness and fixity. The files are then prepared for the downstream <tt>autoingest</tt> process. This includes file renaming to an internal standard, and repackaging into a single binaries where appropriate. This may use the TAR format, but <a href="https://mediaarea.net/RAWcooked">RAWCooked</a> processing is very strongly preferred wherever the resulting 'FFv1 in Matroska' file is appropriate. For example, DPX files are normalised in this way. <a href="https://mediaarea.net/MediaConch">MediaConch</a> is used to define and implement policies in ways that can be shared between the parties involved.

<br><br>The resulting Preservation Package roughly corresponds to the OAIS notion of an Archival Information Package.
"""

space
derive pp@nas ar@nas "Create\nAccess\nRendition"@S [0,-1]
"""
Sometimes content is preserved in formats that cannot be transcoded for access, but in most cases low-bitrate lossy JPG and MP4 files are generated as "Access Renditions" (roughly corresponding to an OAIS Dissemination Information Package). Preservation Packages can use separate audio and video bitstreams, if this is how the standards-based source is built. But on access, a single Access Rendition is more useful, so a ProRes or MP4 file may be generated for staff or public access purposes.
"""

space
derive pp@nas ppmd@nas "Extract\nMetadata"@N [0,1]
"""
The <a href="https://mediaarea.net/en/MediaInfo">MediaInfo</a> tool use used to extract technical metadata from the Preservation Package and any Access Renditions.
"""

merge ppmd@nas record@cdi "Add Metadata To\nExtended Documentation"
"""
The CID is updated with standards compliant record(s), using EN 15907 (moving image), ISAD(G) (screen craft), RDA (library). Records are added for the Access Renditions and the Preservation Packages. The Preservation Package records also refer to the Access Renditions as well as containing the original file and folder names, the technical metadata from MediaInfo, and any access restrictions (for limiting onward delivery).
"""

copy pp@nas replica_1@tape1,replica_2@tape2 "Copy to\ntapes 1 & 2"
"""
At this point, the <tt>autoingest</tt> job takes over, and the the Preservation Package is passed to the tape libraries. Both are >20PB scale, and each uses a different tape technology (IBM3592 & LTO9). The tape library policy system manages replication.
"""

space
derive replica_1@tape1 checksum@tape1 "Calculate\nChecksum"@N [0,1]
"""
The data tape system calculates the MD5 sum of the content as it is written to tape. MD5 is used because this is well-supported by the data tape system and sufficient for detecting accidental transfer failures.
"""

move checksum@tape1 checksum@nas "Retrieve\nChecksum"@E
"""
The MD5 sum is retrieved from the tape library, unless the package was very large and had to be chunked for writing to tape. In that case, the package is read in full and the MD5 checksum is re-calculated.
"""
combine checksum@nas "Fixity\nCheck"@N 
"""
The retrieved MD5 checksum is compared with the local package checksum.
"""

derive replica_2@tape2 replica_3@tape2 "Copy to\ntape 3"@S [0,-1]
"""The second tape robot creates an additional copy on an additional, separate LTO9 tape."""

move replica_3@tape2 replica_3@vault "Transfer tape 3 to vault"@E
"""
As the third-copy tapes are filled, they are collected and transferred to a third location over 50 miles away. This disaster recovery strategy is tested annually through random recovery checks where the data is restored from selected tapes and the results verified against the records in the CID.
"""

copy ar@nas ar@access "Transfer"
"""The Access Rendition is transferred to a suitable storage location used to provide access to end users."""

delete data@nas,pp@nas,ar@nas "Delete\nWorking Copies"@E
"""All the intermediary file and the original submission are now deleted, after confirming lossless transfer to data tape."""


status "Ingest Complete"

end

Further Information

Links and references discovered during this work.

Blogs

Presentations

Code