Design a Ransomware-Resilient Backup for a 100TB Dataset

Designing a backup strategy is judgment under constraints: scale, cost, recovery objectives, and a threat model that now includes an adversary actively trying to destroy your backups. The principles from the last two lessons — 3-2-1, RPO/RTO, immutability, isolation, restore testing — are the same at any size, but at 100 TB the tradeoffs get real: full backups are slow and expensive, restore time becomes a serious engineering problem, and "just keep more copies" runs into a budget.

In this exercise you design the backup strategy for Atlas Genomics, a company with a 100 TB dataset of customer genomic and clinical data in the cloud. The business has set RPO 1 hour and RTO 12 hours for this dataset, it is regulated (HIPAA + contractual), and cost is a real constraint. Each scenario has one best answer; the explanations are the reasoning you'll reuse designing real backup strategies. Work each the way you worked the encryption-strategy exercise: decide the control, then justify it with the evidence and tradeoffs.

Kicking off a nightly full backup of 100TB

Scenario 1: Meeting the RPO at scale

Quick check

The dataset is 100 TB and the RPO is 1 hour. A nightly full backup is proposed. Why won't it work, and what's the right approach?

Nightly full backups are fine — they are the most thorough option

A nightly full backup guarantees up to ~24 hours of data loss, far exceeding the 1-hour RPO, and re-copying 100 TB nightly is slow and costly; use an incremental-forever / continuous approach — periodic baseline plus frequent incrementals or continuous replication / change-data-capture — so recovery points land within the hour without re-moving the full dataset each time

Lower the RPO expectation to 24 hours so the nightly backup qualifies

Take a full backup every hour to meet the RPO

Scenario 2: Meeting the RTO at scale

Quick check

The RTO is 12 hours. Restoring 100 TB from cold archival storage (e.g., deep-archive tier) is estimated to take 30+ hours due to retrieval and transfer time. How do you resolve this?

Ignore the RTO — 30 hours is close enough

Tier the backups so the most recent recovery point sits in a warm tier that can be restored within the 12-hour RTO, while older copies age into cheaper cold/archive tiers for long-term retention; validate the warm-tier restore time with an actual test

Move everything to the most expensive hot storage permanently

Extend the RTO to 30 hours to match the archive retrieval time

Scenario 3: Ransomware resilience — the copy that survives

Quick check

The team has a same-region backup and a cross-region replica, both in the production cloud account. Is this ransomware-resilient? What's missing?

Yes — two copies in two regions is sufficient

No — both copies live in the production account, so a credential or account compromise can delete or encrypt them; add an immutable copy (Object Lock / WORM with a defined retention) in an isolated account with separate credentials, so at least one copy is unreachable and undeletable by an attacker who owns production

Yes, as long as the replica is in a different region

No — the fix is simply to make more copies in the same account

Scenario 4: Encryption and key dependency

Quick check

The backups are encrypted with a customer-managed key (good). An engineer suggests using the SAME KMS key that encrypts the production database, to keep key management simple. What's the risk?

No risk — reusing the key is simpler and the data is the same

A shared key creates a dangerous dependency: if that key is compromised, disabled, or deleted (accidentally or by an attacker with key access), you can lose access to BOTH production and its backups at once; the immutable/isolated backup copy should use a separate key whose access is independent of the production environment

The only risk is slightly slower encryption performance

Reusing the key is required so the backups can be decrypted

Scenario 5: Proving it works

Quick check

Leadership wants assurance that Atlas could actually recover from a ransomware event. What demonstrates this best?

A document describing the backup architecture and stating the RTO/RPO targets

A documented restore test: actually restoring the dataset (or a representative subset) from the immutable copy into a clean environment, measuring that it completed within the 12-hour RTO and lost no more than the 1-hour RPO, validating data integrity, and recording the date, duration, and any issues found

A vendor brochure for the backup tool listing its features

Confirmation that backup jobs are running successfully each hour

Putting it together: the backup design

A finished ransomware-resilient design for Atlas's 100 TB dataset comes together as a layered set of decisions:

Decision	Choice for Atlas (RPO 1h / RTO 12h, 100 TB, regulated)
Backup method	Baseline + frequent incrementals / continuous replication (meets 1h RPO at scale)
Copies & locations	Production + warm same-account copy + cross-region copy + isolated-account immutable copy (3-2-1-1)
Restore tiering	Recent recovery point in a warm tier (restores within 12h RTO); older copies age into cheap archive for retention
Immutability	Object Lock / WORM with a defined retention on the isolated copy — undeletable even by admins/attackers
Isolation	Immutable copy in a separate account with independent credentials, outside the production blast radius
Encryption / keys	CMK encryption; the isolated copy uses a separate key independent of production keys
Proof	Scheduled restore test from the immutable copy; measured against RTO/RPO; integrity-validated; dated record

Two patterns to notice. First, the principles (3-2-1-1-0, RPO/RTO, immutability, isolation, restore testing) are identical to a small dataset — but at 100 TB the design is shaped by cost and time at scale, which is why incremental methods and storage tiering appear. Second, every decision is chosen for the evidence and the recovery it enables: the immutable isolated copy exists so you can refuse to pay, and the restore test exists so you can prove, in advance, that you'll actually recover within the objectives.

How to use this in practice

When you design or review a backup strategy as a GRC Engineer, work the same questions regardless of scale: does backup frequency meet the RPO; does the restore architecture (and storage tier) meet the RTO; is there an immutable, isolated copy that survives a ransomware-grade attacker; are backup keys independent of production keys; and is there a recent restore test proving it all works. Then write down the rationale and the constraints — why incrementals instead of fulls, why a warm tier for the recent copy, why a separate key. That documented reasoning, plus the restore-test record, is what turns a backup configuration into a defensible, auditable recovery program — and it's exactly what an auditor and a board both ask for after the word "ransomware" enters the conversation.