Data backup and recovery: 3 incidents that show why recovery is the real test

Data backup and recovery is measured by what you can restore

Your business needs its data back when a server fails, a laptop disappears, or a cloud application loses records. Data backup and recovery decides whether that happens, and the outcome depends on choices you make before any incident: what you protect, how often you capture it, where the copies live, and whether anyone has proved they can restore them. 

Most recovery gaps stay hidden during normal operations. They sit in a postponed restore test, an unresolved backup alert, or an assumption that another team or provider protects the data, and they stay there until an incident exposes them. 

Confidence can mask those gaps. In the OpenText Cybersecurity 2025 Global Ransomware Survey of 1,773 executives and security leaders, 95% of respondents said they were confident they could recover from a ransomware attack, yet only 15% of organizations hit by ransomware fully recovered their data.  

October is Cybersecurity Awareness Month. For IT security leaders and managed service providers (MSPs), it gives a practical reason to run restore tests and confirm which servers, devices, and cloud data your organization can bring back. A data backup strategy should answer one direct question: If important information disappeared today, what could your organization get back, and how quickly? 

Three recent data loss incidents show what that question looks like in practice, and each one carries a lesson you can apply to your own environment. 

At a glance: How 3 incidents exposed recovery gaps

Before diving into each story, the table below provides a summary of the three real-world data loss incidents. Each scenario highlights where normal operations broke down, what ultimately determined whether data could be saved, and the key safeguard you can implement to protect your own environment.

1. Keep backups out of reach of anything that can delete production (PocketOS, April 2026)

On April 24, 2026, an AI coding agent deleted the production database of PocketOS, a software platform for car rental businesses. Founder Jer Crane reported that the agent hit a credential mismatch in a staging environment, found an API token in an unrelated file, and used it to delete a storage volume at infrastructure provider Railway. Railway stored that volume's backups in the same location as the data, so one nine-second request removed the database and its backups together.

PocketOS staff spent the weekend rebuilding records from payment histories and email logs. Railway then restored the data from separate disaster backups it maintains.

The recovery worked because one copy sat outside the reach of the delete request. The 3-2-1 backup rule builds in that separation: three copies of your data, on two types of storage, with one offsite backup. An immutable backup, which nobody can change or delete during its retention period, and an air-gapped backup, which stays isolated from production credentials, add further protection.

​​​The lesson: control who and what holds delete rights and keep at least one recovery copy outside the system or account that can delete production data.​​​​     ​​ 

OpenText™ Cybersecurity offers server backup capabilities that help organizations address this type of data risk. OpenText™ Server Backup – Public Cloud replicates forever-incremental backups to the cloud and stores them in immutable formats, with role-based access controls and recovery of full systems, files, or application data. Keep backup credentials separate from production credentials, and run restore tests that prove the database comes back consistent. 

2. Make sure device data has an enabled backup (Google Maps Timeline, March 2025)

In March 2025, Google confirmed that a technical issue had deleted Google Maps Timeline data for some users. Timeline records the places a person visits and the routes they take, and Google had recently moved that history from its servers to users' devices.

When the glitch hit, outcomes came down to a single toggle: users with encrypted backups restored their location histories instantly, while those without permanently lost their data. Because backups were optional and off by default, most users never knew they were at risk until the data was gone. 

This incident reflects an operational reality common in the enterprise: despite cloud migration efforts, critical work routinely accumulates on local endpoints. Employees frequently save proposals, financial models, and active project files directly to local desktop or document folders for quick access. When a laptop suffers a hardware failure, ransomware attack, or theft IT can quickly supply new hardware, but the unbacked files residing on that drive are lost permanently. ​     ​ 

The lesson:  
Turn on automated endpoint backup on all user devices by default, so critical files created on local laptops and desktops are protected regardless of employee settings or habits. 

OpenText™ Core Endpoint Backup automates backup for Windows and macOS laptops and desktops. It installs, activates and backups up silently across devices, allows you set policies from a central dashboard, and can recovery files or wipe a device from anywhere.

3. Plan recovery for the whole business (Marks & Spencer, April 2025)

Over Easter weekend in April 2025, British retailer​​ ​Marks & Spencer (M&S) suffered a major cyberattack​. The company was forced to shut down its automated inventory systems and rely on manual pen-and-paper tracking to move fresh food, beverages, and clothing, leaving many store shelves empty. 

M&S estimated the attack would cost approximately £300 million in lost operating profit, with online service disruptions stretching into July. Full home delivery for most of its clothing lines was not restored until 46 days after the initial breach, which attackers achieved through social engineering targeted at a third-party contractor. 

M&S shows that recovery affects the entire business. When one set of systems goes down, the impact spreads to every team that depends on it. A recovery plan has to account for everything the business needs to keep running, and for most organizations today, that includes the email, files, and collaboration tools that live in SaaS applications. 

SaaS providers operate under a shared responsibility model: they keep the service available, but protecting and restoring your data is largely your responsibility. Built-in features like recycle bins and retention policies help with everyday mistakes, but they have time limits, they live inside the same environment they’re meant to protect, and they aren’t designed for large-scale recovery after ransomware, a malicious insider, or a compromised admin account. 

To close any gaps this might create, start by identifying the mailboxes, SharePoint sites, user files, and collaboration content your teams need to operate. Then confirm which data types your backup covers, how long recovery points ar​​e kept, and what administrators can actually restore, whether that’s a single email or an entire environment. 

Platforms offer native options, such as Microsoft 365 Backup for supported workloads or Salesforce Backup & Restore, but teams should verify which capabilities are enabled and test them before an incident occurs. Support for a platform does not automatically mean support for every data object or restoration workflow. Ask your team to demonstrate the specific SaaS recovery scenarios your business relies on. 

The lesson: 
Plan and test recovery across your entire operational footprint, including third-party SaaS applications, so business operations can withstand supplier breaches and widespread system outages. 

OpenText Cloudally Backup for Microsoft 365 provides automated daily backup and point-in-time recovery for individual items or entire environments. Because it runs as an independent service, your backups stay separate from the environment you’re protecting, so critical data remains recoverable even when Microsoft 365 itself is affected.

Make recoverability part of the service your MSP delivers

An MSP can turn backup coverage, recovery targets, and restore testing into an agreed backup and disaster recovery service. Start with a record of the servers, endpoints, and cloud workloads the service covers, and name an owner for each exclusion or gap. 

Then agree two measures with each customer. The recovery point objective (RPO) sets the maximum period of changes the business can afford to lose, and the recovery time objective (RTO) sets the target time to restore a service. A customer who needs current order data within an hour requires a much tighter RPO and RTO, and a different backup schedule than one who can wait a day for yesterday's documents. 

Prove the service with regular restore tests and compare the elapsed time and the age of the recovered data with the agreed RPO and RTO. Protect the recovery path as well: limit administrative access to backup consoles, keep one copy that a production incident cannot delete, and contain any compromise before restored systems return to use during ransomware recovery.  

The M&S attack began at a third-party contractor, so MSPs should apply the same controls to their own access into customer environments to strengthen cyber resilience for every customer. 

OpenText™ Cybersecurity offers backup capabilities that help MSPs address this type of recovery risk by delivering managed server protection across their customer base.

Use October to prove what you can recover

Experienced people make mistakes, automated tools act on the permissions they receive, and established providers suffer failures. Each incident above came from one of those causes, and in each case the outcome depended on the copies and plans in place before the loss. 

This Cybersecurity Awareness Month, run a short disaster recovery testing exercise:

• Test one server workload  
  Restore it to a test environment and confirm the application starts with consistent data. 

• Test one employee device  
  Recover files from its most recent backup and compare them with what the employee expects to find. 

• Test one cloud data set  
  Restore a mailbox, site, or file set from an independent backup and record how long the restore took. 

• Check who can delete your backups  
  Review the accounts, tokens, and automated tools with delete rights, and confirm that one copy sits outside their reach. 

Record each result against your RPO and RTO, assign an owner to every gap, and then test it again after you’ve made the improvements. A tested data backup and recovery process shows your business what it can restore today and where it needs more protection.