The Beget Cyberattack Data Loss: Why Half of Customers Won't Get a Backup

The Beget cyberattack data loss is the story of a Russian hosting provider that lost all data in its VPS, S3, and Kubernetes cloud infrastructure after attackers compromised its management plane overnight on November 1-2, 2026. By a November 6 update, the news had gotten worse: according to comss.ru's reporting, Beget now says file-level VPS backups, the one category it had initially said survived, will only be recoverable for about half of affected customers.

Jump to the estimate that got worse, not better if you want that detail first.

What Attackers Actually Did

Tadviser's incident record states plainly that "attackers gained access to the system managing the entire architecture and executed scripts that wiped the data." This is a management-plane compromise, not a ransomware encryption event or a data-exfiltration breach. The attacker's goal, as far as Beget's own disclosures describe it, was destruction: once inside the control system that manages Beget's infrastructure, the intrusion deleted data rather than encrypting it for ransom or quietly copying it out.

The destruction was total within the cloud segment specifically. All data in VPS, S3, and Kubernetes was lost, according to Beget's own Telegram announcement as translated and reported by iz.ru, along with CDN configuration and IP address settings. Binary VPS backups, full disk images that would have let customers restore a server to its exact prior state, were destroyed completely. Beget said at the time that file-level backups, individual files rather than whole-disk images, had survived.

The Estimate That Got Worse, Not Better

That survival claim didn't hold up as cleanly as first reported, however. Beget's November 6 update, per comss.ru, revised the file-backup recovery estimate downward: "по актуальной оценке компании, файловые резервные копии будут доступны только половине пользователей," meaning the company's current assessment is that file backups will be available to only half of users, not the near-complete recovery implied by its earlier messaging.

Even where a backup copy does exist, comss.ru reports that each one has to be manually matched to its specific customer and all of that customer's associated data, a process the company describes as time-consuming rather than automated. For some clients, Beget's own internal records linking an account to its services were also lost, meaning those associations can't simply be restored; they have to be reconstructed from scratch.

What's Actually Recovering, and What's a Harder Rebuild

The recovery picture Beget has published is uneven by design, not by accident, and the unevenness tracks directly to how centralized each affected system was. Dedicated servers that customers administer themselves were restored quickly, within roughly a day, because Beget's own infrastructure compromise never touched systems the customer, not Beget, controls. DNS management for domains in the .ru, .рф, and .su zones came back next. Virtual hosting, ordinary websites rather than VPS instances, was reported by comss.ru as more than 60% restored by November 5-6, with the remainder dependent on backup restoration rather than a simple server restart.

Social-media monitoring firm Dark Web Intelligence's recovery update, citing Beget's own November 5 status report, lists 60% of shared-hosting servers back online (up from 35% the day before), 40% of managed dedicated servers restored, and billing paused entirely while the affected categories of service remain unrestored. The same post adds an important qualifier: "figures and timelines are Beget's own estimates, not guarantees," and notes that ransomware has not been established as the mechanism, consistent with Beget's own description of deletion scripts following management-plane access rather than an encryption payload.

VPS, S3, and Kubernetes remain the hardest case, because those are precisely the systems where the deleted binary backups would have mattered most, and where the newly revised 50% file-backup recovery rate leaves the other half of affected customers dependent entirely on whatever backups they kept outside Beget's own infrastructure.

What This Means If You Run Production Workloads on Any Hosting Provider

Our verdict: this isn't a story about one provider having bad luck. It's a demonstration of what a single compromised management plane can cost when the backup and production data paths both run through the same control surface, and of how easily a "backups survived" early announcement can be revised downward once the actual, server-by-server recovery process is underway.

• Keep a backup that lives outside your hosting provider's own management plane, not just stored in a different "zone" or "region" the same provider controls. Beget's own file-level backups, the one category it initially described as intact, are now only confirmed recoverable for half of affected customers precisely because they ultimately depended on the same compromised infrastructure.
• Treat "backups preserved" announcements made in the first 24-48 hours of an incident as provisional, not final. Beget's own estimate moved from near-complete virtual-hosting recovery to a 50% file-backup figure for cloud customers over the course of four days, a meaningful downward revision once engineers were actually matching copies to accounts rather than describing the backup state in general terms.
• Understand the difference between your dedicated infrastructure and your provider's shared management plane. Beget's customer-administered dedicated servers were untouched and restored within a day; everything routed through Beget's own centrally managed control system took the full brunt of the attack. If a provider's compromise can reach everything it manages at once, that's the actual blast radius to plan backups against, not the blast radius of any single server.

FAQ

What data did Beget lose in the cyberattack?

Beget lost all data in its VPS (virtual private server), S3 object storage, and Kubernetes cloud infrastructure, along with CDN configuration and IP address settings, after attackers compromised its management plane and ran data-wiping scripts overnight on November 1-2, 2026. Binary VPS backups were destroyed entirely; file-level backups initially appeared to have survived.

Will Beget customers get their data back?

It depends on the service. Virtual hosting (ordinary websites) was reported more than 60% restored by November 5-6 and is expected to largely recover through existing file backups. For VPS, S3, and Kubernetes customers specifically, Beget's November 6 update stated that file-level backups will only be recoverable for approximately half of affected users; binary VPS backups are a total loss with no stated recovery path.

Was this a ransomware attack?

Beget has not confirmed ransomware, and outside analysts tracking the incident have noted that no ransomware mechanism has been established. Beget's own account describes attackers gaining access to its management plane and running deletion scripts, consistent with a destructive wipe rather than an encryption-for-ransom event.

What We Checked Before Publishing

We cross-referenced Beget's own Telegram disclosures as translated and reported by Tadviser and iz.ru against comss.ru's more detailed November 6 recovery update and Dark Web Intelligence's independent tracking of Beget's November 5 status report. Figures throughout this piece, including the 60% and 50% recovery rates, are Beget's own self-reported estimates rather than independently audited numbers, and we've flagged that distinction rather than presenting them as confirmed facts.

I'm Rohit, founder of Krova Cloud: no single compromised credential or control-plane bug should be able to reach every customer's VPS, object storage, and backups at once. That's an architecture decision, not a promise that any system is unbreachable, but a management plane that can delete everything it manages is a specific, identifiable risk, and this incident shows exactly what it costs when it goes wrong. More debugging stories at debugly.dev.

Structured Data

{ "@context": "https://schema.org", "@graph": [ { "@type": "BlogPosting", "headline": "A Hosting Provider Lost Its Entire Cloud, and Half Its Customers Won't Get a Backup", "datePublished": "2026-11-07", "dateModified": "2026-11-07", "author": { "@type": "Person", "name": "Rohit" }, "about": ["Beget cyberattack", "hosting provider data loss", "cloud infrastructure security", "management plane compromise"] }, { "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "What data did Beget lose in the cyberattack?", "acceptedAnswer": { "@type": "Answer", "text": "Beget lost all data in its VPS (virtual private server), S3 object storage, and Kubernetes cloud infrastructure, along with CDN configuration and IP address settings, after attackers compromised its management plane and ran data-wiping scripts overnight on November 1-2, 2026. Binary VPS backups were destroyed entirely; file-level backups initially appeared to have survived." } }, { "@type": "Question", "name": "Will Beget customers get their data back?", "acceptedAnswer": { "@type": "Answer", "text": "It depends on the service. Virtual hosting (ordinary websites) was reported more than 60% restored by November 5-6 and is expected to largely recover through existing file backups. For VPS, S3, and Kubernetes customers specifically, Beget's November 6 update stated that file-level backups will only be recoverable for approximately half of affected users; binary VPS backups are a total loss with no stated recovery path." } }, { "@type": "Question", "name": "Was this a ransomware attack?", "acceptedAnswer": { "@type": "Answer", "text": "Beget has not confirmed ransomware, and outside analysts tracking the incident have noted that no ransomware mechanism has been established. Beget's own account describes attackers gaining access to its management plane and running deletion scripts, consistent with a destructive wipe rather than an encryption-for-ransom event." } } ] } ] }