Museum records · backups · recovery

How to Back Up a Museum Collection Database

A museum backup is useful only if it protects the records, images and related files the collection depends on—and if another person can restore them when the normal system is unavailable.

Database

Images

3-2-1

Cloud

Restore test

Core principle

Back up the whole collection information system, not only one database file

Best proof

A successful restore is stronger evidence than a successful backup message

In practice: identify every component needed to rebuild access to the collection, keep more than one copy, store at least one copy away from the main system, automate what can be automated and test restoration on a schedule. For cloud collection software, add a regular independent export so the museum has a usable copy outside the supplier’s platform.

A dependable backup plan protects more than the database: it keeps the records, linked files and recovery route together.

What to back upRecords, images, attachments and system information.System typesWhat cloud, desktop and self-hosted setups can miss.3-2-1 approachCopies, storage types and an off-site copy.Recovery targetsHow much work and downtime can the museum accept?Cloud systemsWhat vendor backups do—and do not—guarantee.Restore & integrityProve the backup is complete, usable and unchanged.10-question auditA fast check for gaps in the backup plan.FAQDirect answers to common backup questions.

Start by defining what the museum would need to rebuild

“Back up the database” sounds simple until the database depends on image folders, attachments, settings or information stored somewhere else.

The first job is to identify the complete collection information set. The obvious part is the catalogue or collections management database: object records, accession details, locations, condition information, loans, movements and other structured data. But the database may only point to photographs, PDFs, conservation documents, audio, video or scanned paperwork stored elsewhere.

If those files are missing after a failure, the database may technically open while important parts of the collection record are unusable. The same problem can appear with a locally hosted system if the database is protected but the configuration, custom fields, media folders or documentation needed to rebuild the installation are not.

For a small museum, the most useful question is practical: if the main computer, server or cloud account disappeared today, what would another trained person need in order to recover useful access to the collection?

The collection record may be spread across several components even when staff experience it as one system.

Collection records

The structured database: identifiers, descriptions, locations, acquisition information, rights, condition, movements, loans and linked relationships.

Images and media

Object photographs, scans, audio, video and derivatives. Confirm whether files are stored inside the system, on a shared drive or in separate cloud storage.

Attachments and documents

PDFs, reports, agreements, scanned forms and other files that staff expect to open from the record.

Configuration and documentation

For locally managed systems this may include configuration, customisation, installation notes, credentials and access procedures and instructions needed to rebuild the service.

Do an inventory before choosing storage: a backup policy that protects the wrong set of files can look successful for months. List the systems, folders and services first, then decide how each one is protected.

What to back up depends on the type of museum system

The same phrase—“collection database”—can describe very different technical setups. The backup plan should match where the records and linked files actually live.

Museum collection backup components by system type
Museum setup	Protect these components	Common blind spot
Cloud museum CMS	Independent data export, original images and attachments where available, export documentation and the provider recovery route.	Assuming the supplier’s internal backup is automatically a museum-controlled copy.
Self-hosted collection system	Database, media files, configuration, customisations, application documentation and anything needed to rebuild the service.	Protecting the database while leaving media folders or configuration outside the backup.
Desktop database	The database file, linked image and document folders, templates or settings, and the instructions needed to open the system on another computer.	Keeping both the working file and its copy on the same computer or permanently connected drive.
Spreadsheet plus folders	The current spreadsheet, image and document folders, folder structure, naming rules and a clear record of which spreadsheet is authoritative.	Several conflicting spreadsheet copies with no dependable master version.

Do not back up by software name alone: map the full information path from object record to image, attachment, location history and export. If one required component lives outside the main system, it needs its own protection and recovery test.

Backup and digital preservation are related, but not identical

A backup is primarily about recovery from loss or damage. Long-term digital preservation also asks whether files will remain understandable and usable as technology changes.

Backup asks: can we recover?

It protects against deletion, hardware failure, ransomware, account problems, corruption and other incidents by keeping recoverable copies.

Preservation asks: can we still use it later?

It adds concerns such as file formats, documentation, storage monitoring, integrity, migration and the long-term management of digital material.

A backup can preserve a bad state

If corrupted files, missing images or poor filenames are copied repeatedly, the backup process may faithfully reproduce the problem.

A preservation plan still needs backup

Policies and metadata do not replace redundant copies. The museum still needs a practical recovery route when working storage fails.

For image-heavy collections, consistent filenames make recovery and migration easier. See the internal guide to museum image file naming.

Use 3-2-1 as a simple starting structure

The familiar 3-2-1 model is useful because it prevents one device, one account or one building from becoming the museum’s only line of defence.

3-2-1 is a structure, not a product list. The exact storage choices depend on the museum’s systems and resources.

3-2-1 in plain language

Do not let every copy fail together

3 copies: the working data plus at least two additional copies.
2 storage approaches: avoid treating one device or one service as the whole plan.
1 off-site copy: keep at least one copy away from the main physical location or primary system.
Make at least one copy difficult for ordinary user mistakes or malware to overwrite immediately.
Document how to reach each copy and who is authorised to restore it.

Important distinction: a USB drive permanently attached to the same computer is convenient, but it may be exposed to the same theft, electrical event, malware or accidental deletion. Separation matters as much as copy count.

Choose backup frequency from the amount of work you can afford to lose

There is no useful universal answer such as “back up every Friday”. The right interval depends on how quickly the collection data changes.

Start with a simple question: after a failure, how far back could staff reasonably go without causing serious rework? If several people update locations, accession records or digitisation data every day, losing a week may be unacceptable. If a legacy image archive changes only once a month, the schedule can be different.

Automation is valuable because it removes memory from the routine. A scheduled backup or export should run without someone having to remember a button. That does not remove human responsibility: a named person should still check that the job completed, storage remains available and restore tests are being performed.

Example museum backup frequencies based on how collection information changes
Collection component	Typical change pattern	Planning question
Active collection database	Records may change throughout the working day.	How many hours or days of cataloguing, movement and accession work could the museum recreate?
New digitisation files	Large batches may arrive during a project.	At what point are new masters copied away from the capture workstation?
Stable master image store	Existing masters change rarely, while new files are added.	Can the process protect new files without repeatedly rewriting the whole archive?
Configuration and procedures	Usually changes after upgrades or workflow decisions.	Is a fresh copy taken whenever the system or written procedure changes?

How much work can the museum afford to lose?

This is the recovery point question. If losing one day of new cataloguing, location changes or accession work would create serious rework, the backup or export interval needs to be shorter than one day.

How long can the database be unavailable?

This is the recovery time question. A copy that takes several days and specialist help to restore may be inadequate if staff need collection locations or current records the same morning.

These are often called the recovery point objective (RPO) and recovery time objective (RTO). The labels matter less than writing down the museum’s acceptable data loss and acceptable downtime.

Automation reduces missed backups, but it does not prove recoverability

A green status message can confirm that a backup job ran. It cannot confirm that the restored collection will be complete and usable.

1. Run automatically

Schedule database backups, file copies or exports so protection does not depend on the right person being present.

2. Check completion

Review failed jobs, storage warnings, unusually small backups and other signs that the routine is not behaving normally.

3. Keep versions

A mistake may be discovered days later. If every new backup immediately replaces the previous one, the only surviving copy may already contain the error.

4. Test restoration

Recover a copy into a safe location and check real museum tasks, not only whether one file can be opened.

Keep a separated copy

At least one useful copy should not remain continuously exposed to the same workstation, shared drive or ordinary user account as the live collection data.

Limit delete access

Routine collection users should not automatically be able to erase every backup generation. Recovery copies need tighter permissions than everyday working files.

Encrypt portable and off-site copies

If a drive or remote copy contains sensitive collection information, protect it against unauthorised access as well as physical loss.

Keep a separate recovery route

Document how an authorised second person can reach the backup if the normal administrator account is unavailable, locked or compromised.

Avoid silent failure: assign someone to receive or review backup alerts. An automated process that has been failing unnoticed for three months is not a backup strategy.

Cloud collection software still needs a recovery conversation

Hosted software can remove much of the technical burden, but “the supplier backs it up” is not enough detail for a museum continuity plan.

Ask the supplier exactly what is protected: the structured records, uploaded images, attachments, audit history, configuration and any integrations the museum relies on. Ask how often copies are created, how long versions are retained and what kinds of restoration are possible. Recovering an entire service after a catastrophic failure is different from restoring one record that a user deleted last Tuesday.

The museum should also understand the exit route. A provider’s internal backup may be excellent for operating its service while still being inaccessible to the museum as an independent copy. A regular export in documented, usable formats gives the museum another option if access to the platform is interrupted, the museum changes supplier or a migration is needed later.

This is one reason backup should be considered when choosing museum collection software, not after the contract is signed.

Provider recovery and museum-controlled export solve different problems. A resilient plan understands both.

Ask what can be restored

Whole service, individual record, deleted image, previous version or a point in time? These are different recovery capabilities.

Ask how long versions survive

If an error is noticed after the retention window has passed, a technically successful backup may no longer help.

Ask what an export contains

Fields alone may not be enough. Check images, attachments, identifiers, relationships and documentation needed to interpret the data.

Ask who can request a restore

Know the support route, authorisation requirements and what staff should do if the normal administrator is unavailable.

An export is valuable, but do not assume it is a complete backup

Exports are excellent for portability and independent access. Their weakness is that they may preserve only part of the system.

What to check in museum collection database exports
Check	Why it matters	Simple test
Fields	A CSV may omit notes, repeating fields or specialist modules.	Compare a complex object record with its exported version.
Identifiers and relationships	Related people, places, objects or loans may depend on internal IDs.	Confirm the export keeps stable identifiers that can reconnect records.
Images and attachments	Media may live outside the database or require a separate export.	Export one record with several images and a document, then verify every file.
File linkage	Files are much easier to rebuild when the export clearly states which record each one belongs to.	Move the export to a clean folder and see whether the relationship is still understandable.
Documentation	Column names and codes may be ambiguous years later.	Ask whether another staff member can understand the export without the original administrator.

Keep one readable route: even when the native database backup is the fastest way to restore the live system, a documented export can provide a second route to the collection data if the original software is unavailable.

The restore test is the part that turns copies into a recovery plan

Testing should answer a museum question: after a real failure, can staff get back to useful collection work?

Restore into a safe test location. Do not overwrite the live system merely to prove that a copy exists.

Practical restore checklist

Test the work people actually need

The database or exported records open successfully.
Recent records and recent edits are present.
Accession and object identifiers remain unchanged.
Locations, relationships and repeating fields still make sense.
Images and attachments are present and linked to the right records.
Search returns expected results.
User access can be re-established safely.
A fresh export can be produced from the restored copy where relevant.

Record the result: note the test date, the backup used, who performed the restore, what was checked and what failed. A failed test is useful information because it reveals the weakness before an emergency.

Verify integrity as well as successful copying

A completed backup job proves that a process ran. It does not by itself prove that every file is unchanged or that the database backup can be restored.

For museum images, documents and other file-based digital material, checksums can provide a practical fixity check. A checksum is a value calculated from a file. If the file changes because of corruption or an unintended alteration, a later checksum comparison can reveal that the copy is no longer identical.

Checksums do not replace backup copies and they do not prove that a database is logically correct. Use the verification features provided by the database or backup system where available, watch for failed jobs and unusual backup sizes, and still perform a real restore test.

For image-heavy collections, keep the relationship between identifiers and files understandable as well. The museum’s image file naming method should make it easier to compare, migrate and recover the correct files without guessing.

Integrity check

Use several kinds of evidence

Backup or export job completed without errors.
File counts and expected storage size look plausible.
Checksums or fixity checks pass for important file sets where used.
The database backup passes any built-in verification available to the system.
A sample of recent images and attachments opens correctly.
A full restore test proves that records and linked files can be used together.

Think of integrity as early warning: a fixity failure tells the museum that a copy has changed. The recovery plan still needs another known-good copy and a documented way to restore it.

Design the plan around ordinary failure scenarios

A backup strategy becomes clearer when the museum asks what would happen in specific incidents instead of discussing storage in the abstract.

One record was deleted

Can the museum recover that record or a previous version without rolling the entire database back and discarding newer work?

The main computer failed

Can staff identify the latest good database, the linked files and the steps needed to move work to another machine?

The building is inaccessible

Is at least one usable copy available away from the museum, together with the credentials and instructions needed to reach it?

The cloud service is unavailable

Does the museum have a recent independent export or other route to essential collection information while the service is down?

Ransomware reaches shared storage

Is there a versioned, offline, immutable or otherwise separated copy that ordinary infected accounts cannot immediately overwrite?

The main administrator leaves

Can another authorised person find the backup locations, schedules, supplier contacts, restore notes and current access procedure?

A practical small-museum backup plan

The exact tools will differ, but a simple written pattern makes responsibilities and gaps visible.

Example museum collection database backup plan
Item	Working approach	Evidence to keep
Active database	Automated backup at a frequency matched to daily editing, with multiple retained versions.	Job history, latest successful run and storage capacity check.
Images and attachments	Separate protected copy if the files are not already included with the database backup.	Folder or object count, recent sample files and a documented link to the record structure.
Off-site copy	A copy stored away from the primary system and main building or account.	Last update date and confirmation that authorised staff can reach it.
Independent export	Regular export from the collection system, including enough documentation to interpret the files.	Export date, file list and a checked sample of complex records.
Restore test	Restore to a safe test environment on a written schedule and after major system changes.	Test log, backup used, results, failures and corrective action.
Responsibility	One named role owns the routine and another person can verify or continue it.	Short written procedure, supplier contacts and handover notes.

Keep the document short enough to use: a one-page operating procedure that names the systems, copies, locations, schedule, owner and restore test is more useful than a long policy nobody consults during an incident.

Keep a small backup and restore log

A log provides continuity when staff change and helps the museum notice that a supposedly routine process has stopped being routine.

Record

Date and time of the backup or export

Record

System, database or file set protected

Record

Destination and version or retention point

Record

Success, warning or failure status

Restore test

Backup used and test environment

Restore test

Checks completed and problems discovered

Do not put live passwords into the backup log. Record the approved credential or access procedure instead.

A 10-question museum backup audit

A small museum should be able to answer these questions without opening a technical manual or waiting for one specialist to return.

Coverage and separation

Can you answer yes to all five?

Do we know exactly which database, images, attachments and configuration are included?
Is at least one usable copy kept away from the primary system or building?
Are several versions retained so yesterday’s error does not overwrite every copy?
Are ordinary users prevented from deleting every backup copy?
Do we have a museum-controlled export or another independent route to essential records?

Recovery and continuity

Can another person recover the collection?

Can a second authorised person find the copies and the recovery procedure?
Have we restored a backup into a safe test environment?
Did we check recent records, identifiers, searches, images and attachments after restoration?
Do we know roughly how much data loss and downtime the museum can accept?
Is the latest successful restore test recorded, including failures and corrective action?

If any answer is no: the backup plan has a specific gap to document and fix. That is more useful than simply describing the museum as “backed up”.

Backup red flags for a museum collection system

Most weak plans are not completely absent. They contain one assumption that makes every other step less useful.

Only the database file is protected

Images and documents sit elsewhere, so the restored catalogue opens with broken links or missing evidence.

Every copy is in one building

The museum has several copies but one theft, flood, fire or electrical incident can still remove all of them.

The drive stays permanently connected

The backup may be exposed to the same malware, deletion or account permissions as the working files.

The supplier says “backups included”

Nobody has written down retention, restore scope, response route or whether the museum can obtain an independent copy.

No previous versions are kept

A corrupted or accidentally edited state may overwrite the only backup before anyone notices the problem.

No restore has been tested

The museum knows that files were copied but does not know how long recovery takes or whether the result is complete.

A strong backup plan is boring: it runs routinely, failures are noticed, copies are separated, the recovery steps are written down and another person can restore the collection without guessing.

Frequently asked questions

Direct answers to practical questions about museum collection database backups.

What should a museum collection database backup include?

It should protect the collection records and every file needed to make those records useful again, including linked images, attachments, configuration or documentation where relevant, and a usable export of the data.

How often should a museum database be backed up?

The schedule should reflect how much work the museum can afford to lose. An actively edited database may need automated daily or more frequent protection, while less active material may use a different schedule.

Is an external hard drive enough for a museum backup?

Not by itself. A single drive can fail, be lost, be stolen or be damaged in the same incident as the main computer. It is better used as one copy within a broader backup plan.

Does a cloud museum database still need a separate backup?

The museum should understand exactly what the provider backs up, how long versions are retained and what can be restored. A regular independent export gives the museum another recovery and migration route.

Is exporting a museum database the same as backing it up?

Not always. An export may preserve important records in usable formats but may omit images, attachments, audit history, relationships or system configuration. Check the export contents rather than assuming it is complete.

How do you test a museum database backup?

Restore a copy into a safe test location and check that the database opens, recent records exist, identifiers and relationships remain intact, images and attachments are available, and staff can perform key searches and exports.

What is the 3-2-1 backup rule for museums?

It is a practical model of keeping at least three copies of important data, using two different storage approaches, with one copy kept away from the main location.

Who should be responsible for museum backups?

Responsibility should be assigned to a named role, with a second person able to verify the process. The museum should record when backups and restore tests were completed so the plan does not depend on one person remembering it.