Yandex Cloud lost 2.84% of customer data after data center fires: there were no backups

Every engineer has heard some version of “it's in the cloud, it won't disappear.” October 2026 showed what that confidence is worth. Yandex said it could not recover 2.84% of customer data on the Yandex Cloud platform after fires at its data centers.

What we actually know

According to the company's press office, recovering this data is impossible for two reasons: the hardware suffered critical damage, and there were no backups of that information on the platform. The combination is what matters. A data center fire is, in itself, a disaster the industry knows how to withstand. Data disappears when the only copy was stored in the same place that burned down.

In response, Yandex plans to enable backups by default. The announcement provides no further details: it is unclear how many customers were affected or exactly which services lost data. The figure of 2.84% sounds modest, but for an individual company it could mean 100% of its database if that database fell within the affected share.

Why “by default” matters most here

Imagine an online store with its order database on a single cloud disk. As long as everything works, there is no problem. Then the rack burns down, disk and all. If there is no copy in another availability zone or in separate storage, the orders are gone. This is an illustration, not an analysis of an actual case: we do not know which services were affected.

Backups that require manual activation often stay disabled. Some people cut costs, some forget, and others assume the provider handles it automatically. This is a classic gap in responsibility: the customer believes the cloud is responsible for keeping data safe, while the cloud provider expects the customer to configure backups. Enabling them “by default” closes that gap for people who have not read the documentation carefully.

What developers, product managers, and founders should do

Do not wait for your provider to change its settings. Check your infrastructure today:

• List all your storage systems: databases, object storage, and virtual machine disks. Flag those without backups.
• Follow the 3-2-1 rule: three copies of your data, on two types of media, with one copy stored elsewhere. Ideally, in another availability zone or with another provider.
• Test recovery. A backup you have never restored remains a hypothesis, not protection.
• Document your acceptable data loss (RPO) and recovery time (RTO). Without these numbers, a discussion about backups becomes a discussion about hopes.
• Read the shared responsibility section in the documentation and your contract. A service availability SLA is not a guarantee that your data will be preserved.

Product managers should add data loss to the risk register and compare the cost of backups with the cost of losing data. Founders should ask their technical team one question: “How much of our data exists in only one copy?” If the answer is confident and comes with a list, things are in order. If there is a pause, you have work to do.

Limitations and caveats

For now, this is a brief company statement, not a detailed postmortem. We do not know how many customers were affected, what caused the fires, or the terms of any possible compensation. Backups enabled by default are no cure-all either: a copy stored in the same data center will burn along with the original. After enabling backups, therefore, check where the copies are physically stored and whether you can quickly restore your service from them.

The takeaway is simple. The cloud frees you from managing hardware, but not from responsibility for your data. If you do not have a working, tested copy elsewhere, assume you have no backup at all.