Can Your Cloud Recovery Plan Actually Leave the Platform?
Disruption across three Yandex data-centre locations has left recovery work ongoing. For affected customers, the urgent question is whether critical workloads can run somewhere else before the provider finishes restoring services.
Yandex’s corporate notice separates three events. Its Sasovo site stopped operating after serious damage during the night of 7 to 8 October. Part of the Kaluga infrastructure failed after another attack on 9 October. The Vladimir site stopped operating after an attack during the night of 10 to 11 October. The notice was published on 9 October and revised on 11 October.
Yandex Cloud’s incident record still reported restricted operation and round-the-clock restoration at 19:04 GMT+2 on 15 October. That continues the unchanged status recorded at 18:44 GMT+2 on 13 October, without a reliable restoration time.
Separate, daily guidance covers individual services; operators should use it alongside the incident’s earlier advice to host and reserve resources elsewhere. The varying service updates are not proof of uniform impact across every workload.
The 13 October billing update makes Yandex Cloud services in Russian availability zones free for existing customers from 8 to 31 October, with automatic adjustment.
Recovery begins with a usable copy of state
A recovery environment depends first on state that cannot be recreated from code: databases, object stores, queues and persistent volumes. A recovery plan should identify the newest copy held outside the affected platform, its age, the keys needed to open it and the point after which transactions may require reconciliation.
A backup catalogue is evidence that copies exist, not that a service can use them. A representative restore into the alternative environment should be opened with the intended application identity and tested through a real business transaction. If that cannot be done, the dependency remains unproved and should be treated as a recovery risk.
The recovery controls must be reachable independently
Moving data is only part of the route. The team also needs access to break-glass identities, DNS, certificates, secrets, deployment artefacts, infrastructure definitions and incident contacts without relying on the affected provider. Capacity, network reachability and service quotas in the destination need to be known before a cutover starts.
Dependencies outside the obvious application stack can stop the move just as effectively as missing data. Image registries, build systems, licence servers, monitoring and outbound allowlists should therefore be tested from the recovery environment rather than assumed to be portable.
Cutover decides who may write
The safest cutover establishes one write authority. The original and restored systems should not accept conflicting changes, and the team should record the recovery point and transactions that may need reconciliation. Before moving user traffic, it should prove authentication, one critical workflow, monitoring and support access in the destination.
Traffic can then move in measured stages with a clear stop condition. The same decision record should define what must be true before workloads return or the temporary platform becomes permanent. A workable recovery route is demonstrated by current state, independent control and a controlled change of authority, not by the existence of backups alone.
Sources
- Yandex Cloud incident 2136, latest update 15 October 2026 at 19:04 GMT+2.
- Yandex data-centre notice, published 9 October and revised 11 October 2026.
