# Design a database backup and recovery service: system design interview question

> Database recovery with low production overhead: bounded data loss, complete recovery history, fast restores, and proof that backups work.

Source: https://sysround.com/questions/design-database-backup-and-recovery-service
Updated: 2026-11-05


Difficulty: hard. Levels: Senior, Staff+.

## How the interviewer opens it

"Design a service that creates automatic database backups and restores a database to a selected time. The service must limit production overhead and meet recovery-time and data-loss targets."

## What to clarify first

- Database fleet
- Workload and read:write mix
- Recovery history
- Data-loss target
- Recovery-time target
- Production overhead and latency
- Consistency and availability
- Durability and access
- Recovery result
- Exclusions

## Scope of a strong answer

Core requirements:

- Create automatic backups with low production overhead
- Restore a separate database cluster to a selected time
- Report available recovery intervals and target breaches
- Test that restores meet the recovery targets

Usually out of scope:

- Automatic failover and production traffic changes
- Cross-version migration and other database engines
- Individual table restores
- A deadline for recovery of the entire fleet

## What interviewers probe

### Production impact

A large copy competes with queries for resources. A remote outage can consume the disk space that production needs.

### Available recovery history

A valid target needs a usable base and complete recovery history. Recent files alone do not prove continuous coverage.

### Recovery time and correctness

Recovery work grows between usable bases. A valid backup can miss the deadline even when the base transfer is fast.

### Backup completion and survival

Files, metadata, keys, and retention rules must agree. A disaster can remove a dependency even when the backup files survive.

## Common mistakes

- Uses periodic snapshots without the history required for recovery between them.
- Promises recent recovery times or outage gaps that remote data cannot cover.
- Uses average change volume to justify the recovery deadline under sustained peak load.
- Ignores backup duration, replica lag, or checkpoint history when calculating recovery work.
- Deletes dependencies that support the oldest advertised target.
- Ignores catalog, key, credential, and capacity dependencies during a regional failure.

## The bar by level

- **Senior:** Defines durable completion, valid recovery intervals, timeline checks, and safe retention. Proves the recovery budget under peak load. Handles target breaches explicitly.
- **Staff+:** Includes regional dependencies and reserved capacity in the recovery proof. Quantifies fleet cost. Controls the conflict between production protection, backup deadlines, and recovery coverage.

Practice this question with an AI interviewer: https://sysround.com/practice/new?problem=database-backup-recovery


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews. It has a voice or typed AI interviewer and a shared whiteboard. At the end, you get feedback on each skill and a model answer. The AI feedback can be wrong.