Impacts of the Attacks on Yandex Data Centers and the Recovery Process
Immediately following the attacks, Yandex engineers implemented a systematic recovery plan to restore services. The priority was repairing the access layer; this was followed by integrity checks, damage detection, and identification of intact data copies in the storage infrastructure. As a result of the audits, access was restored to 97.16% of customer data; the remaining 2.84% could not be recovered due to physical damage and lack of backups. The recovery process was accelerated by the simultaneous execution of capacity-based personnel deployment, automated verification tools, and manual logical checks.
Which data was recovered and which data was lost?
Recovered data includes disk images, database backups, and user files in virtual machines. The unrecoverable 2.84% was directly linked to physically damaged storage units; logical recovery methods were unsuccessful because data blocks in these units were physically corrupted. For example, fire damage and erosion on the control unit detected in the Sasovo rack resulted in the permanent loss of disk clusters in that rack. Recovery teams first restored the most recent backups on intact media, then verified data integrity with consistency and reference logs.
Backup services: who wasn’t affected and why
Customers using Yandex Cloud backup services did not experience data loss because backups were copied to multiple independent locations using a combination of snapshots, incremental backups, and regional replication. This architecture made it possible to recover quickly even when the main production area was damaged. Example: when a VM is accidentally deleted, the relevant snapshot can be selected from the control panel and the VM can be recreated to its original state within 10–15 minutes. During this process, automatic inventory, IP reassignment, and DNS updates were coordinated in the background.
Default backup setting and user controls
The company has enabled backup by default on newly created virtual machines to provide stronger protection; existing users can manually change this setting. Technical implementation: The “Snapshot & Backup” option is pre-selected in the VM creation workflow; users can specify one-time or policy-based (daily/weekly) storage options. This change reduced human error-related oversights and expanded the backup cover.
Infrastructure deployment, new measures and technical details
Yandex continues to distribute its resources to independent data centers in different regions of Russia and increase the number of centers. The aim is to prevent a single physical attack from causing widespread service disruption. The technical measures taken include: geo-redundancy with block-level replication, SMART and telemetry expansion for more frequent hardware health scans, dual power supplies and regional power/cooling independence. In addition, physical isolation measures such as melt-condensed cooling insulation for critical storage were evaluated.
Chronology of the event and affected regions
During the drone attacks that took place between October 8–11, the Sasovo data center in Ryazan and three data centers in the Kaluga and Vladimir regions were damaged. The direct impact of the attack manifested as access problems and delays in Yandex Cloud services and the Yandex Disk platform; some customers reported short-term outages. Recovery took several days and involved intensive repair, reconstruction, and automated and manual data verification steps.
Possible risks and recommended reconstruction steps
Risks other than irreversible losses from physical damage: incomplete implementation of backup policies, reliance on a single region, and failure to ensure the currency of backups. Steps recommended by Yandex:
1. Create a replicated backup policy: Take regular snapshots of critical data to at least two independent geographic locations; adjust retention periods according to business requirements.
2. Conduct backup tests: Verify recovery point and duration objectives (RPO/RTO) with periodic restore drills; document test results.
3. Review SLA and disaster recovery plan: Define RTO and RPO values according to your business continuity goals, and include clear clauses in contracts.
4. Ensure hardware redundancy: Create dual power supplies, separate cooling zones, RAID configurations, and vendor support contracts for critical components.
Step-by-step preparation guide
Step 1 — Prioritization: Classify databases, business applications, and customer files according to their criticality level; determine acceptable RTO/RPO for each level.
Step 2 — Backup configuration: Determine the snapshot frequency and retention period for each critical component. Example configuration: daily incremental snapshot + weekly full backup + 30-day archive.
Step 3 — Replication strategy: Establish simultaneous replication across at least two different geographic regions; define automated failover policies and integrate DNS and IP reassignment processes.
Step 4 — Regular testing: Conduct a recovery drill every quarter; validate procedures and automations using production-like scenarios.
Step 5 — Monitoring and alerts: Set up automated alerts for hardware health, backup success rate, and delays; define escalation procedures for failed snapshots.
Transparent communication and customer support
Yandex shared with customers which centers were affected, the percentage of data recovered, and the reasons for remaining losses. Affected customers were assigned direct support teams and given priority in the backup and restore processes. This type of rapid, structured communication both accelerated technical coordination and shortened the customer’s operational turnaround time.
Example: Customer restoration process
An e-commerce customer did not experience data loss thanks to a daily snapshot policy and regional replication. There was a brief outage in the main region at the time of the incident; the customer recovered transaction traffic within 12 minutes by performing a failover from the replica via their control panel. Then, teams performed consistent data validation in the background, compared transaction logs, and continued to monitor the customer experience.
Conclusion and priority steps
This incident demonstrated that physical attacks can create data risks even in cloud infrastructure; it also proved that strong backup and geographical distribution strategies can significantly reduce data loss. Priority actions: enable default backup, perform periodic restore tests, and eliminate a single point of failure by geographically distributing the infrastructure. In addition, frequently reviewing the backup design and implementing improvements based on test results minimizes the impact of similar incidents.
Be the first to comment