A backup and data-protection platform stores enormous volumes across many customers. What determines whether the architecture is actually a recovery system rather than a storage system?

The distinction

Backups are trivially easy and recovery is the product. A system that writes copies reliably and has never been asked to restore under pressure is a storage bill, not a data-protection platform.

The properties that separate them:

• Recovery time is designed, not discovered. The architecture must be shaped by the RTO. Restoring a hundred terabytes at a given throughput takes a calculable number of hours, and if that exceeds the RTO the design is wrong regardless of how good the backups are.
• Granular recovery. Most real restore requests are for one mailbox, one file, one table, one point in time — not the whole estate. A design optimised only for full restore serves the rare case and fails the common one.
• Recovery is tested continuously, not annually. Automated restore verification of sampled backups is the only evidence the backups are usable, because a corrupt or unreadable backup is indistinguishable from a good one until you try.

What deduplication buys and what it risks

Global deduplication across customers gives enormous storage efficiency, because most enterprise data is duplicated many times over. It introduces two hazards that shape the architecture:

• A corrupted shared block affects every backup referencing it, so integrity verification and redundancy on the deduplication store are disproportionately important.
• Deletion becomes reference counting, and a bug in it either leaks storage forever or deletes data still referenced. This is where the hardest bugs in such platforms live.

There is also a tenancy question: cross-tenant deduplication is efficient and requires strong cryptographic separation to be defensible, since block-level sharing across customers is exactly the thing a security review will interrogate.

The immutability requirement

Modern data protection must assume the attacker reaches the backups. That means write-once storage with a retention lock that the platform's own administrators cannot override, air-gapped or logically isolated copies, and an alerting path for mass-deletion attempts.

A backup an administrator can delete is not protection against the scenario that most often needs it.

The metric that matters

Not backup success rate, which is near 100% in every organisation including those that cannot restore. The metric is verified recovery rate against the stated RTO for a representative sample, measured continuously. Anything else measures whether copies were written.