Backup, archive & DR

RPO, RTO and copy strategy

How much data a service may lose and how long it may be down, and what that implies for mechanisms and copies. Definitions are from NIST SP 800-34 Rev. 1; copy roles from NIST SP 800-209. Target values belong to your scenario or business impact analysis, not to this page. Arithmetic marked “derived” is Cloudbit’s. Sources checked 5 Oct 2026.

Definitions

NIST SP 800-34 Rev. 1 (§3.2.1) defines three terms. MTD is the total outage the owner will accept. RTO is the longest a system can be unavailable before the impact on other systems, processes and the MTD is unacceptable. RPO is the point before the outage to which data can be recovered, set by the latest usable copy. NIST notes that RPO is not part of the MTD: it measures data-loss tolerance, not downtime (NIST SP 800-34 Rev. 1).

Tiering: which mechanism can meet which RPO

Group applications into a few tiers, each with an RPO and an RTO. The RPO sets the mechanism. A schedule that runs less often than the RPO cannot meet it, however fast the jobs are.

Short-RPO tiers need replication, CDP or frequent off-array snapshots, with backup behind them for corruption and ransomware. Every tier needs backup; only some need replication.

RTO is a restore-throughput problem

RTO covers detection and decision, rebuilding dependencies (identity, DNS, network policy), moving data and starting applications. The data-movement part gives a minimum sustained throughput (derived):

Required restore rate = data to restore ÷ (RTO − time for detection, decision, dependencies and app start)

Illustrative only: restoring 20 TB with 2 h left for data movement needs 20 × 10¹² × 8 b ÷ 7,200 s ≈ 22 Gb/s sustained from the target, through the network, into storage that can absorb it. If no target and path can sustain that, the tier needs a replica to fail over to, not a restore. Datasheet ingest rates are not restore rates; measure restore throughput in the proof of concept.

Copy strategy

3-2-1-1-0 is a vendor heuristic (Veeam) extending 3-2-1: three copies, on two media types, one offsite, one offline, air-gapped or immutable, and zero errors after recovery verification (Veeam). It is not a standard. The vendor-neutral basis is NIST SP 800-209 §4.7: keep copies for ordinary recovery, plus cyber-recovery copies that are hardened, locked and isolated (NIST SP 800-209). Decide per tier which copies exist and which of them count as cyber-recovery copies.

Backup capacity follows retention, change rate and data reduction, all of which vary by workload. Measure them; treat any capacity multiple of primary as a planning assumption until a pilot confirms it.

RPO and RTO design / build / manage

Design

• Run a business impact analysis; set RPO and RTO per tier from it
• Pick a mechanism per tier that meets the RPO; check the restore rate against the RTO
• Name the cyber-recovery copies per tier

Build

• Measure write and change rates per tier before sizing anything (Method)
• Prove restore throughput in the proof of concept, end to end

Manage

• Track achieved RPO (replication lag, last good copy) per tier, not just job success
• Re-tier applications when they change; re-check capacity assumptions yearly

Backup platforms and targets

Platform delivery models, data paths and target media. Array snapshots and object platforms are on Storage; tape library models on Storage: Tape. Vendors are compared in Market leaders. Sources checked 5 Oct 2026.

Delivery models

Data paths and the catalog

How data reaches the target decides which network segments carry it: an agent in the guest sends over the IP network; a hypervisor-API proxy reads virtual disks; storage-integrated backup reads array snapshots over the storage network. Record the path per workload, because each one becomes a flow in the backup network design. The backup catalog and configuration database are what make restores possible: protect them with their own copy and include their recovery in the runbook.

Targets: disk, object, tape

Platforms design / build / manage

Design

• Choose the delivery model by who will harden and operate the repository
• Record the data path per workload; choose a target per copy

Build

• Size proxies and repositories for both ingest and restore throughput
• Protect the catalog and configuration database with their own copy

Manage

• Monitor window overruns and repository capacity trend
• Keep backup software, proxies and repositories on a patch track (Security: Lifecycle)

Immutability and cyber recovery

How copies are locked, who can unlock them, and how they are restored after an attack. Admin identity and PAM are on Security: Identity; the vault network is in Vault air gap. Sources: NIST SP 800-209, AWS S3 documentation, Veeam and LTO documentation. Product behaviour changes by release. Sources checked 5 Oct 2026.

Lock mechanisms

Object Lock rows are from AWS S3 documentation. On-prem S3-compatible stores implement Object Lock to different degrees; confirm compliance-mode behaviour per product. Hardened repository row from Veeam Help Center.

The admin plane is the real lock

Every lock trusts an admin plane and a clock. NIST SP 800-209 asks that management of cyber-recovery storage be separate from production and from the ordinary data protection system, not reachable with their credentials, on an isolated network (IS-SS-R2), and that unneeded services and interactive web interfaces be disabled where possible (IS-SS-R6). Backup administrators get separate identities (Security: Admin tiering). Protect the time source the locks rely on.

Clean-room restore

NIST SP 800-209 IS-SS-R7: do not mount cyber-recovery copies on production hosts; push restores to an isolated staging environment. Scan and validate there before reconnecting. CISA also recommends keeping golden images and offline copies of infrastructure-as-code templates (CISA).

Immutability design / build / manage

Design

• Choose a lock mode per copy and write down who can bypass it
• Place the backup admin plane on a separate identity and network

Build

• Test that a backup admin cannot delete or shorten a locked copy
• Build the clean-room environment before you need it

Manage

• Audit lock mode, default retention and bypass rights; alert on any change
• Review who holds backup admin and security-officer roles each quarter

Replication and CDP

Replication types compared at the level of design choice. Array data services are on Storage; HCI built-in replication and stretched clusters on HCI. Bandwidth is in Replication bandwidth. Product RPO ranges change by release. Sources checked 5 Oct 2026.

Replication types

Replication is not backup. Every type above copies corruption and encryption. NIST SP 800-209 IS-SS-R5 says DR replicas and cyber-recovery copies should not depend on production baseline data. Pair every replicated tier with backup copies that have their own retention and locks.

Synchronous distance. Each product publishes its own round-trip latency limit for sync or metro modes. That limit, not the bandwidth, caps how far apart the sites can be; check it before the DR location is fixed.

Replication design / build / manage

Design

• Pick one replication layer per tier; avoid stacking two without a reason
• List tiers that need sync and hand their latency limit to Facility and Network

Build

• Define consistency groups around application boundaries
• Encrypt replication in transit (NIST SP 800-209 DP-SS-R7)

Manage

• Alert on replication lag against each tier’s RPO
• Test failover to the replica and failback

Archive and retention

Long-retention copies and the policy that governs them. Tape library models are on Storage: Tape. LTO generation details change; recheck before buying. Sources checked 5 Oct 2026.

Retention policy

NIST SP 800-34 Rev. 1 §3.4.2 expects the backup policy to state frequency, scope, storage location, media rotation and offsite transport. Separate operational retention (how far back you can restore) from records retention (how long you must keep data), and handle legal holds separately from both. NIST SP 800-209 IS-SS-R5 asks that archives not depend on production or DR baseline data.

Media migration

LTO-10 has no backward read or write compatibility with earlier generations (LTO). If retention outlasts a drive generation, plan either to keep older drives in service or to migrate data to new media, and budget the time that takes.

Archive design / build / manage

Design

• Write the retention policy per data class, including legal hold

Build

• Set up offsite transport and custody records for tape

Manage

• Track media generations against retention; schedule migrations
• Test reads from the oldest media you still hold

DR design

How the DR target is used, in what order services come back, and how recovery is proved. Where the DR site is and its rating are on Facility: DR location; DCI on Network: DCI and cloud on-ramps on Network: Edge. Sources: NIST SP 800-34 Rev. 1, CISA. Sources checked 5 Oct 2026.

DR target: second colo or cloud

NIST SP 800-34 Rev. 1 §3.4.3 describes cold, warm, hot and mirrored alternate sites. The site type sets the RTO you can reach: a cold site cannot meet a short RTO however good the backups are.

Runbooks and recovery order

Write the runbook in dependency order: identity and DNS first, then network and firewall policy at the DR site, then the data tier, then applications. Nothing logs in until identity works, so its recovery is the first step and the first test. Keep break-glass credentials that do not depend on the identity system being recovered (Security: Break-glass). For a cyber event, restore into the clean room, not straight into production.

Restore testing

NIST SP 800-34 Rev. 1 §3.1 has plans reviewed and recovery capabilities and personnel tested annually. CISA recommends regularly testing the availability and integrity of backups in a disaster recovery scenario (CISA). Use non-disruptive test failover where the platform supports it; Hyper-V Replica, for example, runs an isolated test copy without affecting production or replication (Microsoft). Record the achieved RPO and RTO each time, and compare them with the targets.

DR design / build / manage

Design

• Choose the DR site type that can meet each tier’s RTO
• Write runbooks in dependency order, identity first

Build

• Pre-stage DR network policy and identity at the DR site
• Run a first full failover test before go-live

Manage

• Test at least annually; record achieved RPO and RTO
• Update runbooks after every test and every major change

Backup network decisions

What Backup decides for the network: how the backup estate is isolated, how much bandwidth replication needs, and how the vault is cut off. Network owns the plumbing and the shared definitions: oversubscription and ECMP in Fabric design; VRF/VNI design in VNI/VRF design, MTU in MTU, and the multi-site overlay in Multi-site; firewall insertion in Service insertion; DCI circuits and transport encryption in DCI, carriers in Edge. Security owns the zone model (Policy model) and admin identity (Identity). Storage-network flows are on Storage networking. Arithmetic marked “derived” is Cloudbit’s and is open to review. Sources checked 5–6 Oct 2026.

Backup network isolation

• Its own zone and VRF(s). Backup is a zone in Security’s policy model. Put proxies, media servers and repositories in a backup data VRF. Put the backup servers, catalog and consoles in a separate in-band backup management VRF, not on the OOB network: they reach proxies and agents in production and backup VRFs, so OOB placement would bridge management into the data plane. Only their BMCs go on the OOB. The cyber-recovery vault is not on the production fabric at all (Vault air gap). VRF and VNI mechanics are on Network: VNI/VRF design.
• One policy point. Flows between production zones and the backup VRF cross a firewall at the insertion point Network defines (Service insertion), or a fabric route leak only where the policy model marks the flow L3/L4-only. Permit only the backup platform’s documented ports, in the direction each one is initiated, per data path. Include restore flows: they run the other way and are the ones most often missing when they are needed. Restores must cross the same firewall in the reverse direction, so the stateful path stays symmetric (Service insertion).
• Inspection vs throughput. Backup streams are bulk transfers. Decide in the policy model whether they need L7 inspection. If they cross an inspecting firewall, size it for the backup-window and restore rates (Security: NGFW sizing).
• Separate admin plane and identity. Backup servers, repositories and appliances authenticate against an identity domain separate from production, with phishing-resistant MFA and PAM (Admin tiering, PAM). Their management interfaces and BMCs are not reachable from production VRFs. For cyber-recovery storage NIST SP 800-209 IS-SS-R2 also requires separation from the ordinary backup system.
• Storage-path backups. A proxy that reads array snapshots sits on both the backup network and the storage network. Treat it as a bridge between zones: harden it and keep it out of production identity.
• Ingest vs oversubscription. Backup is fan-in: many sources write to a few repository ports. Required ingest ≈ data sent in the window ÷ window length (after source-side reduction). Restore is the same path reversed at the rate from Restore throughput, and for short-RTO tiers it is usually the larger number. Place repositories on leaves whose uplinks carry that rate after oversubscription (Fabric design). If the backup segment uses jumbo frames, set them end to end per MTU.

Replication bandwidth from RPO

DCI is sized from this method, so run it before circuits are ordered. Use your own measured rates and your own RPO per tier.

• 1. Measure per tier. For continuous replication and CDP, measure write throughput per source; AWS recommends at least 24 h of data to capture peak and average (AWS DRS). Include month-end and batch periods. For interval replication, measure unique changed data per interval: a block rewritten many times in one period is sent once (Broadcom KB 317503).
• 2. Size on the RPO-length window, not the daily average. Broadcom’s method takes the average change within an RPO period and compares it with the link. A backlog from a burst is fine as long as it drains within the RPO; a daily average hides the busy window (derived).
• 3. Continuous replication. Bandwidth must exceed the combined write throughput of all sources on the path, or replication never converges. AWS recommends at least 20% headroom for burst writes (AWS DRS).
• 4. Interval replication. Worst-case loss ≈ interval (I) + transfer time (T) + apply time (A). So T ≤ RPO − I − A, and T ≤ I or cycles queue. Bandwidth ≥ changed data in the busiest interval ÷ T (derived).
• 5. Synchronous replication. Writes wait for the remote acknowledgement, so the link must carry the peak write rate with no backlog. Latency, not bandwidth, usually limits it (Replication types) (derived).
• 6. Reduction and usable link. Apply compression or dedupe ratios only from a pilot on your data. Broadcom’s planning assumes only 70% of a link is available for replication traffic (Broadcom). Size the DCI for encryption overhead in both MTU and bandwidth (Encryption overhead). NIST SP 800-209 DP-SS-R7 asks for replication to be encrypted in transit.
• 7. Add the other flows on the path. Offsite backup copies, vault sync if the vault is remote, initial seeding (or ship the seed offline), and resync after an outage. Catch-up time ≈ backlog ÷ (usable bandwidth − peak ongoing replication rate during catch-up) (derived). Set a target for it; it is the resync headroom Network adds.

Worked example (illustrative inputs, not a recommendation; derived). Interval replication with RPO 60 min, interval 15 min and apply time 5 min: T ≤ min(15, 60 − 15 − 5) = 15 min. If the busiest interval changes 200 GB after reduction: 200 × 10⁹ × 8 b ÷ 900 s ≈ 1.8 Gb/s, or ≈ 2.5 Gb/s at 70% usable. Resync: a 2 TB backlog on a link with 7 Gb/s usable (70% of a 10G link) and a peak ongoing replication rate of 2 Gb/s during catch-up takes 16 × 10¹² b ÷ 5 × 10⁹ b/s ≈ 53 min.

Hand Network these outputs: required bandwidth per tier and in total, with the measurement window; which tiers are synchronous and their latency limit; the resync and seed targets; which flows share the DCI (replication, backup copies, vault sync) and their priority; and the encryption requirement. Network chooses transport, diversity and QoS (DCI) and the multi-site overlay (Multi-site).

Vault air gap

A physical air gap has no connection at all, as with ejected tape. A logical air gap keeps a physical link but isolates it by control: Dell’s Cyber Recovery reference architecture uses that term for a vault whose replication interface is enabled from the vault side only when new data must come in (Dell H18661, 2022). NIST SP 800-209 IS-SS-R8 treats closing connections between replication windows as a less strict form of air gap, and warns that known air-gap bypasses exist. Vendors implement vaults differently, some as managed services; compare them on the same criteria.

• Control from inside. The component that opens the link sits in the vault and pulls; nothing in production can open it.
• Narrow window, narrow rule. Open the link only for the sync window. Dell recommends a firewall on the vault replication link but no deep packet inspection in that path, for cost and throughput. Permit only the replication flow between the named source and vault target.
• No shared planes. The vault has its own management host inside the vault, its own identity, and no attachment to production VRFs, the production OOB network or production identity (NIST IS-SS-R2). Physically, give it its own access zone (Security: Physical zones).
• Restore inside. Restore and validate in the vault or a clean room before anything moves back to production (IS-SS-R7).
• Size the window. Each sync must move a cycle’s changed data within the window; use step 4 of the bandwidth method with the window as T. If the vault is at another site, add this flow to the DCI.

Backup network design / build / manage

Design

• Add the backup zone, its VRFs and its flow matrix (including restores) to the policy model
• Run the bandwidth method per tier and hand the outputs to Network before DCI is ordered
• Choose the vault category and design its link, firewall and window

Build

• Test default deny from production into the backup VRFs and the vault
• Load-test ingest and restore through the real path, firewall included
• Confirm the vault link is down outside windows and cannot be opened from production

Manage

• Track DCI utilization against replication lag with Network
• Re-measure change rates yearly and after major application changes; re-run the method
• Review backup-zone firewall rules against the matrix (Security: Drift)