Yandex data center shut down: your cloud says run your DR plan

A cloud provider just told its customers to run their own disaster recovery plan. On Sunday, Yandex said a drone attack had damaged its infrastructure and caused the complete shutdown of its data center in Russia's Vladimir region. Its service alert said operations there were "completely suspended" and advised users to activate their disaster-recovery plans. It was the third Yandex data center hit in about four days. The geopolitics are not our department. The disaster recovery lesson is, and it applies to every business that runs on someone else's cloud.

What actually happened

The facts come from Yandex's statements as reported by Al Jazeera and The Moscow Times, both citing Reuters:

• Thursday, Oct. 8: An attack shut down Yandex's data hub in Sasovo, southeast of Moscow. It houses two of the three supercomputers Yandex uses to develop its AI model.
• Friday, Oct. 9: Yandex said its Kaluga-region data center, southwest of Moscow, was struck and partly put out of action.
• Sunday, Oct. 11: The Vladimir data center was fully shut down. No one was injured. Some Yandex services were unavailable, and the company did not say when repairs would finish.

Per Al Jazeera, Yandex's alert said the platform was running in emergency mode, that "the remaining resource configuration is considered unstable," and that technical support could also be disrupted.

Why it matters for your business

Read that alert again. The provider did not say "we've got it." It said: activate your plan, our remaining capacity is unstable, and support may not answer. That is the shared responsibility model with the marketing removed. The cloud provider owns the building. You own your recovery.

Most small businesses do not have a war risk. They do have fire, floods, power failures, a bad config push and an account suspension. Each one ends the same way: a region, zone or account is gone, and the question is what you have outside it. We covered the same pattern when AWS said Bahrain data was unrecoverable. Three Yandex sites in four days shows a second point: nearby sites can fail together.

What a real plan looks like for a small team:

• Backups in a second region, ideally a second provider. Database dumps and object storage copied out on a schedule, not just snapshots in the same account.
• A written restore runbook. Which DNS records change, which env vars move, who does it.
• A tested restore. Restore to a fresh environment once a quarter and time it. An untested backup is a hope.
• Infrastructure as code. If your stack lives in Terraform or a deploy script, rebuilding elsewhere takes hours, not weeks.

Sources: Al Jazeera, The Moscow Times.