Whose Backups Survived Japan’s Cloud Ransomware Attack

At 3:40 a.m. Japan time on October 7, ransomware stopped four zones of IDCF Cloud’s East Japan Region 1. By the following evening, the provider, SoftBank subsidiary IDC Frontier, was telling 495 affected companies and local governments that data in those zones would be difficult to retrieve or restore, and that recovery would depend on backups the customers held themselves.

That single line split the customer list in two. Organizations with a copy of their data somewhere outside the affected platform started rebuilding almost immediately. Organizations whose only copies lived inside the same environment began a much longer week.

A Snapshot on the Same Platform Shares the Same Fate

Cloud snapshots feel like insurance because they are easy to schedule and easy to restore when something small goes wrong. A deleted table or a botched deployment is exactly what they were built for. The IDCF incident tested a different scenario: the platform hosting the snapshots itself failed.

According to Japan Cyber Watch’s ongoing coverage of the incident, IDC Frontier’s final report said it could retrieve backup data for 206 of the 495 affected customers. That is a meaningful number, but it still leaves most customers having to recover from whatever they stored elsewhere. A copy that sits inside the same blast radius protects against human error. It offers far less protection against an attacker who reaches the infrastructure underneath.

The Responsibility Split Was Always in Writing

Every major cloud provider publishes some version of a shared responsibility model. The provider secures the facilities, the hypervisors, and the network. The customer owns its data, its configurations, and, in most service tiers, its backups. IDC Frontier’s own FAQ for IDCF Cloud states who is responsible for backups, and the answer is the customer.

Most teams have read that language at some point. Fewer have tested what it means in practice, because a regional failure severe enough to make provider-side recovery impossible has historically been rare. October’s incident moved that scenario from the theoretical column into the incident-report column.

Day-One Recovery Came From an Outside Copy

The clearest lesson in the coverage comes from the customers who recovered fastest. Publishing software company Six Apart, whose cloud edition ran servers in the affected region, kept its own copies outside IDCF Cloud and could begin restoring on day one. Its recovery path ran through a different provider entirely.

That outcome traces back to a decision made well before October: a copy of production data belonged in a place with a separate failure domain, separate credentials, and a separate operator. When the incident arrived, the team only had to execute an existing plan.

Delegating Infrastructure Still Requires Understanding It

Pablo Gerboles Parrilla, founder of Alive Devops, has spent years arguing that a company that outsources a function still carries the accountability for it. His view applies directly to how companies treat their cloud providers. “Founders shouldn’t just delegate; they should understand, then delegate with purpose,” Gerboles Parrilla said.

In infrastructure terms, understanding means knowing exactly where every critical dataset lives, how many copies exist, who controls the credentials for each copy, and how long a full restore actually takes. Many teams can answer the first question. The last one usually requires a test that nobody has scheduled.

Backup Testing Belongs on the Release Calendar

Teams that take recovery seriously treat restore drills like deployments: recurring, scheduled work with an owner and a measured outcome. The drill answers practical questions that a policy document cannot: whether the restored database is consistent, whether the application can reach it, whether the secrets and DNS records needed to bring a service back online exist outside the failed environment.

This kind of drill belongs inside cloud infrastructure management rather than beside it, because a recovery plan only becomes real once someone has walked through it under realistic conditions. Gerboles Parrilla makes the same case about security, which he says “should be baked into the pipeline, not added at the end.” Recovery belongs in that category too.

Independent Copies Are Within Reach for Small Teams

There was a time when a second, independent copy of production data meant a second data center and a budget only large enterprises could justify. That constraint has largely disappeared. Object storage from a different provider, immutable storage tiers that compromised credentials can’t alter, and automated cross-provider replication are now standard options with predictable costs.

The harder part is organizational. Someone has to own the decision, choose the separate failure domain, and keep the replication healthy as systems change. Lean teams can do this well precisely because fewer people need to agree before the work gets scheduled.

Rehearsing the Notice Before It Arrives

The IDCF attack will eventually fade from the headlines, and IDC Frontier’s final report, which traced the intrusion to an open-source flaw in its customer portal’s login system, holds its own lessons for providers. The lesson for customers is already available. Every company running production workloads in the cloud can ask one question now: if our provider sent the same notice IDC Frontier sent on October 8, where would we restore from, and how long would it take?

Teams that can answer both parts with confidence are in a strong position. Teams that cannot have just been handed a free rehearsal, courtesy of 495 organizations in Japan that didn’t get one.