Beget hosting outage: how we moved our site in an hour

On November 2, 2026, Beget, one of the largest hosting providers in Russia, was hit by a cyberattack. According to the company, the attackers gained access to the management layer of its entire infrastructure and ran scripts that wiped data. Websites, virtual servers, DNS, email and the control panel went down at the same time, and all data in Beget’s cloud was lost. You can’t prevent an outage on your provider’s side, but you can make it cost an hour of work instead of weeks of downtime: keep independent copies of your code, content and database, don’t keep your domain, DNS and website with one provider, and be able to rebuild a server from a script.

Our own website, itelmen.ru, ran on Beget’s infrastructure. Below is what happened, how we moved, and what we recommend doing before it happens to you. We update this article as new confirmed information comes in.

What happened at Beget

The outage started on the night of November 2, at around 3 a.m. Moscow time. Beget’s official statements and industry coverage agree on the following:

• Cause. Beget reported a cyberattack in which the attackers gained access to the management layer of the whole architecture and then launched data-wiping scripts. The company is not disclosing details while the investigation is ongoing.
• Scale. Beget says it has around 200,000 customers. Shared hosting, cloud servers, DNS, email and the control panel were all unavailable. Recovery requires a manual check of more than 1,000 servers for hidden vulnerabilities and malicious scripts.
• Cloud. All data in the cloud infrastructure (VPS, S3, Kubernetes) was lost, including full VPS images, CDN settings and IP addresses. File-level VPS backups survived, but customers can’t access them yet.
• Shared hosting. Beget’s preliminary estimate is that almost 100% of shared hosting sites can be restored, but every server is checked by hand before it goes back online, which takes time.
• Data access. Beget says it sees no attempts to download or modify data on servers that held customer data, but still recommends changing every password, key and credential stored on its servers.
• Force majeure. The company formally notified customers of force majeure under Russian civil law, which releases it from liability for the downtime. Don’t expect SLA credits.

Timeline

• November 2, night. Websites, VPS, DNS servers and the Beget control panel stop responding.
• November 2, around 2 p.m. Beget brings back self-managed dedicated servers. During the day it announces the cyberattack and force majeure.
• November 2, late evening. Beget’s DNS servers start answering again, and customer domains resolve to their old addresses.
• November 3. Beget publishes its account of the attack. Customers can edit A, MX and TXT records again for .ru, .рф and .su domains, and the Russian domain registry agrees not to suspend domains whose registration is expiring.

How we moved in an hour

itelmen.ru is built on headless WordPress: the CMS only stores content, and a separate Nuxt application serves the pages. The application ran on a Beget cloud server, and the CMS on Beget shared hosting. The cloud server was wiped along with the rest of the cloud. We lost nothing with it, because there was nothing on that server we didn’t already have in our own copies.

• Code lives in a Git repository, outside the hosting provider.
• Content. We back up all CMS content on a regular schedule: services, case studies, articles, pages, menus and settings in both languages. The site can build straight from this copy without calling the CMS at all.
• Media. The originals of every image are stored with the code.
• The server is defined in scripts. Packages, firewall, nginx, the SSL certificate and deployment are all set up by commands, not by hand from memory.

Going from a blank Ubuntu server to a live site on HTTPS took less than an hour. We didn’t need a database dump. Even if the CMS database had been lost for good, we would have installed a fresh WordPress and loaded the content from the same copy with our standard import. That is also about an hour of work.

The server is only half of it. To get visitors to a new server, you have to repoint the domain, and that needs working DNS. If the same host runs both your site and your DNS zone, the switch waits until the host restores DNS, no matter how ready the new server is. That’s why your domain and DNS belong somewhere other than your hosting.

Why everything failed at once

Most small businesses keep everything with one provider: domain registration, DNS, website hosting, the database, email and backups. It’s convenient as long as the provider is up. When it goes down completely, everything goes down with it, and the customer has nothing left to pull. You can’t move the site because DNS is managed from the same dead control panel. You can’t restore a backup because it lives in the same infrastructure. Email is silent, so customers can’t even reach you.

The same pattern has hit much larger players:

• Dyn, October 2016. A DDoS attack by the Mirai botnet on a DNS provider made Twitter, GitHub, Netflix and Reddit unreachable for hours. The sites themselves were up, but browsers couldn’t find their addresses.
• OVHcloud, March 2021. A fire at a data center in Strasbourg. Some customers lost their data for good because their backups were stored at the same site.
• Fastly, June 2021. A single customer’s configuration change triggered a bug in the CDN provider’s software, and Amazon, Reddit, The New York Times and GOV.UK returned errors for about an hour. Sites that relied on one CDN had nowhere to fail over.
• Rackspace, December 2022. A ransomware attack on its Hosted Exchange email service. The service was never restored, and some customers lost their mailboxes.

The takeaway is the same in every case: an independent copy and the ability to reroute traffic quickly matter more than the reliability of any single provider.

Hosting setups and what a full provider outage does to them

How to reduce the risk: a checklist

• Domain with a separate registrar. If your registrar and your host are the same company, an outage there also takes away your ability to change the domain’s nameservers.
• Nameservers with an independent DNS provider. This is the main protection against an outage like Beget’s. If your host doesn’t run your DNS zone, the domain keeps resolving while the host is down, and pointing the A record to a new server takes minutes. Even better, list nameservers from two different providers (secondary DNS), so visitors won’t notice if one of them fails.
• Set up nameservers in advance. You can change nameservers at the registrar during an outage if its panel works, but new nameservers take anywhere from a few hours to a day to propagate, because resolvers cache the old ones. During an incident, only an A record with a short TTL changes quickly.
• Email away from your web host. Business email on its own service keeps working even when the site is down.
• Backups off the host, database included. Your host’s own backups live in its infrastructure and can disappear with it. For a CMS site, files without the database are usually not enough to restore it.
• A copy of your content in version control. A regular CMS content export lets you deploy the site anywhere, even without the database.
• Infrastructure as code. A setup and deploy script turns a migration from a multi-day project into a routine operation.
• Restore drills. Once a quarter, deploy the site from your copies to a test server. A backup you have never restored from is not a backup.
• Rotate credentials after a host breach. CMS and database passwords, API keys, bot tokens, secrets in environment variables. Don’t bring a compromised server back as is; rebuild it from scratch.
• Short TTLs on critical records. If an A record has a TTL of several hours, switching to a new server also takes several hours to propagate.

What we recommend

The rule is simple: if a day of downtime costs you leads or sales, this is the minimum. Domain and DNS not with your host, email on a separate service, daily file and database backups to independent storage, and a tested migration plan. It’s a few hours of setup and a small monthly fee, and in the next major outage you’ll be fixing the problem yourself instead of refreshing your provider’s status page.

If your site runs on WordPress and the business depends on it, consider headless WordPress websites: with this architecture the site doesn’t depend on the CMS being up and can run from a content copy. Backups, monitoring and a recovery plan can be set up as part of support and maintenance, and if you need to leave an unreliable host, see performance and migration.