Backup, Recovery and Cyber Resilience

Introduction

A database is valuable only when its information remains available, accurate and trustworthy. Hardware failure, software defects, human error, malicious deletion, ransomware, fire, flood and prolonged loss of connectivity can all interrupt database services. Security therefore includes more than confidentiality and access control: it must also protect availability and integrity over time.

Backup and recovery are the technical foundations of this protection. Cyber resilience extends the idea by asking whether an organisation can anticipate disruption, withstand an attack, continue essential operations, recover safely and improve afterwards. A resilient database service is not simply one that has backup files. It is one for which recovery objectives are defined, copies are protected from compromise, restoration is tested and business processes can continue during an incident.

This chapter presents practical methods for designing protected and encrypted database backups, defining recovery objectives, responding to ransomware, using immutable storage and connecting technical recovery to disaster recovery and business continuity.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain full, incremental, differential, snapshot and transaction-log backups.
2. Define recovery point objective (RPO) and recovery time objective (RTO).
3. Design a protected, encrypted and geographically distributed backup strategy.
4. Explain how ransomware affects databases and backup systems.
5. Distinguish immutable, offline and air-gapped backup protections.
6. Plan and test database restoration and disaster recovery procedures.
7. Relate database recovery to business continuity, governance and legal obligations.

1. The Recovery Problem

Database recovery has two related goals:

• Atomicity and consistency: after a failure, committed transactions should remain and incomplete transactions should be removed or rolled back.
• Service restoration: the database and dependent applications should become usable within an acceptable period.

A database management system (DBMS) commonly uses a transaction log or write-ahead log. Before a changed data page is written to storage, the corresponding log record is written first. During recovery, the DBMS can redo committed changes and undo incomplete changes. This protects against certain crashes, but it does not replace backups. A corrupted database, accidental deletion, compromised administrator account or encrypted production server may cause damage that a local log cannot safely correct.

A backup is a separate, recoverable copy of data or database state. A recovery plan describes how backups, logs, infrastructure, credentials, applications and people will be coordinated to restore an operating service.

Important terminology

• Backup: A copy retained for restoration.
• Restore: Copying backup data into a usable database environment.
• Recovery: Returning data and services to an acceptable operational state.
• Point-in-time recovery (PITR): Restoring a base backup and replaying transaction logs up to a selected time.
• Failover: Moving service to a standby system.
• Failback: Returning service to the original or primary environment.
• Disaster recovery (DR): Capabilities and procedures for restoring technology services after a major disruption.
• Business continuity (BC): The broader ability to continue critical business activities during and after disruption.
• Cyber resilience: The ability to prepare for, resist, respond to and recover from cyber events while learning from them.

2. Backup Types and Their Trade-offs

Full backups

A full backup copies the selected database or dataset. It is straightforward to restore, but consumes more storage and takes longer to create. Many organisations perform periodic full backups and use logs or smaller backup types between them.

Incremental backups

An incremental backup copies changes made since the most recent backup of any type. It usually minimises backup time and storage consumption. Restoration may require the last full backup plus every subsequent incremental backup, increasing procedural complexity.

Differential backups

A differential backup copies changes made since the last full backup. It grows until the next full backup, but restoration normally requires only the last full backup and the latest differential backup.

Transaction-log backups

A transaction-log backup copies log records generated since the previous log backup. Frequent log backups support fine-grained PITR and reduce potential data loss. They require a functioning log chain: a missing or corrupted log segment can prevent recovery beyond that point.

Snapshots and replication

A storage or DBMS snapshot records a point-in-time state efficiently, often using copy-on-write techniques. Snapshots are useful for rapid operational recovery, but they may depend on the same storage system and administrative identity as production. Replication maintains a current copy at another system or site, supporting availability and failover. Synchronous replication can reduce data loss but may transmit corruption or accidental deletion immediately; asynchronous replication provides distance and performance advantages but may lose recent transactions.

Neither replication nor snapshots should be treated as the only backup. A resilient design combines independent recovery mechanisms.

3. Recovery Objectives

Recovery design begins with business requirements rather than a storage product.

Recovery Point Objective

The RPO is the maximum acceptable amount of data loss measured in time. If a service has an RPO of 15 minutes, the organisation aims to recover to a state no more than 15 minutes before the disruption, subject to technical and operational conditions.

A simplified planning relationship is:

This is not a guarantee. Network failure, backup corruption, delayed detection and unavailable keys can increase actual loss.

Recovery Time Objective

The RTO is the maximum acceptable time from service interruption until the service is restored to the required level. RTO includes detection, decision-making, isolation, infrastructure provisioning, restoration, validation and application reconnection—not merely the time to copy a backup.

Other useful objectives

• Maximum tolerable downtime (MTD): The longest period a business process can be unavailable before unacceptable harm occurs.
• Recovery service level: The level of functionality required during recovery, such as read-only access or reduced transaction capacity.
• Retention period: The length of time backups and logs must be preserved.
• Legal hold: A requirement to preserve information despite normal deletion schedules.

RPO and RTO should be assigned by service or business process. A public information database may tolerate hours of data loss, whereas a payment ledger may require seconds or minutes. RTO and RPO must be technically feasible and financially justified.

A simple capacity example

Suppose a database generates 12 GB of transaction logs per hour and log backups run every 15 minutes. Ignoring compression and overhead, the average log-backup volume per day is:

The four daily intervals per hour do not change the total volume; they change the number of backup objects and the maximum interval of potential loss. If the last successful log backup is 15 minutes old, the planned RPO is approximately 15 minutes, but monitoring must verify that jobs actually complete.

4. Designing a Protected Backup Architecture

A sound architecture applies defence in depth.

The 3-2-1 principle

A common baseline is:

• 3 copies of important data, including the production copy;
• on 2 different media or storage technologies;
• with 1 copy off-site.

For high-risk environments, organisations often extend this to 3-2-1-1-0: one off-site copy, one offline or immutable copy, and zero unverified backup errors. The exact pattern should reflect threat, regulatory and business requirements.

Separation of trust

Backup systems should not rely entirely on production identities. Recommended controls include:

• separate backup administration accounts;
• multifactor authentication and least privilege;
• dedicated management networks;
• restricted write and delete permissions;
• separate credentials for backup storage and restoration;
• monitored privileged operations;
• independent security logging;
• emergency access procedures stored securely offline.

If a ransomware operator gains domain-administrator privileges, ordinary network-mounted backups may be deleted or encrypted. A backup copy that shares the same credentials, management plane and network trust boundary as production is not genuinely independent.

Encryption and key management

Backups should be encrypted in transit and at rest. Encryption protects confidentiality if media, cloud objects or portable devices are exposed, but it introduces a recovery dependency: the organisation must be able to obtain the correct key during an emergency.

A practical key-management design should define:

1. key generation using approved cryptographic mechanisms;
2. restricted key access and separation of duties;
3. rotation and retirement procedures;
4. secure backup of key-encryption keys;
5. recovery access when normal identity services are unavailable;
6. audit records for key use.

Encryption keys should not be stored only inside the database being recovered. Conversely, storing plaintext keys beside encrypted backups defeats the purpose of encryption. Key escrow or a secured recovery vault may be used, subject to organisational policy and legal requirements.

Immutability and offline protection

An immutable backup cannot be modified or deleted during a defined retention period. Object-lock retention, write-once media and protected snapshots are examples. Immutability is effective against ransomware and malicious administrators, but it must be correctly configured. An attacker who can shorten retention, change the storage policy or compromise the management account may still defeat a poorly designed implementation.

An offline backup is not connected to production systems during ordinary operations. An air-gapped copy has a stronger separation, although practical air gaps may be logical, physical or procedural rather than absolute. Offline copies require controlled procedures for transport, inventory, restoration and media ageing.

Geographic diversity

A second site or cloud region reduces exposure to local disasters. However, geographic separation alone does not protect against replicated ransomware, shared credentials, common software vulnerabilities or regional legal restrictions. Location, provider independence and administrative separation should be considered together.

5. Ransomware-Resistant Recovery

Ransomware may encrypt production databases, remove snapshots, delete backup catalogues and steal data before encryption. Recovery therefore has both availability and confidentiality dimensions.

A ransomware-ready plan should include:

1. Detection: monitor unusual encryption activity, mass deletion, privilege changes, failed backup jobs and abnormal data transfer.
2. Containment: isolate affected hosts, disable compromised accounts and prevent further access to backup systems.
3. Evidence preservation: retain relevant logs and follow incident-response procedures.
4. Recovery decision: identify a clean restore point before attacker activity or persistence.
5. Credential reset: rebuild trust rather than reconnecting compromised credentials.
6. Clean restoration: use known-good infrastructure, patched software and malware scanning.
7. Validation: confirm data integrity, application function and absence of unauthorised persistence.
8. Communication and reporting: coordinate technical, legal, management, regulatory and customer responses.

A backup can restore availability but cannot automatically remove an attacker from the environment. Recovery must include identity, endpoint, network, application and monitoring controls.

6. Restoration and Recovery Testing

A backup job marked “successful” proves only that a process completed according to software criteria. It does not prove that a usable database can be restored.

Restoration workflow

A disciplined restoration normally includes:

1. authorise the recovery and define the target point in time;
2. isolate a clean recovery environment;
3. obtain and verify backup files, manifests and cryptographic hashes where available;
4. retrieve required encryption keys;
5. restore the full or base backup;
6. apply differential, incremental and transaction-log backups in order;
7. perform DBMS consistency checks;
8. validate schemas, permissions, row counts and critical business records;
9. reconnect applications in a controlled sequence;
10. monitor performance, security events and data correctness;
11. document results and obtain business owner acceptance.

Testing levels

• File verification: confirms that backup objects can be read.
• Automated restore test: restores a sample database regularly.
• Application test: verifies queries, transactions, interfaces and reports.
• Tabletop exercise: rehearses decisions and responsibilities without technical restoration.
• Failover exercise: moves service to a standby environment.
• Full disaster exercise: tests people, facilities, communications, technology and return to normal operations.

Testing should be risk-based and scheduled. A restore test should measure actual RTO and actual recoverable point, not merely state that the test passed.

Useful measures include:

• backup completion and failure rate;
• age of the latest successful recovery point;
• restore duration;
• percentage of critical databases tested;
• number of unresolved restoration defects;
• time to detect and contain a destructive event.

7. Disaster Recovery and Business Continuity Integration

Database recovery is one component of a larger service. A restored database is not useful if DNS, application servers, identity services, network routes, certificates, message queues or staff procedures are unavailable.

A business impact analysis identifies critical processes, dependencies, consequences of interruption and acceptable recovery levels. The results guide the selection of recovery tiers. For example:

A DR plan should identify roles such as incident commander, database recovery lead, infrastructure lead, security lead, communications lead and business owner. It should include contact methods that remain available if corporate email or identity services fail.

Business continuity may involve manual processing, alternate suppliers, reduced service levels and customer communication. It is therefore broader than technical redundancy. Continuity plans should state when a manual workaround begins, how transactions are reconciled later and who authorises a return to normal operation.

8. Governance, Ethics and Regulation

Backup data often contains personal, financial, health or confidential information. Copies inherit the sensitivity of the production data. Governance should address:

• retention and secure deletion;
• data minimisation and purpose limitation;
• access review and auditability;
• cross-border transfer and cloud jurisdiction;
• legal holds and investigation requirements;
• breach notification duties;
• segregation of duties;
• supplier assurance and contractual recovery commitments.

Long retention can support investigations but increases exposure, storage cost and privacy risk. Deleting backups too quickly may violate legal or operational obligations. Retention schedules should be approved by information owners, legal advisers and security personnel.

Ethically, recovery decisions should consider affected customers and vulnerable users, not only organisational cost. Restoring an old backup without disclosing potential data loss can mislead stakeholders. Security professionals should report limitations honestly and preserve evidence when an incident may involve wrongdoing.

9. Contemporary Developments

Cloud backup services offer elasticity, geographic distribution and managed durability, but responsibility is shared. The provider may protect infrastructure while the customer remains responsible for configuration, keys, retention, access and restoration testing.

Zero-trust principles increasingly influence backup architecture: every administrative request is authenticated, authorised and monitored, regardless of network location. Behaviour analytics can identify unusual backup deletion or data-volume changes. Artificial intelligence may assist anomaly detection, capacity forecasting and incident triage, but it should not independently approve destructive recovery actions. False positives, poisoned data, model error and excessive trust in automation remain risks.

Confidential computing, stronger hardware-backed key protection and policy-controlled immutable storage may improve future recovery architectures. These technologies do not eliminate the need for clear objectives, independent copies and human governance.

Applied Case: Illustrative Regional Health Provider

Background

A fictional regional health provider operates a patient-record database, a billing database and an appointment system. The patient-record service has an RPO of 15 minutes and an RTO of four hours. The provider currently uses nightly full backups stored on a network share.

Problem

An administrator’s credentials are stolen. Attackers encrypt the production servers and delete the network-share backups. The provider has a tape archive, but its last restoration test was three years ago. The clinical team cannot access current records and must use emergency paper procedures.

Analysis

The nightly schedule could cause up to almost 24 hours of data loss even without attack. The network share is in the same identity and administrative domain as production, so it is not independent. The untested tape archive may be technically available but has uncertain usability and recovery time. The incident also creates confidentiality, patient-safety and reporting concerns.

Approach and solution

The provider establishes a recovery programme with:

• log backups every 15 minutes for the patient-record database;
• weekly full backups and daily differential backups;
• encrypted copies in a separate cloud account with immutable retention;
• monthly offline media exported under dual control;
• separate backup identities with multifactor authentication;
• protected key recovery procedures;
• a clean-room recovery environment;
• quarterly application restoration tests and an annual full exercise;
• documented paper-to-digital reconciliation procedures;
• monitoring for deletion, retention-policy changes and unusual backup volume.

During the incident, the provider isolates compromised systems, preserves evidence, resets credentials and restores to a verified point before malicious activity. The security and clinical teams validate patient records before reconnecting applications.

Outcome and learning points

The provider reduces dependence on a single backup location and makes recovery measurable. The case demonstrates that RPO and RTO are business commitments, not merely database settings. It also shows that encryption, immutability and offline storage must be combined with identity protection, tested restoration and clinical continuity procedures.

Challenges and Limitations

No backup strategy removes all risk. Very frequent backups increase network, storage and operational cost. Synchronous replication can spread corruption instantly. Immutable retention can delay legitimate deletion and increase privacy exposure. Offline media can be lost or damaged. Cloud services can suffer provider outages or configuration errors. Recovery exercises can disrupt production if poorly controlled. Finally, recovery may reveal that the organisation lacks trustworthy data validation: a technically complete restore may still contain incorrect or fraudulent records.

The appropriate design is therefore risk-based. Critical databases deserve stronger isolation, more frequent recovery points, shorter restoration targets and more rigorous testing than low-value systems. Plans should be reviewed after major application, infrastructure, threat or regulatory changes.

Best-Practice Checklist

• Define RPO, RTO and recovery service levels with business owners.
• Maintain multiple copies using independent failure domains.
• Include immutable or offline protection against destructive attacks.
• Encrypt data in transit and at rest, and protect recovery keys separately.
• Separate backup administration from production administration.
• Monitor backup age, failures, deletion and policy changes.
• Test restoration—not just backup completion—on a regular schedule.
• Validate data, applications, identities and dependencies after restoration.
• Include ransomware containment, evidence preservation and communications.
• Document manual continuity procedures and reconciliation.
• Review retention, privacy, legal hold and supplier responsibilities.
• Record lessons from every exercise and incident.

Chapter Summary

Backup, recovery and cyber resilience protect database availability and integrity across time. Full, incremental, differential, log, snapshot and replication methods have different restoration and risk characteristics. RPO expresses acceptable data loss in time, while RTO expresses acceptable restoration time; both must be defined with business owners.

A resilient architecture uses independent copies, encryption, secure key management, geographic separation and immutable or offline protection. Ransomware recovery requires containment, clean restoration, credential recovery, validation and communication—not merely copying files back. Disaster recovery must include applications, networks, identity services, people and facilities, while business continuity also addresses manual workarounds and essential service levels.

Finally, backups are trustworthy only when restoration is regularly tested. Governance must balance availability, confidentiality, retention, privacy, legal obligations and cost. Cyber resilience is a continuing organisational capability rather than a single product or one-time project.

Key Terms

Backup: A separate copy retained for restoration.

Recovery: Returning data and services to an acceptable operating state.

Restore: Reconstructing a database from protected copies.

Recovery Point Objective (RPO): Maximum acceptable data loss measured in time.

Recovery Time Objective (RTO): Maximum acceptable time to restore a service.

Point-in-time recovery: Restoration to a selected moment using a base backup and logs.

Transaction log: Ordered record of database changes used for recovery.

Full backup: Copy of the selected database or dataset.

Incremental backup: Copy of changes since the latest backup of any type.

Differential backup: Copy of changes since the latest full backup.

Snapshot: Point-in-time storage or database representation.

Replication: Maintaining a current copy on another system.

Immutability: Protection that prevents alteration or deletion for a defined period.

Offline backup: Backup disconnected during ordinary operations.

Air gap: Strong physical, logical or procedural separation from production.

Disaster recovery: Restoration capability for major technology disruption.

Business continuity: Ability to continue critical business processes during disruption.

Cyber resilience: Ability to prepare for, withstand, respond to and recover from cyber events.

Retention: Period for which a backup must be preserved.

Review Questions

Short Answer Questions

1. What is the difference between RPO and RTO?
2. Why is replication not a complete substitute for backup?
3. State the traditional 3-2-1 backup principle.
4. What is an immutable backup?
5. Why must encryption keys be included in recovery planning?

Long Answer Questions

1. Compare full, incremental, differential and transaction-log backups, including their restoration implications.
2. Explain how a database organisation can design a ransomware-resistant backup architecture.
3. Describe a complete database restoration workflow from authorisation to business validation.
4. Explain how disaster recovery differs from business continuity and why both are required.
5. Discuss the governance and privacy issues created by long-term retention of encrypted backups.

Analytical / Application Questions

1. A critical database has an RPO of 15 minutes and an RTO of two hours. Design a backup and recovery approach that could meet these objectives, and identify assumptions that must be tested.
2. An attacker deletes production snapshots but cannot access an offline tape library. Analyse the remaining recovery options and propose improvements to reduce restoration risk.
3. During a restore, all database files are present but the identity provider and application servers are unavailable. Explain why the service is not yet recovered and develop a prioritised continuity response.

Multiple Choice Questions with Answers

Question 1

Which objective describes the maximum acceptable amount of data loss measured in time?

A. RTO

B. RPO

C. MTD

D. Retention period

Correct Answer: B. RPO

Question 2

Which backup type normally requires the last full backup and every subsequent backup in the chain for restoration?

A. Incremental backup

B. Differential backup

C. Snapshot only

D. Replication copy

Correct Answer: A. Incremental backup

Question 3

What is the main purpose of immutable backup storage?

A. To increase database transaction speed

B. To prevent alteration or deletion during a defined retention period

C. To eliminate the need for encryption

D. To guarantee zero recovery time

Correct Answer: B. To prevent alteration or deletion during a defined retention period

Question 4

A database generates 12 GB of logs per hour. Ignoring overhead, how much log data is generated in 24 hours?

A. 48 GB

B. 144 GB

C. 288 GB

D. 576 GB

Correct Answer: C. 288 GB

Question 5

Why can replication fail to protect against ransomware?

A. Replication cannot copy database changes

B. Replication may transmit corruption or malicious deletion to the replica

C. Replication always requires offline media

D. Replication prevents failover

Correct Answer: B. Replication may transmit corruption or malicious deletion to the replica

Question 6

Which practice best separates backup administration from production compromise?

A. Using the same administrator account for both systems

B. Mounting backups read-write on every production server

C. Using separate privileged identities and management controls

D. Storing encryption keys in the production database

Correct Answer: C. Using separate privileged identities and management controls

Question 7

What does point-in-time recovery usually combine?

A. A base backup and transaction logs

B. Only a current replica

C. A firewall and an antivirus scan

D. A paper procedure and a snapshot schedule

Correct Answer: A. A base backup and transaction logs

Question 8

Which activity provides the strongest evidence that a backup is usable?

A. Checking that a backup job displays ‘successful’

B. Confirming that the backup file has a large size

C. Performing a controlled restoration and application validation

D. Copying the backup to another folder

Correct Answer: C. Performing a controlled restoration and application validation

Question 9

What is a key limitation of storing backups in the same administrative domain as production?

A. They cannot be encrypted

B. A compromised privileged account may delete or encrypt both

C. They cannot support retention policies

D. They always have a longer RTO

Correct Answer: B. A compromised privileged account may delete or encrypt both

Question 10

Which statement best describes business continuity?

A. It concerns only database transaction logging

B. It is limited to buying replacement hardware

C. It includes continuing critical business processes, including manual workarounds

D. It means preserving every system at full capacity during a disaster

Correct Answer: C. It includes continuing critical business processes, including manual workarounds