How to Evaluate Whether Your Backups Are Really Protecting You and Your Data

A Practical Guide to Backup Design, Testing and Recovery Readiness

For personal users, small and home businesses, and enterprise organisations

Backups are often treated as a routine copy operation. In reality, a backup is part of a recovery system. It has value only when the correct data can be restored, within an acceptable time, to a trustworthy operating state.

An untested backup is not protection. It is hope that recovery will work.

This whitepaper explains how to determine whether your existing backups really protect you. It covers the threats that make recovery necessary, the data and dependencies that must be protected, full and incremental backup methods, database log forwarding, schedules and retention, recovery testing, disaster recovery sites, and practical design and test checklists.

Related reading: What RTO and RPO Mean to Your Business.

Executive Summary

A backup job that reports success proves only that a process ran. It does not prove that every required file was included, that the backup chain is complete, that encryption keys and credentials will be available during an incident, or that the recovered service will work. Protection is demonstrated through recovery, validation and evidence.

The same principles apply at every scale. A personal user may need to recover irreplaceable photographs, identity documents and a failed laptop. A home business may need its accounts, customer records, website and email back before cash flow is affected. An enterprise may need to recover interdependent applications, databases, identity services and thousands of users’ information while meeting contractual or regulatory obligations.

A sound backup program follows a recovery-first sequence:

• identify the data and business services that would be difficult, costly or impossible to recreate
• define how much data loss is acceptable through a Recovery Point Objective (RPO)
• define how quickly each service must return through a Recovery Time Objective (RTO)
• design backup types, schedules, storage locations and retention periods to meet those objectives
• protect at least one recovery copy from the same failure, account compromise or ransomware event as production
• document how to recover at file, application, database, operating-system and whole-environment levels
• test realistic recoveries and record whether the actual RPO, RTO and business outcome were achieved

Back up to meet the RPO. Test recovery to prove the RTO.

How to Use This Guide

Use the earlier sections to review your current design and the later checklists to convert the review into action. Do not attempt to protect every device and application in exactly the same way. Prioritise the information and services that create the greatest personal, operational, financial, safety or legal impact if they are lost or unavailable.

• Personal users: focus on irreplaceable information, device recovery and simple procedures that another trusted person could follow.
• Small and home businesses: connect backup decisions to invoicing, payments, customer service, records, websites, email and the ability to continue trading.
• Enterprise organisations: map complete business services, technical dependencies, security boundaries, recovery order, staffing, vendors and formal acceptance criteria.

1. The Importance of Backups

Why You Should Back Up

Information has value because it represents memories, work, money, obligations and decisions. A lost family archive cannot be recreated. A lost customer database can stop a business from trading. A lost configuration or encryption key can make otherwise healthy systems unusable. Backups provide an independent point from which data, systems or services can be reconstructed after normal controls have failed.

The objective is not simply to save copies. It is to preserve the organisation or individual’s ability to return to a known, acceptable state. That may mean recovering one document, rebuilding a laptop, restoring a database to the moment before an erroneous transaction, or re-establishing an entire environment after a site has been lost.

Reliable backups reduce the consequences of disruption by providing options. They can reduce the amount of data that must be recreated, shorten the outage, support investigation after a cyber incident and allow a controlled recovery rather than an improvised one. They also support long-term record keeping where older versions must remain available.

The Consequences of Inadequate Backups

The immediate symptom may be missing files or an unavailable server, but the wider impact can include:

• loss of personal records, photographs, messages, contacts and creative work
• inability to invoice, receive payments, process orders, dispatch goods or answer customer questions
• extended staff downtime, backlog, overtime and manual re-entry of transactions
• breach of contractual, privacy, tax, audit, records-management or industry obligations
• loss of customer confidence, reputational harm and difficulty proving what occurred
• unsafe or inconsistent operations where technology supports physical or regulated processes
• business failure where essential records, receivables, inventory or intellectual property cannot be reconstructed

Backups Are Not the Same as High Availability

High availability keeps a service running when a component fails. Backups allow recovery after data has been deleted, corrupted or made untrustworthy. Redundant disks, clustering, replication and multiple cloud regions can reduce outages, but they may reproduce accidental deletion, application corruption or malicious changes. High availability and backups address different risks and are normally required together for important services.

A Copy Is Not Always a Backup

Several technologies create additional copies or versions, but their protection depends on how independently they are operated and secured:

• Synchronisation: a deletion or ransomware-encrypted file may be synchronised to every connected device.
• Replication: improves availability, but can replicate logical corruption or unauthorised changes to the secondary system.
• Snapshots: provide fast point-in-time rollback, but may share the same storage platform, credentials or failure domain as production.
• Version history: can help with accidental changes, but retention may be short and the account itself may be compromised.
• Archives: support long-term records, but may not contain complete system dependencies or support rapid operational recovery.

A recovery copy should be separated from the events that could damage production, retained for long enough to outlast delayed detection, and proven usable through restore testing.

2. Disasters That Require Recovery from Backups

A disaster does not have to be a flood or a destroyed building. Any event that makes required data or systems unavailable, incomplete or untrustworthy can create a recovery need. The backup design must cover both common small failures and rare large failures.

Hardware Failure

Storage devices, power supplies, controllers, memory, motherboards, phones, laptops, servers and network appliances all fail. Redundancy can keep some systems running, but it does not eliminate every failure mode. Multiple disks can fail, a storage controller can corrupt data, a laptop can be lost, or a cloud-hosted virtual machine can become inaccessible.

The recovery requirement may range from restoring a few files to rebuilding an operating system on replacement hardware. Test whether backups can be restored to hardware with different disk sizes, drivers, firmware or virtualisation platforms, because an exact replacement may not be available during an emergency.

User Error and Operational Mistakes

Accidental deletion, overwriting, incorrect permissions, faulty scripts, mistaken database updates and misconfigured systems are among the most common reasons for restoration. These events are often discovered after the action has propagated through synchronisation, replication or normal application processing.

Version history and granular restore features are valuable here. The design must retain enough restore points to reach a time before the error and should allow recovery to an alternate location for comparison before replacing current data.

Environmental and Site Disasters

Fire, flood, storm, heat, water leaks, prolonged power failure, building access restrictions and regional events can make an entire location unavailable. A backup stored beside the original equipment may be lost in the same event. Off-site recovery copies and a documented alternate recovery location are therefore essential for important information and services.

For personal users, off-site may mean an encrypted cloud copy or media stored securely with a trusted person. For a small business, it may mean cloud object storage or rotated media held away from the premises. For an enterprise, it may involve another data centre, cloud region, cyber recovery vault or specialist records facility.

System Compromise, Hacking and Ransomware

Cyber incidents can affect production data, accounts, backup servers and connected backup repositories at the same time. Attackers may deliberately delete snapshots, alter retention, steal backup administrator credentials or encrypt accessible backups before disrupting production. A recovery copy that is online, writable and controlled through the same identity system may not survive the incident.

At least one copy should be offline, immutable or otherwise strongly isolated. Backup administration should use separate credentials, multi-factor authentication and least privilege. During a cyber recovery, systems should normally be restored into an isolated environment, scanned and validated before they reconnect to production. Restoring infected or still-compromised systems can restart the incident.

Software, Upgrade and Service Provider Failures

Failed patches, application defects, corrupted file systems, misbehaving integrations and unsuccessful migrations can require rollback. Cloud and Software-as-a-Service platforms can also suffer account compromise, configuration loss, accidental deletion, retention limitations or provider outages. The provider may protect the platform while the customer remains responsible for data, configuration and recovery decisions.

Back up configuration, scripts, licences, certificates, keys and the information needed to rebuild the service.

3. Understand the Data You Must Protect

Effective backup begins with a data and dependency inventory. Many failed recoveries occur because the backup contained the obvious files but omitted configuration, transaction logs, service accounts, certificates, hidden application paths or external dependencies. The aim is to understand what makes the service usable, not merely what consumes the most storage.

Operating System and System-State Data

Operating system protection may include boot records, system files, drivers, package lists, patches, the Windows registry or equivalent system state, local users and groups, scheduled tasks, services, configuration under locations such as /etc, security policies and device-specific settings. Image-based or bare-metal backup can accelerate recovery, but a clean operating-system rebuild followed by application and data restoration may be safer after a compromise.

Record the operating system edition, version, patch level, architecture, boot mode, disk layout and required drivers. Keep clean installation media or trusted images and confirm that product licences and activation methods remain available when the original hardware is gone.

Application and Binary Data

Application recovery requires more than copying executable files. Protect or document installers, package repositories, exact versions, plug-ins, configuration files, service definitions, scheduled jobs, integration endpoints, environment variables, licences, certificates, secrets and custom scripts. Some applications must be installed before data is restored; others can be recovered as a complete image.

Where possible, maintain infrastructure-as-code, configuration management and reproducible build documentation. These controls reduce dependence on a single image and allow the application environment to be rebuilt on replacement hardware or another cloud platform.

Static Data

Static data changes infrequently. Examples include completed projects, photographs, signed documents, archived email, policies, reference material, design files and historical records. Static data may not require frequent full backup once captured, but it may require long retention, integrity checking and protection from silent corruption.

Because static data is often retained for years, periodically confirm that the storage media remains readable, that encryption keys are still available and that the backup format can be opened by current software. Plan migration before media or proprietary formats become obsolete.

Dynamic Data

Dynamic data changes continually and often drives the RPO. Examples include active documents, mailboxes, customer records, orders, databases, virtual machine disks, collaboration platforms, transaction queues and application logs. A nightly backup may be adequate for one workload and unacceptable for another that processes transactions every minute.

Dynamic data also requires consistency. Copying open database files or a running application without application-aware controls can create an unusable restore point. Use supported database backup interfaces, quiescing, snapshots coordinated with the application, or transaction-log protection as appropriate.

File Paths, Volumes and Hidden Locations

Document where data actually resides. Important content may be distributed across user profiles, shared folders, mounted volumes, external disks, network shares, cloud-synchronised directories, application data folders, database storage, transaction-log volumes, container volumes and hidden configuration directories. New paths introduced by an upgrade may not automatically enter the backup policy.

For each path, record the owner, purpose, sensitivity, expected size, change rate, backup method, retention and restore procedure. Include permissions, ownership, access-control lists, timestamps, extended attributes and alternate data streams where they are required for a correct recovery.

From Understanding Data to Knowing What and How to Back Up

Classify each item by value, rate of change, consistency requirement and recovery method. Then decide whether it needs file-level backup, image backup, database-aware backup, log protection, configuration export, SaaS backup or a combination. Avoid blanket rules such as “back up every server nightly” without considering the service it supports.

• Personal example: daily protection of active documents and photographs, weekly device backup, and an encrypted off-site copy of irreplaceable data.
• Small-business example: frequent accounting and order backups, daily endpoint and file protection, website and email exports, plus an off-site copy protected from the main administrator account.
• Enterprise example: service-based protection combining application-aware backups, database logs, virtual-machine images, configuration repositories, immutable copies and coordinated recovery of dependencies.

4. Full, Incremental and Related Backup Methods

Full Backups

A full backup captures all selected data at a defined point. It is straightforward to understand and usually provides the simplest restore path because fewer backup components are required. The trade-offs are longer backup windows, higher storage consumption and greater data movement.

A full backup does not automatically mean a complete business recovery. It may still omit application consistency, transaction logs, dependencies or the backup catalogue. Confirm exactly what “full” means for the product and workload.

Incremental Backups

An incremental backup captures data changed since the preceding backup, whether that preceding backup was full or incremental. Incrementals are normally faster and smaller, which supports shorter RPOs and reduces network and storage load. Recovery may require the last full backup plus every required incremental in the chain.

The main risk is dependency. A missing or damaged incremental can prevent later restore points from being used. Test long chains, interrupted jobs and catalogue loss. Some products create synthetic full backups by combining prior backups within the repository, reducing the need to reread all source data while presenting a new full restore point.

Differential, Snapshot and Continuous Techniques

A differential backup captures changes since the last full backup. Differential backups are considerable smaller and are much quicker than a full backup. Recovery may require only the last full and the latest differential. Snapshots can create rapid point-in-time copies, and continuous data protection can capture changes at short intervals. These techniques can improve RPO and RTO, but should still be assessed for independence, retention, consistency and cyber resilience.

Database Logging and Log Forwarding to a Standby

Many databases record changes in transaction, redo, write-ahead or logs. A common design creates a full or base database backup and then protects the continuing stream of logs. During recovery, the base backup is restored and logs are replayed forward to a selected time, often immediately before an accidental deletion or corruption event.

Logs can also be transmitted over the network to a standby database server and applied continuously or at intervals. This can reduce data loss and shorten recovery because a near-current secondary database already exists. Implementations differ by database platform, but the underlying concepts are similar: capture changes, transfer them reliably, monitor gaps and lag, apply them in order, and control when the standby is opened for service.

Log forwarding is valuable, but it is not a replacement for independent backups. A damaging transaction, malicious change or logical corruption may also be forwarded. Retain base backups and historical logs long enough to recover to a point before the event. Test network interruption, log gaps, full standby activation, application validation and the procedure for protecting changes after failover.

5. Backup Schedules and Retention Periods

Schedule and Retention Are Different Decisions

The schedule determines how often a restore point is created. Retention determines how long that restore point remains available. A frequent schedule with very short retention may fail when corruption is discovered late. Long retention with an infrequent schedule may preserve history but still allow too much recent data loss. Both decisions must be tied to RPO, risk, detection time, storage capacity and records obligations.

Designing Daily, Weekly, Monthly and Yearly Cycles

A common rotation is sometimes described as daily, weekly, monthly and yearly, or as a Grandfather-Father-Son scheme. The labels are less important than the recovery outcomes. An illustrative design might retain daily incrementals for 30 days, weekly full or synthetic full backups for 12 weeks, monthly copies for 12 months and selected yearly copies for the required archival period. This is an example, not a universal rule.

Use shorter intervals for high-change data and longer retention where errors may remain undetected. Yearly retention should be based on legal, tax, records or historical requirements and should not be confused with operational recovery. Long-term archives may require different media, cataloguing and integrity checks from day-to-day backups.

Match Frequency to RPO and Change Rate

An RPO of four hours requires a recoverable point no more than four hours before the incident under the conditions being planned for. A nightly backup cannot meet that target by itself. The solution may combine periodic full backups, frequent incrementals, snapshots and database log protection. Measure whether jobs finish within the available backup window and whether off-site copies complete before the next risk period.

Retention Must Survive Delayed Detection and Attack

Some corruption, malicious access and configuration errors remain unnoticed for weeks. Retain multiple generations and protect retention settings from casual or compromised administrative deletion. At least one protected copy should have a retention period that cannot be shortened through ordinary production credentials. Monitor unexpected deletion, policy changes and sudden reductions in restore points.

6. How to Test Your Backups

Backup testing should be a planned program, not an occasional attempt after a failure. The program should progress from frequent automated checks to realistic end-to-end exercises. Each layer answers a different question and none is sufficient alone.

The only reliable evidence of a backup is a successful, validated recovery.

Layer 1: Monitor Every Backup Job

Review failed, partial, missed and unusually small jobs. Confirm that every expected device, path and workload is included. A green dashboard can still hide excluded data, stale agents, unprotected new systems or transaction logs that stopped shipping. Alerts must reach someone who is responsible and able to act.

Layer 2: Verify Media and Backup Integrity

Use product verification, checksums, media scans and repository health checks where available. Confirm that backup catalogues can locate the data and that encryption keys are available. Integrity verification detects some corruption, but it does not prove that the application was captured consistently or that the complete service can run.

Layer 3: Perform Routine Sample Restores

Regularly restore representative files, folders, mail items, records and configurations. Restore both to the original location and to an alternate location. Check file contents, permissions, ownership, timestamps and metadata. Select some restore points randomly, including older retained copies, rather than always testing the newest backup.

Layer 4: Test Application and Database Recovery

Restore the application and database to an isolated environment. Apply required transaction logs to a nominated point. Start the service, review logs and complete representative business transactions. For example, create an invoice, retrieve a customer record, run a report, process a test order or reconcile a transaction. The test ends when the service works, not when files finish copying.

Layer 5: Test Operating System and Bare-Metal Recovery

Recover a workstation, virtual machine or physical server from a blank or replacement target. Confirm bootability, drivers, storage layout, network configuration, licences, patch state and access to dependencies. Test alternate hardware or a different hypervisor where that scenario is part of the plan.

Layer 6: Conduct a Disaster Recovery Exercise

Recover multiple systems in the required order at an alternate or isolated site. Assume that the primary backup server, identity system, management network or normal administrator is unavailable. Measure the time to declare the incident, obtain access, prepare infrastructure, restore data, validate security, test business processes and obtain owner acceptance.

Define Success Before Testing

Every test should have written acceptance criteria. At minimum, record:

• the scenario, scope, participants, assumptions and recovery environment
• the selected restore point and the expected amount of data loss
• the RPO and RTO targets and when each measurement starts and stops
• required technical checks, application functions and business transactions
• security checks confirming that the recovered environment is clean and appropriately controlled
• evidence such as logs, screenshots, checksums, timings and business-owner sign-off
• defects, workarounds, risks, owners, completion dates and the required retest

Set a Risk-Based Test Frequency

There is no single interval for every system. Criticality, rate of change, threat exposure, regulation and design changes should drive frequency. A practical baseline is to review every job, perform regular sample restores, test critical applications at least several times a year where feasible, and run a coordinated disaster recovery exercise at least annually. Test more often after major upgrades, migrations, identity changes, backup-platform changes or previous failures.

7. Understand When to Consider and Initiate Recovery

Recovery is a business and risk decision, not merely a technical button. Restoring too early can overwrite good evidence, reintroduce malware or discard valid recent transactions. Waiting too long can consume the RTO and increase business impact. The recovery plan should define who can declare an incident, who can authorise restore, and when security, legal, privacy or executive stakeholders must be involved.

Questions to Ask Before Recovery

• Is the current data unavailable, corrupted, incomplete or no longer trustworthy?
• Can the issue be repaired safely without restoration, and would repair be faster or lower risk?
• What is the earliest known-good point before the error, compromise or corruption?
• What valid data would be lost or require reconciliation if that point is restored?
• Has the cause been contained so it will not immediately damage the recovered system?
• Is forensic preservation required before systems or logs are changed?
• Are the target environment, credentials, keys, licences and dependencies available?
• Who will validate the result and authorise return to service?

Recovery During a Cyber Incident

Coordinate recovery with incident response. Preserve evidence where required, reset compromised credentials, identify the initial access path and confirm the chosen restore point predates the compromise. Rebuild from trusted media when system integrity is uncertain. Restore into a clean network segment, scan data and systems, apply required security fixes and monitor closely before reconnecting users or integrations.

8. Recovery at Every Level

File and Folder Recovery

File recovery should support individual items, folders, previous versions and alternate destinations. Validate contents, access permissions and metadata. When the cause is accidental overwrite or corruption, restore beside the current file first so the owner can compare and choose the correct version.

Application Recovery

Application recovery includes binaries or installation, configuration, data, licences, certificates, integrations and service accounts. Document the recovery order and validation steps. A server that starts but cannot authenticate users, send email, access storage or complete a transaction is not recovered.

Database Recovery

Database recovery may involve full restore, differential or incremental components, transaction-log replay, point-in-time selection and consistency checks. Validate database integrity, user access, application connections, scheduled jobs, replication and business transactions. Reconcile any transactions that occurred after the selected recovery point.

Bare-Metal Recovery

Bare-metal recovery restores an operating system and system state to an empty physical or virtual target. It is valuable after total disk or server loss. Test boot media, network access to the repository, storage drivers, partitioning, firmware mode and recovery to disks that are larger, smaller or arranged differently from the original where supported.

Entire-System Recovery on New Hardware

A complete system recovery should assume that the original hardware, site or cloud account may be unavailable. Prepare replacement infrastructure, install or recover the backup platform, obtain catalogues and keys, restore dependencies in order, redirect network traffic and validate the end-to-end service. Confirm that licences permit recovery to alternate equipment and that vendor support can be reached during an emergency.

Return to Normal Operations

Plan how changes made during recovery will be preserved. Users may have worked manually, processed transactions on a standby, or created data in an alternate environment. Reconcile this activity before failback. Record the final data point, communicate service status, increase monitoring and conduct a post-incident review.

9. The Value of Disaster Recovery Plans and Off-Site Systems

A disaster recovery plan coordinates people, technology, locations, suppliers, communications and decision rights when normal operations cannot continue. It should identify recovery priorities, dependencies, alternate processing methods, recovery locations, contact paths, security requirements and acceptance criteria. A list of servers is not a disaster recovery plan.

An off-site or disaster recovery environment can be cold, warm, hot or active. A cold site provides space and basic facilities but requires systems to be built. A warm site has prepared infrastructure and some current data. A hot or active site has running capacity and current data that can take over quickly. The appropriate design depends on RTO, RPO, cost and operational maturity.

Use the DR Environment to Test Backups Continually

A standby or isolated recovery environment creates an opportunity to test restore processes regularly. Backups can be recovered on a schedule, applications can be started, automated checks can run and business owners can validate selected functions. This provides stronger evidence than waiting for an annual exercise and helps detect changes that have made the runbook obsolete.

Keep the test environment controlled. Avoid exposing recovered production data unnecessarily, prevent test systems from sending real messages or transactions, protect privacy, and ensure that automated testing cannot alter production. For cyber recovery, preserve an isolated path that does not depend on the compromised production identity or management plane.

10. Best-Practice Backup Design Guide

Start with RTO and RPO

Recovery Point Objective is the maximum acceptable amount of recent data loss. Recovery Time Objective is the target time to restore the service to an agreed operating level. They are business requirements that must be translated into backup frequency, replication or log protection, storage performance, recovery automation, staffing and test frequency.

Define objectives by business service, not by server alone. A service may depend on identity, DNS, networks, certificates, storage, databases, third parties and several application tiers. The measured RTO must include detection, decision, access, infrastructure preparation, data restore, dependency recovery, validation and business acceptance.

Apply the 3-2-1 Principle

The 3-2-1 principle is a useful minimum starting point: maintain at least three copies of important data, including the production copy; keep three copies of your backup data; keep the copies across at least two different media types or failure domains; and keep at least one copy off-site. The objective is to avoid a single device, platform, account or location destroying every copy.

Modern cyber risk justifies an additional requirement: keep at least one copy offline, immutable or strongly isolated, and verify that recovery from it produces no uncorrected errors. The design should survive compromise of ordinary production and backup administration credentials.

Design and Document the Backup Configuration

Maintain a controlled design document that records protected assets, data paths, owners, RPOs, RTOs, backup methods, schedules, retention, storage locations, off-site transfer, encryption, key management, security roles, monitoring, capacity, dependencies, licences, exclusions and accepted risks. Update it when services change.

Maintain a Documented Recovery Plan

The recovery runbook should be detailed enough for an authorised alternate operator to follow under pressure. It should explain how to obtain access, identify the correct restore point, recover the backup platform and catalogue, prepare an isolated or alternate environment, restore dependencies in order, validate security and application function, escalate to vendors, communicate status and return to normal operations.

Protect the Backup System Itself

• use separate administrative accounts and multi-factor authentication
• apply least privilege and separation of duties for backup, security and production roles
• encrypt backup data in transit and at rest and protect key recovery procedures
• make retention, immutability and deletion settings resistant to tampering
• back up the backup catalogue, configuration, licence information and recovery media
• monitor missed jobs, unusual deletions, capacity, media health and policy changes
• retain a recovery path that works when normal identity, DNS, network or management systems are unavailable

Scale the Design to the Environment

Personal users should favour simplicity, automation and clear recovery instructions. Small businesses should remove dependence on a single owner or device and protect cloud as well as on-premises data. Enterprises require service tiering, formal ownership, security separation, multiple recovery locations, vendor support and evidence that recovery objectives are met.

11. Backup Design Checklist

Use this checklist when creating or reviewing the backup architecture. Record the owner, evidence and remediation date for every item that is not complete.

Business and Data Requirements

• Critical personal information, business processes and enterprise services have been identified.
• Each in-scope service has a business owner and a technical recovery owner.
• RPO and RTO are defined, approved and practical for each service tier.
• Data classification, privacy, legal-hold and retention obligations are documented.
• Operating-system, application, static, dynamic and configuration data are inventoried.
• File paths, volumes, cloud locations, transaction logs and hidden dependencies are recorded.
• Recovery priorities and the required dependency order are documented.

Backup Architecture

• Backup methods are selected for each workload: file, image, application-aware, database, log or SaaS.
• Full and incremental chains can meet the RPO and complete within available windows.
• Database base backups and transaction-log retention support point-in-time recovery.
• The design maintains at least three copies across two media types or failure domains with one off-site.
• At least one copy is offline, immutable or strongly isolated from ordinary credentials.
• Backup repositories, catalogues, configurations, recovery media and encryption keys are protected.
• Capacity, growth, bandwidth, seeding and off-site transfer time have been calculated.
• Retention includes enough generations to survive delayed detection of corruption or compromise.
• Long-term archives have media migration, integrity-checking and key-retention plans.
• The design includes recovery when the primary site, cloud tenant or backup server is unavailable.

Security, Operations and Documentation

• Backup administration uses separate accounts, least privilege and multi-factor authentication.
• Encryption is enabled and key recovery has been tested.
• Monitoring alerts on missed jobs, failures, capacity, unusual deletion and policy changes.
• Every protected workload has a documented backup configuration and recovery runbook.
• Licences, installation media, drivers, certificates, secrets and vendor contacts are available.
• An authorised alternate person can perform recovery without relying on the usual administrator.
• The design and risk acceptance are reviewed after material changes and at least annually.

12. Backup Test Checklist

Use this checklist for routine testing and formal exercises. Select representative new, old, small and large restore points rather than always testing the easiest case.

Test Preparation

• The scenario, scope, participants, environment and assumptions are documented.
• RPO, RTO, functional, security and business acceptance criteria are defined before testing.
• Production data used in the test is protected and the environment is isolated where required.
• The selected restore points, backup chain and expected dependencies are recorded.
• Start and finish rules for timing are agreed.

Backup and Restore Tests

• Backup-job success, exclusions, warnings and unexpectedly small data volumes are reviewed.
• Repository integrity, media readability, checksums and catalogue search are tested.
• A file and folder are restored to original and alternate locations.
• An older retained restore point is tested.
• Permissions, ownership, timestamps and metadata are validated.
• A full plus incremental chain is restored, including a deliberately interrupted or failed job scenario.
• A database is restored and transaction logs are replayed to a nominated point in time.
• An application is recovered and completes a representative business transaction.
• An operating system or virtual machine is restored and boots successfully.
• Bare-metal or alternate-hardware recovery is tested where required.
• Recovery is tested without the original backup server or catalogue where the design claims to support it.
• A ransomware or destructive-event scenario is recovered from the isolated or immutable copy.
• A multi-system disaster recovery exercise validates dependencies and recovery order.

Evidence and Follow-Up

• Actual data loss and elapsed recovery time are measured against RPO and RTO.
• Technical and business owners validate the recovered service and sign the result.
• Logs, screenshots, checksums, timings and exceptions are retained.
• Defects have owners and target dates, and material defects are retested to closure.
• Runbooks and the backup design are updated with lessons learned.

13. Recovery Checklist

Use this checklist during a real incident. Adapt it to the service and make sure decision authority is assigned before an emergency.

Assess and Authorise

• Confirm the scope, impact, cause and whether current data is trustworthy.
• Start the incident record and preserve evidence where required.
• Contain the failure or compromise before restoring.
• Identify the earliest known-good recovery point and expected data loss.
• Compare repair, failover and restore options against RTO, risk and business impact.
• Obtain recovery authorisation and notify required business, security, legal and vendor contacts.

Prepare the Recovery Environment

• Obtain clean recovery media, credentials, multi-factor methods, keys and licences.
• Recover or rebuild the backup platform and catalogue if necessary.
• Prepare isolated, alternate or replacement infrastructure with sufficient capacity.
• Confirm network, DNS, identity, storage, certificate and third-party dependencies.
• Record the chosen restore point and protect source backups from alteration.

Restore, Validate and Return

• Restore systems and data in the documented dependency order.
• Apply database logs only to the approved point and record any gaps.
• Scan and validate recovered systems before reconnecting after a cyber incident.
• Check integrity, permissions, security controls, integrations and performance.
• Complete representative user and business transactions.
• Measure the actual RPO and RTO and obtain business-owner acceptance.
• Communicate status, reconcile manual or standby transactions and plan failback.
• Increase monitoring, close the incident safely and conduct a lessons-learned review.
• Update the design, runbook, training and test schedule, then retest material improvements.

Call to Action

Select one important data set or business service and perform a documented recovery test within the next 30 days. Time the complete process, validate the result with the owner and record every missing dependency or manual step. Then repeat the process for the next highest-priority service.

Backups protect data. Tested recovery protects your life, your operations and your business.

This whitepaper provides general guidance. Adapt the design and test program to your technology, risk, contractual and regulatory environment.

If you require assistance reviewing a backup design, defining RPO and RTO, creating recovery runbooks or conducting recovery tests, Contact KAOS Data.

Check out our other Cheat Sheets and Blogs and if you would like us to write a cheat sheet for you, for FREE, (and we find it suitable) Contact Us.

Further Reading and References

The following resources provide additional guidance on backup, contingency planning, cyber recovery, RTO, RPO and database log protection:

• KAOS Data – What RTO and RPO Mean to Your Business – business-focused explanation of recovery objectives
• KAOS Data – Introduction to Data Protection and Recovery – overview of data protection and recovery concepts
• KAOS Data – Best Practice Designs for High Availability and Disaster Recovery – multi-site resilience and disaster recovery design