All jobs / Database administrator

Disaster Recovery interview questions

Disaster Recovery questions a Database administrator can be asked, from first job to senior. Open one to see the strongest answer and why it works.

1. A team says they do not need backups because they have a replica in another region. What do you tell them?

   The strongest answer: A replica copies whatever happens, a dropped table included, within seconds. Backups give you a point in time before the mistake; the replica protects you from losing the site, not from losing the data

   Why it works: Exactly — they cover different failures, and saying which failure each one covers is what ends the argument.

   • Replicas copy mistakes too.
   • Backups give a point before.
   • A replica covers site loss.
   • Keep both; different failures.

2. Explain RPO and RTO and how they shape a backup design.

   The strongest answer: RPO is how much data we can afford to lose, which sets log-shipping frequency; RTO is how long we can be down, which sets restore speed and whether we need a warm standby

   Why it works: Exactly — the two numbers translate directly into architecture and cost.

   • RPO = acceptable data loss.
   • RTO = acceptable downtime.
   • Both drive design and cost.
   • Agree them, then build to them.

3. Design a disaster-recovery drill for the main database.

   The strongest answer: Pick a scenario, restore into the DR environment from real backups without touching production, point a copy of the application at it, measure against RTO and RPO, and write down every surprise

   Why it works: Exactly — a real restore, measured against the targets, with findings that change the plan.

   • Restore from real backups.
   • Measure against RTO and RPO.
   • Test the application against it.
   • Record every surprise.

4. You are writing the restore runbook a colleague will follow at three in the morning, possibly for the first time.

   What goes into it?

   The strongest answer: Where the backups are and how to reach them, the exact commands in order, how to verify each step, who authorises the start and who is told — and when it was last walked through

   Why it works: Right — commands, verification, decision rights and proof of freshness; an untested runbook is only a guess written down.

   • Exact commands, in order.
   • Say how to verify each step.
   • Name who decides and who is told.
   • Date the last walk-through.

5. You are setting up database on-call for a small team. What do you put in place?

   The strongest answer: Alerts that mean action, runbooks for each one with the exact queries and decisions, a clear escalation path, and a review of every page so noisy alerts are removed

   Why it works: Exactly — actionable alerts, executable runbooks, and a feedback loop.

   • Alerts that mean action.
   • Runbooks with real queries.
   • Rotate the pager.
   • Review every page.

6. Checksum failures are climbing on the primary of the order system; some reads return errors and the standby may have replicated the damage.

   You are the incident commander. What are your first moves?

   The strongest answer: Stop the spread: fence writes, preserve the corrupted files and logs, check whether the standby shares the corruption, choose between a clean standby and a point-in-time restore against the RPO, and announce a status cadence

   Why it works: Exactly — contain, preserve, assess the standby, choose the recovery path deliberately, communicate.

   • Contain writes first.
   • Preserve evidence.
   • Verify the standby is clean.
   • Choose the path against RPO; communicate.

7. Leadership wants the database to survive a full region outage. How do you approach it?

   The strongest answer: Clarify the RPO and RTO for a regional loss, then design a cross-region standby with matching replication — usually asynchronous, with the accepted loss stated — plus fenced promotion, application cut-over and a drill

   Why it works: Exactly — the honest conversation about loss and latency comes before the topology.

   • Regional RPO and RTO first.
   • State the accepted loss.
   • Fenced promotion and cut-over.
   • Drill it.

8. During a long database outage, executives keep asking for updates. How do you communicate?

   The strongest answer: A fixed cadence of short updates — what is broken, what we know, what we are doing, the next decision point, when the next update comes — on one channel, no speculation about fix time

   Why it works: Exactly — predictable, honest, and separated from the technical work.

   • Fixed cadence.
   • Known, doing, next decision.
   • No speculative fix times.
   • One channel, one voice.

9. The business asks for zero data loss and zero downtime. What do you say?

   The strongest answer: Explain what each step towards zero costs in latency, complexity and money, propose concrete tiers, and have them choose a target per system — few need the top tier, and those must pay for it

   Why it works: Exactly — turn a wish into a priced decision per system.

   • Price each step to zero.
   • Offer tiers per system.
   • Let the business choose.
   • Never commit to absolutes silently.

10. An engineer dropped a production table by running a script against the wrong environment. How do you run the follow-up?

    The strongest answer: A blameless review of how the system let one mistake reach production — environment separation, confirmation for destructive statements, restricted rights — with actions that make the mistake impossible rather than punishing the person

    Why it works: Exactly — fix the system that allowed it; the person is the messenger.

    • Blameless, systemic.
    • Make the mistake impossible.
    • Guard destructive statements.
    • Punishment hides the next one.