Backups Are Only Valuable When You Can Recover

Why modern backup, cyber recovery, and cloud-based disaster recovery must work together

Most organisations understand that backups are important. Fewer can say with confidence that their backups are complete, protected, regularly tested, and capable of restoring the business after a serious outage or cyberattack.

That difference matters.

A successful backup job does not necessarily mean the organisation can recover. Data may be corrupted, recovery procedures may be incomplete, dependencies may not be understood, or attackers may have compromised the backup environment before launching ransomware.

The real question is therefore not whether your organisation has backups.

It is whether the business can recover when those backups are needed most.

Cyberattacks Have Changed the Recovery Conversation

Traditional disaster recovery was largely designed around equipment failure, power loss, natural disasters, or the loss of a data centre.

Those risks still exist, but organisations must now prepare for deliberate disruption.

Check Point’s 2025 security research reported a 44% year-on-year rise in global cyberattacks. Veeam found that 69% of surveyed organisations had experienced a ransomware attack during the preceding year.

Attackers increasingly target backup repositories, administrator accounts, identity platforms, and recovery tools. They understand that an organisation is more likely to pay when its route back to normal operations has been removed.

A cyberattack may also affect far more than one server. It can spread across endpoints, cloud platforms, applications, networks, identity services, production systems, and connected backups. Data may be stolen before systems are encrypted, creating regulatory and reputational consequences even when restoration is possible.

Backup can no longer be treated as a routine infrastructure task. It has become a core part of cyber resilience.

Most Organisations Are Less Prepared Than They Think

There is often a gap between confidence and actual recovery capability.

An organisation may have backup software, daily reports, documented recovery objectives, and an annual disaster recovery plan. Yet these controls are not always tested against a realistic outage or cyberattack.

When an incident occurs, teams may discover that:

• Some systems were never included in the backup policy

• Backup credentials were compromised with production credentials

• The available recovery points contain malware or corrupted data

• Application dependencies are incomplete or undocumented

• Cloud and SaaS information is not adequately protected

• Recovery procedures depend on unavailable people or systems

• Restored applications cannot communicate with identity, network, or database services

Veeam's research found that only 10% of affected organisations recovered more than 90% of their data, while 57% recovered less than half.

The financial consequences may also be severe. IBM estimated the average global cost of a data breach at US$4.44 million in 2025. Uptime Institute found that one in five respondents experiencing a significant outage reported costs above US$1 million.

Backup and recovery are therefore not only technical concerns. They are business-risk decisions.

Backup Is Not the Same as Recovery

Backup creates a recoverable copy of data.

Disaster recovery restores the infrastructure, applications, connectivity, security, and operating processes required to resume a business service.

Cyber recovery adds another requirement: the organisation must recover into an environment known to be clean.

Restoring a service may involve far more than recovering a virtual machine or database. Networks must be recreated. Identity services must be available. Security controls need to be applied.

Applications may have to be restored in a particular sequence, and databases must remain consistent.

During a cyberattack, the newest backup is not necessarily the safest recovery point. An attacker may have been present in the environment for weeks or months before the incident became visible.

This is why Axionik’s approach begins with the business service rather than the backup product.

The first questions are:

• What must be recovered?

• How quickly must it return?

• How much data loss can the organisation tolerate?

• Which applications and systems does it depend on?

• How will the restored service be validated as safe?

These answers establish practical Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO).

High Availability Is Not Disaster Recovery

High availability and disaster recovery solve different problems.

High availability is intended to keep a service running when an individual component fails. It may use clustered servers, redundant storage, multiple network paths, application replication, or automated failover.

Disaster recovery is intended to restore the service after a broader disruption. This could include a data-centre outage, regional failure, ransomware attack, compromised administrator account, data corruption, or the loss of the production environment.

The distinction is particularly important because high-availability systems often replicate changes immediately.

If information is deleted accidentally, corrupted by an application, or encrypted by ransomware, the same damage may be replicated to the secondary system.

A highly available environment can therefore remain operational while still becoming unrecoverable.

High availability may protect against:

• A failed server

• A storage component failure

• A network-path failure

• A local infrastructure fault

• An individual application instance failing

Disaster recovery must prepare for:

• Loss of the wider production environment

• Regional or facility outages

• Ransomware and destructive attacks

• Data corruption

• Compromised privileged accounts

• Accidental deletion

• Failures affecting multiple connected systems

A resilient organisation needs both.

High availability helps maintain service during expected component failures. Disaster recovery provides an independent route to restore the business when production systems and normal failover paths are no longer trustworthy or available.

Axionik does not treat clustering, replication, or platform availability as a replacement for backup and recovery.

The key question is not only whether a system can fail over.

It is whether the organisation can recover when failover is no longer possible.

The Traditional DR Site Can Be Expensive

Traditional disaster recovery often requires a second physical environment with duplicate servers, storage, networking, licences, support contracts, facility space, power, cooling, and operational resources.

Much of this capacity may remain underused during normal operations.

A dedicated secondary site or active-active architecture may still be appropriate for highly critical systems. However, applying this model to every workload can be expensive and difficult to maintain.

The secondary environment may also fall behind production. Hardware changes, applications are upgraded, dependencies move, and recovery documentation becomes outdated.

A DR site that appears complete on paper may therefore not reflect the live production environment accurately.

Cloud-based recovery provides another option.

Using Cloud as a Recovery Environment

Axionik uses cloud infrastructure as a recovery platform for suitable on-premises, cloud, and hybrid workloads.

Instead of maintaining a fully sized duplicate data centre, protected backup data and the essential components of the recovery environment are retained in the cloud. The wider compute environment can then be created, activated, or scaled during recovery testing or an actual disruption.

This model may include:

• Backup and restore

• Pilot-light recovery

• Warm standby

• Cloud-based replication

• Automated infrastructure rebuilding

• Isolated cyber-recovery environments

In a pilot-light design, critical data and a limited core environment remain available. Application servers and additional capacity are activated when required.

A warm-standby model keeps more of the environment running continuously. This supports faster recovery but carries a higher ongoing cost.

This allows recovery speed and cost to be balanced according to the importance of each workload.

Cloud recovery is not completely free until a failure occurs. Organisations still pay for protected storage, replication, security controls, management services, connectivity, and any core recovery components that remain active.

The saving comes from avoiding the need to operate a fully sized duplicate production estate throughout the year.

Most of the compute capacity is consumed during testing or actual recovery, rather than being permanently powered, licensed, and maintained.

For many organisations, this provides a more flexible and cost-effective alternative to a traditional DR site.

Axionik’s Approach to Backup and Recovery

Axionik treats backup, disaster recovery, and cyber recovery as connected capabilities rather than separate technology projects.

Discover and Assess

The first step is understanding the environment and its current recovery posture.

This includes identifying:

• Critical applications and data

• On-premises, cloud, and SaaS workloads

• Infrastructure and application dependencies

• Existing backup coverage

• Recovery procedures and runbooks

• Compliance and retention requirements

• Operational risks

• Cybersecurity exposure

We also assess whether backup copies are isolated, immutable where appropriate, protected by separate identities, and monitored for unusual activity.

The outcome is a realistic view of current recoverability and the gaps that need attention.

Define Business Recovery Requirements

Recovery priorities must come from the business.

We work with stakeholders to understand which services are critical, how long the organisation can operate without them, and how much data loss is acceptable.

These requirements are translated into RTO and RPO targets and used to group workloads into recovery tiers.

A critical transactional service may require rapid recovery with very little data loss. A lower-priority archive may tolerate a longer recovery period.

This avoids applying the most expensive recovery architecture to every workload while ensuring critical systems receive appropriate protection.

Protect the Backup Environment

Backup infrastructure is now a direct target during many cyberattacks.

Our approach may include:

• Immutable recovery copies

• Offline or logically isolated backups

• Separate administrative identities

• Multi-factor authentication

• Restricted privileged access

• Multi-person approval for destructive actions

• Encryption in transit and at rest

• Malware and anomaly detection

• Protected retention policies

• Separation between production and recovery management

The goal is to prevent one compromised identity or platform from destroying both production data and the organisation’s recovery capability.

Design the Right Recovery Architecture

The recovery architecture may combine:

• Local backup

• Cloud object storage

• Immutable repositories

• Cloud replication

• Pilot-light recovery

• Warm standby

• Dedicated secondary infrastructure

• Isolated clean-room environments

The correct model depends on business importance, data volume, recovery speed, connectivity, application design, regulation, sovereignty, cost, and operational capability.

The goal is not to force everything into cloud.

It is to use cloud where it improves flexibility, recoverability, and cost efficiency.

Build a Clean Recovery Capability

Cyber recovery requires more than restoring systems quickly.

The organisation needs a controlled environment in which recovered data and applications can be checked before being returned to production.

A clean recovery process may include:

• Identifying the last known clean recovery point

• Restoring into an isolated environment

• Scanning for malware and indicators of compromise

• Validating application and database integrity

• Rebuilding compromised infrastructure from trusted code

• Resetting identities and privileged credentials

• Applying security patches and controls

• Reconnecting services in a controlled sequence

Recovering an infected system quickly is not a successful recovery.

The objective is to restore trusted business services safely.

Automate Recovery Where Possible

During a major incident, manual processes create delays and increase the chance of mistakes.

Infrastructure as Code, orchestration, automated network configuration, and tested recovery runbooks can help recreate environments more consistently.

Automation also makes testing easier. Recovery resources can be built, validated, and removed without maintaining the full environment permanently.

Automation does not replace experienced people, but it makes recovery more repeatable and less dependent on individual knowledge during a crisis.

Test the Full Business Service

A backup should be tested through restoration.

A disaster recovery plan should be tested through the return of a working business service.

Testing should confirm that:

• Data can be restored

• Applications start correctly

• Databases remain consistent

• Networks and identities function

• Security controls are active

• Dependencies are available

• Users can access the service

• RTO and RPO objectives are achievable

Cyber-recovery exercises should also test whether the organisation can identify a clean recovery point, operate without compromised credentials, and communicate during a wider incident.

The goal is not simply to satisfy an audit.

It is to identify weaknesses before a real failure or attacker exposes them.

Operate and Improve Continuously

Recovery capability changes whenever the production environment changes.

New systems are introduced. Applications are upgraded. Cloud services are adopted. Data volumes increase. Threats evolve.

Backup and recovery therefore require ongoing:

• Monitoring

• Capacity management

• Security reviews

• Recovery testing

• Runbook maintenance

• Reporting

• Compliance validation

• Continuous improvement

Recovery plans should be treated as living operational capabilities rather than documents reviewed once a year.

Prevention Alone Is Not Enough

Strong cybersecurity controls remain essential, but no organisation can guarantee that every attack will be prevented.

Phishing, stolen credentials, software vulnerabilities, malicious insiders, supply-chain compromises, cloud misconfiguration, and human error may all create an opening.

The continued increase in attacks shows why organisations need to plan not only for prevention, but also for containment and recovery.

The question is no longer only whether security controls can stop an attacker.

It is whether the organisation can continue operating and restore trusted services when those controls fail.

Recovery Confidence Must Be Proven

No organisation can prevent every infrastructure failure, human mistake, cyberattack, or disaster.

What it can control is how prepared it is to respond.

Good backups remain essential, but they are only the starting point. Real resilience comes from understanding business priorities, protecting recovery data, isolating critical copies, designing the right architecture, automating repeatable processes, and regularly proving that services can be restored.

Cloud-based recovery can make this more affordable by reducing the need for a fully duplicated DR estate. It allows organisations to retain protected data and essential recovery capability while activating larger amounts of compute only during testing or an actual disruption.

The goal is not simply to report that backup jobs completed successfully.

It is to know, through evidence and regular testing, that the organisation can withstand disruption and recover the business.

By Sunny Vandeyar

SME - Data Resilience

About the Author

Sunny Vandeyar is a data resilience expert with extensive experience helping organisations protect critical information, strengthen recovery capabilities, and prepare for operational disruption and cyber incidents.

He has worked across backup and recovery, disaster recovery, cyber resilience, recovery testing, and managed data protection services within complex enterprise environments. Sunny focuses on helping organisations build practical, reliable recovery strategies that reduce risk, improve readiness, and support long-term business continuity.