An untested backup is not a backup: the quarterly validation protocol

Most companies have backup configured. Almost none tested it in the last year. When the incident hits, they find out the backup was broken, incomplete, or impossible to restore. See the 4-step protocol senior squads run quarterly.

Por Victhor Araújo

Victhor Araújo

In 2025, three public Brazilian cases involved companies that discovered, on incident day, that the backup configured 18-24 months ago didn't work: corrupted file, incompatible schema, or simply hadn't run in the last 60 days without anyone noticing. Recovery that should take hours took weeks — or never happened.

The rule is simple: an untested backup isn't a backup, it's operational fiction. A senior squad runs a quarterly validation protocol with every client — 4 steps, 4 hours, once every 3 months. Revin runs this since 2023 and publishes the checklist for any client to replicate.

For CTOs, ops heads, and founders who assume backup is fine because 'we set it up a while ago' — without having tested in the last year.

Real restore in isolated environment is the only test that counts — not just job log check

📋 The 4-step protocol

Step 1 — List every critical backup (1h)

Inventory of everything that would need restoring in an incident: transactional databases, blob storage with client data, infra configuration (IaC, secrets), client email history, code repos (yes, GitHub goes down too).

Output: list prioritized by criticality (P0 = stops business, P1 = degrades operation, P2 = inconvenience).

Step 2 — Real restore in an isolated environment (2h)

Not just checking the backup job log. Real restore into an isolated environment (anonymized staging or ephemeral environment created for the test). Validate data integrity, schema compatibility, application reads.

Common mistake: assuming 'job ran successfully' means 'backup works'. It doesn't. File can be corrupted, format can be old, dependency can be missing.

Step 3 — Measure real RPO and RTO (30 min)

RPO (Recovery Point Objective): how much data is lost between the last backup and the incident. If backup is daily at 3am and incident is 5pm, RPO = 14h of lost data.

RTO (Recovery Time Objective): how long restore takes. Timed in the test. If it took 6h in an isolated environment, in production under pressure it'll take 8-10h.

Compare to business expectation: would the CFO expect 30 min RTO? Does current backup deliver 8h? Documented gap.

Step 4 — Document and adjust (30 min)

Test output: 1 page with: what was tested, what worked, what failed, next actions before the next test.

If it failed: immediate allocation to fix. It's not 'we'll look' — it's P0 until next quarter.

A senior squad validates backup every quarter in 4 steps — public checklist available

🚧 The 4 false senses of security

• 'Job shows as success in the console': only means it ran. Doesn't mean data is intact.
• 'Cloud provider does the backup': usually snapshots infra, not application data. Check contract.
• 'We have active replication': replication isn't backup. A production bug propagates to the replica — including accidental deletion.
• 'We tested 6 months ago': a lot changes in 6 months. Schema, DB version, new integration. Quarterly is the minimum.

🛠️ How Revin runs this by default

Across all Revin clients, the 4-step protocol runs automatically on the calendar (quarterly). Tech lead facilitates, 2 seniors present. Output goes to the client as a report. If something failed, P0 opens in the backlog before the next sprint.

📢 Want to run this protocol on your current system? Book a Diagnostic Sprint — Revin executes the first cycle in 1 week and delivers checklist + report to repeat quarterly.

🎯 Conclusion: backup is quarterly practice, not one-time setup

Configuring backup is a 1-day task. Validating quarterly is ongoing practice. Senior squads run both; generic squads run only the first and discover the mistake on incident day.

📢 See Revin's Security Foundations model — backup validation is part of the scope.