PicaJet

Reference Glossary

Backup and disaster recovery

Maintaining redundant copies of DAM assets plus a tested procedure to restore the library after hardware failure, corruption, ransomware, or a vendor outage.

Why it matters in a DAM

In DAM the library is often the only surviving high-resolution master of assets whose originals can't be reshot — a discontinued product, a one-time event, a freelancer who's no longer reachable — so losing it is permanent, not merely inconvenient. Cloud DAM vendors run their own infrastructure backups, but that doesn't cover accidental bulk deletion by an authenticated user, malicious internal edits, or the vendor itself shutting down — cases where the customer needs its own independent export. Recovery targets (how fast, how much data can be lost) belong in the vendor contract as explicit numbers, not as an assumption.

A worked example

RPO (Recovery Point Objective) Maximum acceptable data loss — e.g. no more than 24 hours since last backup
RTO (Recovery Time Objective) Maximum acceptable downtime — e.g. service restored within 4 hours
3-2-1 rule 3 copies of each asset, on 2 different media types, 1 copy off-site or off-vendor

Common mistake

Teams assume "the vendor has backups" is sufficient and never test restoring their own asset export, discovering only during a real incident that the last full export is a year old, missing custom metadata fields, or was never actually configured to run.

Backup and disaster recovery (BDR) in a DAM context covers two related but distinct guarantees: that copies of every asset exist somewhere safe, and that there’s a tested, timed procedure to bring the system back after something goes wrong. The two numbers that matter in any DR plan are the Recovery Point Objective (how much data, measured in time, the organization can afford to lose) and the Recovery Time Objective (how long the system can be down before the business is materially harmed). Neither number is meaningful unless it’s written into the vendor’s contract and actually tested — a backup nobody has ever restored from is a hypothesis, not a safeguard.

The 3-2-1 rule — three copies of data, on two different types of media, with one copy off-site — predates cloud DAM by two decades. It was popularized by photographer Peter Krogh in his 2005 book The DAM Book: Digital Asset Management for Photographers, written for professionals who had just discovered that a single failed hard drive could wipe out a career’s worth of irreplaceable images. The principle still applies directly to modern DAM: a SaaS vendor’s own redundancy satisfies part of the rule, but an organization that never exports its own independent copy is trusting a single party with its entire visual history.

Cloud DAM buyers often conflate the vendor’s infrastructure resilience (protection against server failure, data-center outage) with protection against their own operational mistakes. A vendor’s disaster recovery plan will restore the platform if a data center burns down; it will not undo a bulk-delete triggered by a misconfigured automation rule, or recover metadata a departing admin altered before leaving. Those scenarios require the organization’s own periodic, verified export — assets plus full metadata, not just files.

Frequently asked

What are RPO and RTO in a DAM disaster recovery plan?

RPO (Recovery Point Objective) is the maximum acceptable data loss, like no more than 24 hours since the last backup; RTO (Recovery Time Objective) is the maximum acceptable downtime, like restoring service within 4 hours.

What is the 3-2-1 backup rule?

Three copies of each asset, on two different media types, with one copy off-site or off-vendor — a principle popularized by photographer Peter Krogh in his 2005 book "The DAM Book."

Does a cloud DAM vendor's own backup cover accidental bulk deletion by a user?

No — vendor infrastructure backups protect against server failure or data-center outage, but not accidental bulk deletion, malicious internal edits, or the vendor itself shutting down.

Why is losing a DAM library often permanent, not just inconvenient?

The library is often the only surviving high-resolution master of assets whose originals can't be reshot — a discontinued product, a one-time event, or a freelancer who's no longer reachable.

What's the common mistake organizations make about backups?

Assuming "the vendor has backups" is sufficient and never testing their own restore, only discovering during a real incident that the last export is outdated or missing custom fields.

What should an organization's own backup export actually include?

Assets plus full metadata — not just files — since a restore missing custom fields or rights annotations isn't a real recovery of the library.

Sources

  • Peter Krogh popularized the 3-2-1 backup rule — three copies of data, on two different media, with one copy off-site — in his 2005 book The DAM Book: Digital Asset Management for Photographers. checked 2026-08-07Backup Wrap-up podcast, interview with Peter Krogh