Is a database dump sufficient for preservation?

It can be part of a strategy, but its completeness, compatibility and accompanying documentation need evaluation against future use.

Does preserving a database preserve its application?

Not necessarily. Interfaces, business rules and external services may require separate preservation if their behavior matters.

What is SIARD used for?

It is an open format for long-term archiving of relational database structure and content, used within a broader preservation process.

AI Glossary / Data engineering and architecture / Intermediate

Database preservation

Definition

Database preservation is the planned maintenance of a database's information so that it remains accessible, interpretable and trustworthy over time, including after the original system is retired. It involves more than retaining rows: structure, relationships, meaning, provenance and relevant dependencies may be necessary for future users to understand what the records represent.

What it means

A database can remain intact at the byte level while becoming practically unusable. The software may no longer run, a code list may be missing, or a field named Amount may have lost its currency definition. Preservation addresses those risks alongside the risk of lost or altered files.

The intended future use determines what matters. Preserving the evidence contained in records is different from preserving every behavior of the original application. A project should state whether future users need to inspect tables, reproduce reports, understand historical decisions or run the original interface, because those goals require different supporting material.

How it works

Begin by identifying the database's scope, significant properties and future audience. Document tables, relationships, types, codes, units and time conventions. Identify external files, application logic or reference data needed to interpret the records, and record what will not be preserved.

Choose a preservation strategy. Options may include maintaining an environment, migrating to a supported system or exporting to a documented archival representation. SIARD is one open format designed for long-term archiving of relational databases. Its role is different from simply retaining a vendor-specific dump and hoping compatible software remains available.

Validate the resulting package against the preservation requirements. Check structure, content and representative relationships, record transformations and establish fixity information to detect later file changes. Preserve documentation with the data, manage access and revisit the arrangement as formats, tools and organizational responsibilities change. Preservation is a continuing responsibility, not just a successful one-time conversion.

Three practical examples

1. A museum retires its collection-management application. It preserves collection records together with identifier relationships, controlled vocabulary meanings and descriptions of how records were maintained.

2. A research project archives a relational database of observations. The package includes measurement units, missing-value conventions and the relationship between observations and instruments.

3. A business preserves the data supporting an earlier analytics experiment. It retains the relevant database state, query definitions and contextual notes needed to understand the reported result without pretending that these alone recreate the entire original service.

Think of it this way

Think of preserving a board game with its pieces, board and rulebook. Keeping every piece is insufficient if nobody knows what the markings mean or how the pieces relate. The analogy is limited: a database may also depend on executable behavior, external resources and access restrictions, and future interpretation may require documented transformations rather than the original software.

Worked example

Suppose a fictional archive receives three tables: Projects with 20 rows, Measurements with 2,000 rows and StatusCodes with four rows. Each measurement references a project and a status code. The preservation check confirms these counts and verifies that references resolve to retained records.

The team also selects a known subset containing values 10, 15 and 20. The source report totals them as 45. The archived representation must reproduce that total under the documented query and units. A matching grand row count would not reveal that decimal values were rounded during conversion.

Finally, the team verifies that status code 3 still has its documented meaning. Keeping the number without the code definition could make all 2,000 records readable but ambiguous. The checks demonstrate content and meaning preservation for chosen properties; they do not prove that every application behavior or possible future query has been preserved.

Illustrative case study

Fictional case: ArchiveQuay exports an old service database and stores the files safely. During an access rehearsal, a reviewer cannot tell whether recorded dates refer to submission, approval or later data entry. The old application had displayed those distinctions through screen labels that were never included in the export.

The team consults existing documentation and knowledgeable staff while they remain available. It adds verified field definitions, representative reports and a record of unresolved uncertainties. It does not invent explanations for fields whose meaning cannot be established.

Document context before retirement: intact values can still lose their meaning.

Common misconceptions and mistakes

Do not equate preservation with ordinary backup. Backups mainly support recovery under defined operational conditions; long-term preservation also considers future interpretability and technological change. Both can be necessary.

Avoid assuming that an open format automatically captures every source feature or business meaning. Conversion requires checking unsupported types and lost behavior. Do not rely solely on checksums either: they can reveal changes to a file relative to a baseline, but cannot establish that the original export included every required table or correctly understood each field.

Business use

Database preservation matters when information outlives a project, application or supplier relationship. Planning before decommissioning can prevent expensive attempts to reconstruct dependencies after staff, licenses or servers are gone.

Define the information's purpose, ownership, access conditions and retention decisions. Budget for documentation and validation as well as storage. For AI reuse, assess whether the archived data's original definitions and limitations still fit the new purpose. Preserving historical records does not automatically make them suitable training data or authorize unrestricted reuse.

Check your understanding

Archived files pass every checksum check, but their status codes have no definitions. Is preservation complete?

Answer: Not for a purpose requiring interpretation of those statuses. Fixity supports confidence that the files have not changed, while missing semantic documentation still limits their usability.

Related terms

Database dump
Schema
Digital preservation
SIARD
archival metadata
fixity
data provenance
migration
software preservation
data dictionary
significant properties

Learn next

Learn preservation metadata and fixity next. Select a small database and list what a future reader needs to understand its records without the current application. Export it into a test environment, reproduce a known query and document any lost features or uncertain meanings before choosing a long-term strategy.

Sources

DILCIS Board, SIARD, explains the format's purpose and its relationship to preservation packaging: https://dilcis.eu/content-types/siard

DILCIS Board, SIARD repository, documents the open format and supporting specifications: https://github.com/DILCISBoard/SIARD

Digital Preservation Coalition, Fixity and checksums, explains file-integrity monitoring: https://www.dpconline.org/handbook/technical-solutions-and-tools/fixity-and-checksums

The primary descriptions were read. The worked validation and fictional case are original illustrations; actual preservation requirements must be defined for the database and intended future use.

Previous: Database object Next: Database refactoring