Cloud backup: what the AWS case teaches your business

If your company's system disappeared tomorrow, could you say how long it would take to start selling again? Most business owners I know answer with "oh, but it's all in the cloud." That's exactly where the danger lies. Cloud backup only really protects you when someone planned it on purpose.

This week brought a very direct reminder of that. AWS, the largest cloud provider in the world, admitted it can't restore some of the data stored in facilities in the Middle East that were hit by Iranian attacks. That's right. The company that is a synonym for "reliable cloud" said, in plain words, that some data is never coming back.

You probably don't have a server in Dubai. But the lesson applies to any company that runs on online systems. In other words, almost all of them.

What happened to AWS, in plain language

The cloud isn't a cloud. It's a building. A building full of computers, with power, air conditioning, cables and people working. When that building gets hit by a missile, a fire or a flood, the data inside is at risk.

AWS organizes its buildings into "regions." Each region has a few physically separate data centers, precisely so that a problem in one place doesn't take everything down. In most cases, this works really well.

The thing is, this protection has limits. If a customer kept their data in a single region, and that entire region was affected, there's no magic. The provider can be excellent and still have nowhere to pull a copy from.

And here comes the part few people read in the contract.

What exactly is the cloud responsible for?

Every major provider works with what they call "shared responsibility." Translation: they take care of the infrastructure, and you take care of your data.

In practice, it looks something like this:

• The provider guarantees that the building has power, that the servers work and that nobody gets in without authorization.
• You guarantee that there's a copy of your data somewhere else, that passwords are secure and that someone knows how to restore everything if things go wrong.

When you sign up for a SaaS, like a CRM, an ERP or an e-commerce platform, the logic is similar. The software company takes care of the system. But if an employee accidentally deletes 3,000 customers, or if the vendor goes under, the question "where's my data?" will be yours to answer.

I've seen a small business find out that the scheduling system it had used for 4 years only kept backups for the last 7 days. An import error went unnoticed for two weeks. By the time they caught it, the good copy had already been overwritten.

How to do cloud backup that actually works

You don't need to become an infrastructure expert. You need a method. The best-known rule in the industry is 3-2-1, and it's simple enough to fit on a napkin:

• 3 copies of your important data (the original plus two more).
• 2 different types of storage (for example, the system itself and a separate storage service).
• 1 copy outside the main location, in another region, another provider or another country.

The AWS case is exactly a failure of the "1." Anyone who had everything in a single region was left stranded.

For a small or mid-sized business, this can be very concrete. Picture a clinic that uses an online patient records system. A reasonable plan would be:

1. The main system, where the team works day to day.
2. An automatic export, every night, to storage at a different provider.
3. A weekly copy kept in another geographic region, with access limited to one or two people.

None of this requires a full-time IT team. With well-built automation, it runs on its own and alerts you on WhatsApp or by email if any copy fails.

How long can your business stay down?

Before picking a tool, it's worth answering two questions. They have technical names, but the idea is very down to earth.

How much data are you willing to lose? If the backup runs once a day and the problem happens at 5 p.m., you lose a whole day of work. For an online store with 200 orders a day, that can be a disaster. For an office that updates a spreadsheet once a week, it might not matter at all.

How long can you stay offline? An hour? A day? A week? Each answer changes the cost of the solution. Getting back up in minutes is expensive. Getting back up in two days costs a lot less.

There's no universal right answer. There's the right answer for your cash flow. The mistake is never asking the question and finding out the answer on the worst possible day.

A quick calculation helps you decide. Take your average daily revenue and multiply it by the number of days you'd be down. If your business brings in R$ 8,000 a day and would go 5 days without its system, that's R$ 40,000 at stake. And that's not counting the customer who left and won't come back. Next to that, paying a few dozen reais a month for extra storage looks cheap.

The backup nobody tested

Here's my strongest opinion on the subject: most companies that think they have a backup actually have a file. And a file is not the same thing as a recovery plan.

A backup that has never been restored isn't a backup. It's faith.

I've seen it all. Backups that had been saving the wrong folder for months. A password-protected zip file nobody remembered the password to. An export that only brought customer names, with no phone numbers and no history. In every one of these cases, the company "had a backup." Until it needed it.

The test doesn't have to be complicated. Once a quarter, someone on the team takes a copy and tries to restore it in a separate environment. Does it open? Is the data complete? How long did it take? Write it all down. If it failed, great: you found out on a quiet day, not on a chaotic Monday.

It's like a fire extinguisher. Having one hanging on the wall is useless if nobody ever checked the expiration date. (And if you go check the office extinguisher after reading this, I won't judge.)

A 15-minute checklist for today

If you want to walk away from this post with something practical, set aside a little time and answer:

• What are the 3 systems your company can't run without? (Usually: sales, finance and customer service.)
• Where is the data for each one? With which provider and in which region?
• Is there a copy outside that location? How often is it made?
• Who in the company knows how to restore that copy? Does that person still work there?
• When was the last time someone tested it?

If any answer is "I don't know," that's already worth a conversation. Not out of panic. Out of good management.

The AWS case is extreme, of course. War isn't an everyday risk for most Brazilian businesses. But the logic is the same for a flood, a ransomware attack, a vendor that shuts down or an intern with too many permissions. The event changes, the question stays the same: if everything disappears, where do you pull it back from?

This is exactly the middle ground I work in. I take the systems a company already uses and build the automations that make copies, check them and alert you when something is off, without needing a whole IT team for it. If you want to see how that would look in your business, come learn a bit more about my work.

AWS admitted that some customer data is never coming back.

The biggest cloud in the world had buildings hit by attacks in the Middle East. Customers who kept everything in a single region had nowhere to pull a copy from.

The lesson applies to any company. The cloud takes care of the infrastructure, but your data is your responsibility.

The 3-2-1 rule: 3 copies, 2 types of storage, 1 outside the main location.

And a backup that has never been restored isn't a backup. It's faith.

If everything disappeared tomorrow, would you know where to pull it back from? If not, let's talk.

#Backup #CloudComputing #InformationSecurity #RiskManagement #Automation