Two hosting providers hit in one week: How far are your backups from your provider's control plane?

Last week two Russian hosting providers were hit by serious attacks within days of each other. Since it happened in Russia, it can feel like someone else's problem. It isn't really about geopolitics, though. It's about architecture: what does a customer have left when the system that runs the infrastructure is itself compromised? That question applies to any team running on a local VPS provider, on Hetzner, or on one of the hyperscalers.

What happened

Beget: wiped through the control plane

Beget, one of Russia's largest hosting companies, was attacked on the night of November 2. According to its updates to customers, the attackers reached the management layer of its infrastructure and ran scripts that zeroed out data. Beget said binary backups of its virtual servers were completely lost. On November 6 it announced that its cloud infrastructure, covering VPS, S3 and Kubernetes, had been destroyed and was being rebuilt from scratch.

The company does have file-level backups, but by its own estimate they cover only about half of VPS customers. On the shared hosting side, more than 60% of servers were running again as of November 6. No date was given for full recovery, and Beget has not said how the attackers got in.

ESTT: ransomware in the virtualization clusters

A few days later, on November 8, it was ESTT's turn. The company says preliminary findings point to file-encrypting ransomware that hit its virtualization clusters and cloud management systems. One detail stands out: customers' physical dedicated servers were not affected. By the next day ESTT said about 90% of virtual servers were back, although the customer panel and balance top-ups were still down. The company says it has found no sign that customer data was leaked.

Why this matters

We tend to think about cloud and hosting outages in physical terms: hardware failure, power, a data center fire. Disaster recovery plans follow that model, with another zone, another region, another facility. These two incidents show a different scenario. The problem wasn't one data center. It was the software that manages all of them.

Once the control plane is compromised, regional separation stops meaning much. If the same API and the same tooling can reach every resource, so can an attacker. The provider's built-in snapshot and backup features usually live in that same management layer too. Beget losing its VPS backups along with everything else is exactly that failure mode.

The ESTT detail is instructive as well. When the virtualization layer was hit, the bare-metal servers kept running. That doesn't mean dedicated hardware is always safer, but it's a reminder that the more you depend on a shared management layer, the more a problem in that layer hits you.

What to do in practice

The takeaway isn't to switch providers. It's to design on the assumption that any provider, big or small, could one day have an incident like this. A few concrete steps:

1. Keep at least one backup copy with a different provider

Another region with the same provider protects you from that provider's ordinary failures. It doesn't protect you from its management system being compromised. At least one copy of your critical data should live with a different company, behind different credentials. The off-site part of the classic 3-2-1 rule should now read off-provider.

2. Make backups undeletable

Use object lock (WORM) or an append-only mode on your backup target, so that even if a production key leaks, nobody can delete or overwrite older backups with it. With tools like Restic or Borg, give the machine that creates backups write-only access, and run deletion and pruning from a separate, privileged place.

# Example: keep the Restic repository in an S3-compatible bucket at another provider
export RESTIC_REPOSITORY=s3:https://other-provider.example.com/backup-bucket
restic backup /var/lib/postgresql-dump /etc --tag daily
# Object lock is enabled on the bucket; this server's key cannot delete

3. Don't count provider snapshots as backups

The one-click snapshot in your VPS panel is a handy rollback tool after a bad upgrade. It is not a backup when the provider itself is the one in trouble. Keep snapshots and application-level backups (database dumps, file backups) as separate things.

4. Be able to rebuild

Sometimes, as Beget found, you have to rebuild everything. If your server setup is captured in Terraform/OpenTofu, Ansible, or at least well-documented scripts, standing it up somewhere else takes hours rather than weeks. A hand-built server that nobody fully remembers is the weakest link.

5. Don't put DNS and secrets in the same basket

Beget's first priority was bringing its NS servers back. If your domain's DNS is hosted by the same company that hosts your site, you lose the ability to redirect traffic when that company goes down. Beget also advised customers to rotate any passwords and access keys stored on their servers. Keeping an inventory of the API keys sitting in plain text on your machines tells you what to rotate on a day like that.

6. Actually test restores

An untested backup is a hope. Once a quarter, spin up an empty environment at another provider from your backups and check that the application actually comes up. It's the most boring item on this list and the most valuable.

Final thoughts

We still don't know who was behind these attacks or how they got in, so it's too early for a technical root-cause analysis. But the picture from the customer side is clear enough: the provider's management layer is a single point of failure. Hyperscalers invest heavily in protecting it, while smaller companies may have fewer resources to do the same. Whoever you use, it's worth asking yourself this week: if my provider lost everything tomorrow morning, which copy of my data sits somewhere it can't reach?