Enterprise Backup Architecture

Enterprise backup architecture is the system behind the backup jobs. It connects business recovery requirements to workload protection, copy storage, security controls, operations, and tested recovery.

The architecture succeeds when a required service can return to a usable state within its recovery targets. A large repository and a high job-success rate do not prove that result.

Use this mental model:

business services and risk
           |
           v
recovery policy and service tiers
           |
           v
workload protection -> data movement -> recovery copies
           |                 |               |
           +---------- control plane --------+
                             |
                             v
               restore, validation, evidence

Each layer has a different job. Keeping those jobs explicit prevents a product feature from becoming an accidental architecture.

Start with the service, not the server

A business service can depend on databases, files, virtual machines, identities, name services, certificates, keys, network configuration, deployment code, and external providers. A server inventory shows assets. A service map shows what must work together after recovery.

Begin with a business impact analysis. Identify service owners, critical processes, dependencies, and failure consequences. Then define four requirements for each service:

• Recovery point objective, or RPO: the maximum acceptable data gap, expressed as time.
• Recovery time objective, or RTO: the target limit for returning the service.
• Retention: how long selected recovery points must remain available.
• Recovery scope: the smallest unit and the largest coordinated set you must restore.

These requirements are related but independent. A service can need a fifteen-minute RPO, a four-hour RTO, and seven years of monthly retained copies. One schedule cannot express all three.

Treat exclusions as design decisions. NIST permits data to remain unprotected when it has no organizational significance or can be recreated within the required RTO. Document the owner, reason, and recreation path. An undocumented exclusion is a coverage gap.

Convert requirements into protection tiers

An enterprise may contain thousands of workloads. Designing each one independently creates policy drift and operational cost. Group workloads into a small set of protection tiers.

A tier defines a service contract:

Element	Tier decision
Recovery objectives	RPO and RTO
Copy schedule	Continuous, hourly, daily, weekly, or another cadence
Retention	Number and age of retained recovery points
Protection method	Snapshot, backup, log capture, replication, or a combination
Copy locations	Local, remote, offline, immutable, or isolated
Restore assurance	Test scope and frequency
Security	Encryption, roles, credential boundary, and deletion controls
Cost boundary	Capacity, transfer, software, and operational budget

Keep the number of tiers small enough to operate. Allow an exception only when a named requirement cannot fit a standard tier. Record the exception and its owner.