Cloud backup: what AWS cannot restore

Imagine opening your system dashboard on a Monday and reading this notice from your provider: some of your data cannot be restored. Not "it will take a while". Not "we are working on it". It is simply gone. That is roughly what AWS told customers after facilities in the Middle East were hit by Iranian attacks, according to the Wall Street Journal. It is the kind of news that makes everyone who depends on the cloud stop for a second and think: what if that were me? The answer depends entirely on how your cloud backup is built today.

Let me be blunt: most of the companies I work with do not have a backup. They have the feeling of a backup. Those are different things.

"But it is in the cloud, isn't it safe?"

This is the most expensive confusion in technology right now.

The cloud solves one specific problem very well: it takes away the job of buying servers, replacing burned out drives and paying the air conditioning bill for a server room. It does not take away your responsibility for your data. Every major provider has this written into the contract, in what they call the shared responsibility model. They handle the infrastructure. You handle what you put inside it.

Translated into business owner language: if a data center turns to dust, the provider gives the service back. Your files come back only if you told someone to copy them somewhere else first.

And there is a technical detail that fools a lot of people. When you sign up for a cloud service, you pick a "region", something like São Paulo or Northern Virginia. Inside a region there are availability zones, which are different buildings. Most systems are set up to survive losing one building. Almost none are set up to survive losing an entire region. And the regional scenario is exactly what shows up in war, natural disaster, a large fire or a legal freeze.

This is not hypothetical, it has happened several times

War feels distant. So let's use more ordinary examples.

In March 2021, OVH, the largest cloud provider in Europe, had a data center in Strasbourg destroyed by fire. The whole building. Thousands of customers lost data permanently. Many found out that day that the "backup" they were paying for sat on the same campus that burned. Companies went under.

In 2014, Code Spaces, which hosted code for other companies, was attacked. The intruder got into the AWS admin console and deleted the data along with the backups, because backup and production lived in the same account with the same credentials. The company announced it was shutting down in less than 24 hours.

In 2023, a South Korean provider lost customer data when ransomware encrypted production and the connected backups. The pattern repeats: the backup existed, but it was within reach of the same problem.

A backup that dies along with the original was never a backup. It was just a second copy of the risk.

What you really need to have outside your provider's cloud

There is an old IT rule, the 3-2-1, and it has aged very well. Three copies of the data, on two different media types or platforms, with one of them off site.

For a small or midsize business running on SaaS, I adapt it like this:

• One copy outside your main provider. If your system runs on AWS, the backup copy cannot live only on AWS. It can go to Google Cloud, to cheap storage like Backblaze, or even to a NAS in the office.
• One copy that the production system cannot delete. Separate credentials, separate account, ideally with deletion locked for a period of time (immutability). That is what saves you from ransomware and from an angry employee.
• One copy in a format you can read without the vendor. CSV, JSON, PDF, SQL. If your CRM backup only opens inside the CRM itself, and the CRM is gone, you own a pretty, useless file.

That third point is the most forgotten and the most important in SaaS. You are not only on infrastructure cloud. You are on Bling, Omie, RD Station, Notion, ClickUp, WhatsApp Business. Each of those holds pieces of your business. Each one can block you over a suspected card fraud, end a plan, or simply break.

The test that almost nobody runs

Here is the question I ask in every first meeting, and it almost always stops the conversation: when was the last time you restored a backup?

Not "generated" one. Not "checked that the file exists". Actually restored it, opened it, looked at the data and confirmed everything was there.

An untested backup is a religious belief. I once found an export routine that had been running for eight months producing a 0 KB file, because the API password had expired and nobody read the error email. I have also seen a database dump that was perfect, complete and intact, but missing the attachments folder: every signed contract in PDF, every product photo, none of it was in the backup. The database had the file paths. Not the files.

Do this once a quarter. Take the most recent backup, restore it in a separate environment, and try to answer three simple questions:

1. Is the data from the last seven days there?
2. Do the attachments and images open?
3. How long did this take, from zero to working?

That third answer is your real recovery time. If it is eight hours and your business cannot take two, you do not have a backup problem, you have an architecture problem, and it is better to find that out in a test than in a crisis.

How much time and how much data you can afford to lose

Two questions solve 90% of the planning, and neither of them is technical.

How long can the business stay down? An hour? A day? A week? An online store down for a day loses sales and recovers. A clinic without patient records for a day cancels the whole schedule and damages its reputation.

How much data can the business afford to lose? If the backup runs overnight and the problem happens at 5pm, you lose a full day of work. Every order, every logged call, every appointment. For some businesses that is acceptable. For others it is not, and then the backup needs to be continuous.

Answer those two with a number and the rest becomes execution. Without them, any solution someone sells you is a guess with an invoice attached.

And yes, there is a cost. But far less than people imagine. Keeping 500 GB in cold storage on a second cloud costs somewhere between 2 and 5 dollars a month. The automation that copies it every day, tests it and alerts you when it fails is configuration work, not a lifetime subscription. Compare that to the value of a week of downtime and the math does itself.

What to do this week

You do not need a six month project. You need an afternoon.

List every system where your business keeps something that matters. Management system, finance, CRM, email, files, website. For each one, write down three things: where the data lives, whether an automatic export exists, and who has access to that export. Just building that table usually reveals two or three holes nobody knew about.

After that, pick the most critical system and set up a daily export to somewhere other than the original vendor. Just one. Start with whatever would hurt most to lose.

The AWS news is dramatic because it involves missiles, but the lesson is ordinary and it applies to people who will never go near a conflict zone. Every dependency you cannot replace is a bet that nothing will go wrong. And it does, sooner or later, usually on a Friday afternoon.

If you want a second opinion on where the holes are in your setup, tell me how it works today. Most of the time it can be solved with simple automation, without replacing anything you already use.

AWS told customers that some of their data is simply not coming back. Not "it will take a while". Not coming back.

Most of the companies I work with do not have a backup. They have the feeling of a backup.

The cloud takes care of the infrastructure. Your data is still your responsibility, it is right there in the contract.

And here is the question that almost always stops the meeting cold: when was the last time you actually restored a backup? Not generated one. Restored it, opened it and checked it.

I once found a routine that had been running for eight months producing a 0 KB file, because the API password had expired and nobody read the error email.

A backup that dies along with the original was never a backup. It was just a second copy of the risk.

If you want, tell me how your setup looks today. Most of the time it can be solved with simple automation, without replacing anything you already use.

#backup #cloudcomputing #riskmanagement #technology #smallbusiness