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
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?
The 3-2-1 rule means three total copies of each asset — the original plus two backups — stored on two different media types (for example, cloud storage plus an external drive or a second cloud provider), with at least one copy kept off-site or off-vendor. This spreads risk so a single fire, ransomware attack, or vendor outage can't wipe out every copy at once. Photographer Peter Krogh popularized the principle 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 are designed to recover from server failure, hardware corruption, or a data-center outage — they replicate whatever state the system is in, including deletions a user made on purpose. If someone bulk-deletes assets or tags, that action typically propagates to the backup too. Real protection against human error requires version history or a trash bin with its own retention window, or an independent export the organization controls itself.
Why is losing a DAM library often permanent, not just inconvenient?
A DAM library isn't just a folder of files — it's years of manual work: keywording, custom metadata fields, rights and usage annotations, collections, and relationships between assets. Losing it means losing that accumulated labor, not only the pixels. Worse, many assets are irreplaceable: a discontinued product, a one-time event, or a freelancer who's no longer reachable means the original can never be reshot or resubmitted.
What's the common mistake organizations make about backups?
Assuming the vendor's own backups are enough, and never testing their own restore process. Teams treat "the vendor has backups" as a complete safety net, skip building an independent export routine, and only discover the gap during a real incident — when the last export turns out to be outdated, missing custom metadata fields, or missing the folder structure needed to make the files usable again.
What should an organization's own backup export actually include?
Files alone aren't a recovery — a real export needs the assets plus their full metadata (keywords, custom fields, rights and usage annotations), the folder and collection structure, and user permissions or access rights. Without metadata and structure, a restored library is just a pile of unlabeled files; without permissions, rebuilding who can see or edit what becomes a manual project of its own.
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-07 — Backup Wrap-up podcast, interview with Peter Krogh