Backup and Restore Strategy

A backup and restore strategy defines how data is copied, retained, protected, and recovered after failures or disasters. A strong strategy combines recovery objectives, backup types, retention, security, validation, and tested restoration procedures.

A backup is a separate copy of data that can be used when the primary copy is lost, corrupted, deleted, or otherwise unavailable. A restore procedure describes how that copy is turned back into usable application data. Backups are therefore part of disaster recovery, but having backups alone does not guarantee successful recovery.

Two important recovery objectives are RPO and RTO. Recovery Point Objective (RPO) describes how much recent data loss the system can tolerate, such as five minutes of writes. Recovery Time Objective (RTO) describes how long recovery may take before service needs to be operational again. These objectives drive backup frequency, replication choices, storage design, and operational procedures.

Common backup approaches include full, incremental, and differential backups. A full backup captures the selected dataset at a point in time. An incremental backup captures changes since a previous backup, while a differential backup captures changes since the last full backup. More frequent backups can reduce RPO, but they also affect storage, bandwidth, processing, and operational complexity.

Backups should be protected from the same failures that could destroy production data. Important controls include encryption, access restrictions, retention policies, immutable or offline copies, and geographic or failure-domain separation. A useful resilience pattern is the 3-2-1 approach: maintain multiple copies, use different storage media or systems, and keep at least one copy separated from the primary environment.

A backup is only trustworthy when restoration has been demonstrated. Restore tests should verify that backup data is complete, consistent, readable, and usable by the application. For a Java backend, recovery planning should also consider database consistency, schema migrations, configuration and secrets, object storage, message-processing state, and dependencies that must be recreated or reconfigured.

Key points

• Define RPO and RTO before choosing backup mechanisms.
• Choose backup frequency and retention to satisfy recovery requirements.
• Protect backups against deletion, corruption, unauthorized access, and shared infrastructure failures.
• Use multiple copies and, where appropriate, immutable or geographically separated storage.
• Regularly test restores rather than assuming successful backup jobs imply recoverability.

Interview questions

What are RPO and RTO, and how do they affect a backup strategy?

RPO is the maximum amount of recent data that the business can afford to lose after a failure. RTO is the maximum acceptable time to bring the service back. A tighter RPO generally requires more frequent backups or another mechanism that captures changes more continuously. A tighter RTO requires a restoration process and infrastructure capable of recovering quickly.

Why is a backup not enough to guarantee disaster recovery?

A backup can exist while still being unusable, incomplete, corrupted, inaccessible, or incompatible with the application. Recovery also depends on knowing how to restore databases, configurations, schemas, secrets, and other dependencies. Restore drills provide evidence that the stored data and operational procedure actually work. The test should measure recovery time and verify the resulting system, not merely the existence of backup files.

What is the difference between full, incremental, and differential backups?

A full backup contains the selected data at the time it runs. An incremental backup contains changes since a prior backup, so restoring may require the relevant full backup plus a sequence of incrementals. A differential backup contains changes since the last full backup, which can make restoration simpler than a long incremental chain. The appropriate choice depends on recovery requirements, storage, bandwidth, backup windows, and operational complexity.

How would you protect backups from ransomware or accidental deletion?

I would separate backup access from normal production credentials and apply least-privilege permissions. I would also consider immutable or write-once retention, separate failure domains, encryption, monitoring, and retention controls that prevent a compromised production account from deleting every recovery copy. Recovery credentials and procedures should be protected independently where practical. Finally, I would regularly test restoration from protected copies rather than relying only on backup-job success metrics.

How would you design backup and restore for a Java service backed by a relational database?

I would first establish RPO and RTO, then select database-native backups, transaction-log or equivalent recovery mechanisms, and storage that satisfies those objectives. The application data must be restored consistently with its schema and any required object storage or external state. I would automate backup verification and restore drills in an isolated environment, including application startup and representative read/write checks. The design would also document dependency order, credentials, configuration, rollback procedures, and operational ownership.