Your Continuity Plan Is Only as Good as Your Last Restore

Ask a team whether they have backups and the answer is almost always yes. Ask when they last restored one, and the room goes quiet.

That silence matters more than most people realize. Backups are easy to set up and easy to forget. They run on a schedule, report success, and sit untouched until the day you need them. Continuity is decided on that day. It doesn't depend on whether a backup job ran. It depends on whether you got your data back.

Confidence is not the same as capability

Veeam's 2026 Data Trust and Resilience research surveyed more than 900 senior IT, security, and risk leaders. It found that 90 percent were confident they could recover from a cyber incident within their recovery objectives. Among organizations actually hit by ransomware, only 28 percent fully recovered their data, and 44 percent got back less than three-quarters of it.

That isn't a failure of effort. Most of those teams had backups. What they didn't have was proof. The backup existed, but the restore had never been tested, or the copy was in the wrong place, or the retention window had already rolled past the last clean version.

Continuity plans tend to live in documents: who calls whom, what gets prioritized, which systems come back first. All of it depends on one practical step working when you need it. You have to be able to restore.

Most bad days aren't attacks

Ransomware gets the headlines, but it isn't the most common reason teams reach for a backup. Human error is. Someone deploys the wrong build, a cleanup script runs against the wrong directory, a migration goes sideways halfway through, or a config file gets overwritten at 6 p.m. on a Friday.

None of these take down the business on their own. They become real problems when recovery means opening a ticket, finding an old image, restoring the whole machine, and hoping nothing else broke along the way. For these everyday incidents, what matters is how narrow and how fast your recovery can be. You want to restore the one folder that broke, not rebuild the entire server to get twenty gigabytes back.

When it is an attack, the backup is the target

Attackers understand that an organization with clean backups is much less likely to pay. So they go after the backups first.

Veeam's Data Protection Trends research found that 96 percent of ransomware attacks targeted backup repositories, and attackers affected those backups in about three out of four cases. Sophos's ransomware research shows why that matters. Organizations whose backups were compromised faced median recovery costs of roughly $3 million, against about $375,000 for those whose backups survived. That's close to eight times higher.

The lesson is simple. Where your backup lives is a security decision, not just a storage one. A backup on the same server it protects doesn't survive losing that server, whether the cause is an attack, a hardware failure, or a mistake. Many hosting platforms still ship exactly that as their default "included" backup.

Four questions worth asking about your recovery setup

Before worrying about tools, it's worth answering these honestly.

Where does the copy live? If it's on the same machine or the same disk as the workload, it shares the same failure. A useful backup is physically independent of what it protects.

When did you last restore, and did it work? A backup nobody has restored is a hope, not a plan. Pick one non-critical system and restore it this quarter.

What history do you keep, and who decides what gets deleted? Short retention can mean your last clean copy is already gone by the time you notice a problem. Retention should be a deliberate policy, not whatever the default happened to be.

Who's on the call when you need it? Recovery usually happens under pressure. It helps to know whether you'll be reading documentation alone or working with someone who knows the infrastructure.

How recovery works on InMotion Cloud

Backups on InMotion Cloud are part of the managed platform. They land in object storage inside your own project, on a replicated storage cluster that sits apart from the server being protected. Losing the server, or the host underneath it, does not take the backups with it. If you would rather keep copies on your own infrastructure, you can send them to a server of yours over SSH.

You can back up a whole server as a single image or protect specific folders on their own schedules, with retention set across daily, weekly, monthly and yearly copies. The most recent successful backup is never removed automatically.

Folder restores run from the dashboard, which covers the bad deploy and the deleted directory. Full-server recovery happens with our engineers, the same people who run the rest of your environment.

One limit, stated plainly. A separate copy is not the same as an immutable one. Independent storage protects you when a server is lost. It does not stop someone with administrative access from deleting backups, and if that is part of your threat model, we would rather talk it through with you than let this section imply otherwise.

Start with one restore

If you take one thing from this, make it this: pick a system and restore it this month. Time it, check what came back, and write down what surprised you. That single exercise will tell you more about your continuity posture than any policy document.

If you'd like a second set of eyes on how your recovery is set up, talk to an InMotion Cloud engineer.