When a major outage stops operations, business leaders want to know when critical services will return, how much data has been lost and whether it is safe to resume work. Getronics’ Premnath Anand explains why cloud disaster recovery must start with those business priorities—and why a successful backup alone is not enough.
A successful backup job is useful evidence. It is not proof that applications, identities, data and business processes can be recovered together.
The real test is whether the organisation can restore a usable service within an agreed time, with an acceptable level of data loss and clear responsibility for each decision.
Backup and disaster recovery solve different problems
Backups preserve copies of data that can be restored after deletion, corruption or an attack. They are an essential part of recovery, but they do not define the entire recovery process.
Disaster recovery brings together the technology, people and procedures needed to restore IT services after disruption. Depending on the service and incident, that can involve restoring backups, rebuilding systems or switching to an alternative environment.
Business continuity is broader still. It considers how the organisation keeps operating while services are unavailable, including people, suppliers, communications and temporary ways of working.
A recovery plan therefore needs to answer more than “Do we have a copy?”
It needs to establish which services come first, what they depend on, who can authorise recovery and how the business will confirm that they are ready to use.
Define RTO and RPO before choosing the technology
Two measures help translate business priorities into recovery requirements:
Measure | What it tells the business |
|---|---|
Recovery time objective — RTO | The acceptable data-loss window, expressed as time. This helps determine how frequently data must be protected. |
Actual recovery time | How long recovery takes in a test or incident, including the dependencies and checks needed to make the service usable. |
Actual data loss | The gap between the data needed and the usable data recovered. This can exceed the RPO if recent recovery points are compromised or unavailable. |
These are business decisions supported by technical assessment. A finance platform, a customer-facing application and an internal archive do not automatically need the same recovery model.
The NIST definitions of RTO and RPO provide a useful starting point. The next step is agreeing what those objectives mean for each critical service.
Targets also need evidence. An RTO written into a plan is not the same as a recovery time demonstrated in a realistic exercise.
Ransomware makes the recovery point harder to choose
The most recent backup is not always the safest one to restore.
An attacker may have compromised an environment before the incident became visible. Recent recovery points can therefore contain malicious software, damaged data or unwanted configuration changes.
That does not change the definition of RPO. It changes whether the organisation can meet its target using a recovery point it can trust.
Recovery teams need to investigate the incident timeline, identify an appropriate recovery point and validate restored systems in a controlled environment before reconnecting them to production.
Microsoft’s ransomware recovery guidance recommends identifying the last clean recovery point, restoring into an isolated network and checking restored data for infection.
Backup anomaly detection can help flag unusual changes. It should support investigation and validation rather than be treated as proof that a recovery point is clean.
“Resilience isn’t about what is easiest for IT. It’s about what keeps the business running when things go wrong.”Premnath Anand
Cloud creates choices, not automatic resilience
Cloud services offer different ways to balance recovery speed, operating cost and application requirements.
Some workloads can be restored from backups. Others need a prepared recovery environment or replicated systems to support tighter recovery objectives.
The right approach depends on the business impact of downtime and data loss, together with the application’s dependencies.
Cloud does not remove recovery costs. Storage, replication, networking, licensing, standby capacity and testing all need to be included. Faster recovery options typically require more investment and operational preparation.
AWS’s guidance on cloud disaster recovery explains why recovery strategies should be reassessed against business impact, risk and cost.
The same discipline applies to hybrid and multicloud environments. Using more than one platform does not, by itself, create a working recovery path. Identity, connectivity, application compatibility and operational ownership still need to be designed and tested.
The aim is to match protection to business criticality, without paying for an unnecessarily demanding recovery model across every workload.
Include AI services in the recovery plan
As organisations put AI into production, recovery planning needs to account for more than conventional applications and file storage.
An AI-enabled service may depend on:
- Model versions and fine-tuning artefacts.
- Source documents, datasets and their permissions.
- Vector databases and search indexes.
- Application configuration, prompts and workflow definitions.
- Identity services, credentials and external model providers.
Some assets need to be backed up. Others can be rebuilt from protected source material, provided that the rebuild time meets the service’s recovery requirements.
For externally hosted models, the organisation also needs to understand the provider’s responsibilities and what happens if that service becomes unavailable.
The practical question is straightforward: what must be restored, rebuilt or reconnected before the business can use the AI service again?
Three foundations for a safer recovery
Protect the recovery copies
Use appropriately configured immutable or offline copies, separate access controls and protection against destructive administrative actions. Confirm retention and locking settings rather than assuming a backup product makes every copy untouchable.
Prepare a clean recovery environment
Provide a controlled place to restore and inspect systems before returning them to production. Define the evidence needed for security and application owners to approve reconnection.
Plan for identity and access
Document how recovery teams will access the systems they need if normal identity services are unavailable or compromised. Include directory services, cloud identities, privileged access and emergency access procedures in the recovery sequence.
These controls work together. Protected data has limited value if nobody can access the recovery tools, or if restored applications are immediately reconnected to an environment that remains compromised.
Test the business service, not just the restore job
Recovery arrangements need to change as applications, integrations, identities and business priorities change.
A useful exercise should demonstrate that the service works, rather than simply confirm that a server starts.
That means testing application dependencies, access, data consistency, security checks and the business team’s ability to complete essential tasks.
Automation can make repeatable checks easier. It does not remove the need for coordinated exercises and business acceptance.
Record what happened, compare the results with the agreed RTO and RPO, and assign owners to any gaps. Repeat relevant tests after significant changes.
Before the next incident, leadership should be able to answer:
- Which business services must recover first?
- What downtime and data loss have their owners accepted?
- When was a representative recovery last demonstrated?
- How will we select and validate a clean recovery point?
- Can the recovery team operate if normal identity services are unavailable?
- Who authorises failover, reconnection and the return to normal operations?
A recovery plan becomes credible when those answers are supported by evidence.
How Getronics helps
Getronics’ IT Service Continuity Management services support recovery planning through discovery, risk review, RTO and RPO definition, disaster recovery strategy and managed testing.
Our Cloud & Infrastructure services connect that planning with private, public and hybrid cloud operations, including backup, replication and disaster recovery options.
The starting point is understanding what the business needs to recover, then designing and testing a recovery approach around those requirements.
Can your recovery plan meet your business requirements?
Discuss your critical services, recovery targets and testing gaps with Getronics.
About the author
Premnath Anand
Director of Public Cloud Operations
Premnath Anand is Director of Public Cloud Operations at Getronics, where he leads global cloud strategy, delivery and growth across public, private and hybrid environments. With experience building enterprise cloud services and leading international teams, he works with business leaders on cloud transformation, FinOps and operational governance, translating complex technology requirements into reliable services, clearer accountability and measurable business value.
www.linkedin.com/in/premnathanand/
