Your Hosting Provider Held to Ransom: The Backup Rule Every Small Business Needs

On 7 October 2026, ransomware struck IDCF Cloud, the cloud hosting provider run by SoftBank group company IDC Frontier. Within a day, nearly 500 businesses and local authorities had been told the same uncomfortable thing: their data could probably only be recovered from backups they held themselves. Some of them had copies. Plenty did not. If you pay someone to host your website, this is the month to ask a plain question: if my hosting provider's own systems went down tonight, where is my backup?

What happened at IDCF Cloud

The attack began at about 03:40 Japan time on 7 October 2026 and hit the East Japan Region 1 area of IDCF Cloud. IDC Frontier took that region off the network and switched off its customer management console everywhere while it checked the rest. On 8 October the company said four data centre zones were damaged so badly that customers should rebuild their systems somewhere else, and that recovery would only be possible from backup data held by the customer themselves.

A week later, on 14 October, the picture softened slightly. Of the 495 companies and councils affected, the 194 that had used the provider's own saved copies, known as snapshots, could ask for those back. The other 301 were pointed at their own backups. The attackers claimed to have wiped more than half a million backup snapshots in seven minutes; that figure has not been independently confirmed, and the company says it found no sign that customer files were copied out. Either way, a lot of people waited a week to find out whether the safety net they had been paying for still existed.

Why a backup inside your hosting account is not a plan

Here is the trap. A spare copy stored by the same company, in the same data centre, under the same account is not really two copies. It is one copy with extra steps. When the incident hits the machinery itself, both copies go together. When the provider locks the control panel while it investigates, as IDC Frontier did, you can reach neither of them. And when the only person who can start a restore is the provider currently dealing with its own emergency, your recovery sits behind everybody else's.

None of this makes hosting providers villains. It simply describes where your copies live and whose hands are on them. A sensible setup assumes your host is having the worst day of its year.

The 3-2-1 backup rule, in plain English

The rule that has protected businesses for decades survives every change in technology because it is almost embarrassingly simple: keep three copies of your data, on two different kinds of place, with one copy sitting outside your hosting provider's control.

For a small business website that translates into an afternoon's work. Your live site is copy one. A download to your office computer or an external drive is copy two. Copy three lives in a separate cloud account, or with a host that stores its snapshots in a different region from the one serving your pages. Then add the step people skip and anyone who has ever recovered a site asks about first: restore from that third copy, and time it. A backup you have never opened is a rumour about a backup.

What the Ubuntu attack shows about keeping things apart

A few days after the IDCF Cloud attack, on 8 October 2026, Canonical's websites including ubuntu.com were hit by a sustained denial-of-service attack, where floods of fake traffic knock a site offline, and stayed down for four hours and twelve minutes. The interesting part is what kept working. The software repositories, the download servers, the software store and sign-in services all ran as normal, because those systems sit on their own infrastructure rather than behind the public websites.

One layer fell, the rest held, and the damage stayed where it started. That is exactly the habit a backup is for. Keep the spare copies where the live-site incident cannot reach them, and an outage becomes an afternoon's work instead of a rebuild.

A five-minute check on your own site

Sit down this week and answer five questions in writing. Where exactly is your most recent website backup? How old is it? Who holds it, you or your hosting provider alone? When did you last restore from it? Does it happen automatically, or does somebody have to remember? If any answer is vague, that is your project for the next few days, and it is the sort of gap our monthly maintenance checklist is designed to catch.

What a good setup looks like

Automated copies taken daily, stored away from the account that serves your site, with a restore route written in plain English and tested on a schedule. That is the standard to hold any host to, and it is how our AI Managed Hosting is built: snapshots kept separate from your live pages, a clear answer to the question of where your data sits, and help the moment you need the site back. If your current site makes any of that impossible, our switching service moves it over without downtime, and a look at the packages page shows what suits a business your size. For the wider picture, our guide to static site security explains what else stays protected when there is no database for anyone to steal.

You do not need hourly backups. You need copies that exist, live somewhere your provider cannot switch off, and have been restored at least once. Set that up this week and a story like the one at IDC Frontier stays somebody else's problem.