Yandex Cloud Recovered 97.16% of Data After Attacks on Its Data Centers, and Backups Are Now On by Default

There are things everyone knows and still put off until later. Backups are the prime example. The latest story from Yandex Cloud shows the price of that "later" well: after the attacks on its data centers, the company said how much client data it managed to save and how much it did not.

What happened and the numbers

According to information published with reference to Interfax, Yandex Cloud restored access to 97.16% of client data. This happened despite critical damage to equipment, meaning this was not a brief outage but physical harm to the infrastructure.

The remaining 2.84% could not be recovered. There were two reasons, and they worked together: the hardware that held the data was critically damaged, and the owners of that data had no backups of their own on the platform.

If a client had backups enabled, 100% of data was preserved. This is the key figure of the whole story. It shows that hardware fails for everyone, and what saves data is the settings the client configured in advance.

For context: AWS recently acknowledged that, after strikes on infrastructure in Bahrain and the UAE, some data and resources at the affected sites could not be restored. So physical risks for large clouds are very real, not exotic.

What is changing in the product

Yandex is taking a simple and sensible step: when new virtual machines are created, backups will now be enabled by default. Previously they had to be turned on manually, and many people did not do so.

Opting out is possible, and the terms of the service have not changed. This is a classic product design technique: the safe option becomes the default, while the conscious decision to take a risk remains with the user. Most people do not change defaults, so the share of unprotected machines in new projects should drop noticeably.

At the same time, engineers continue to distribute computing resources across new independent locations in different regions of Russia. The publication gives no details on timing or design, so it is too early to judge how much this will change fault tolerance.

What developers and founders should do

The lesson here is down to earth, with no grand conclusions.

• Check whether backups are enabled. Especially on virtual machines created before the change. The new default does not apply to them, and the publication says nothing about older machines.
• Do not confuse cloud fault tolerance with a backup. A cloud may promise availability, but the physical destruction of a site shows the difference: without a separate copy, the data stays on the same hardware.
• Think about where the copy is stored. The publication does not specify where client backups are kept, but the logic is simple: a copy located next to the original risks being damaged along with it in a serious accident. It is worth reading the provider's documentation and finding out whether the copy is stored in a different location.
• Test restoration. A backup from which you have never tried to bring up a system remains a hypothesis.
• Build this into your product. If you are building a service on top of a cloud, your SLA and architecture should include explicit targets: how much data you are prepared to lose and how quickly you must be back up.

Limitations

All figures come from the company itself and are relayed in the publication. There is no independent audit, and it is unknown which share of clients and which types of data fell into the 2.84%. There are also no details about the attacks or the scale of the damage. So one should not conclude that one provider is more reliable than another. The comparison with AWS in the post is more emotional than rigorous: the incidents differ, and there is no data for a direct comparison.

Nevertheless, the main takeaway is not weakened by this. Even with severe physical damage, 97.16% of data was recovered, and among those who had backups, there were no losses at all. A backup costs little compared with losing data, and now you do not even have to enable it manually if you are creating new machines.