After strikes on Yandex data centers, especially on the night of October 11, some clients found their websites completely inaccessible. Large companies often store their site and all backups in one data center, so any incident causes total loss. One client avoided disaster because a mirror site had been prepared in advance on a server in a different data center, with daily updated backups that allowed full recovery within hours.
The article compiles practical steps that the authors apply to their own projects and now recommend to clients. In current conditions, preparing for data center outages is as essential as having a fire safety plan: invest one or two days once and reduce future stress significantly.
Core principle: separate critical elements across different companies. A website depends on five components: domain, DNS, hosting, email, and backups. When three or more reside with the same provider, a single failure disables everything, including recovery options. A common mistake is keeping DNS records with the same hoster or cloud where the site runs, so when hosting fails the DNS panel becomes unreachable too.
Basic checklist for any site
- Move DNS to an independent provider such as Timeweb, IHC, SpaceWeb or Beget, never the same company that hosts the site.
- Reduce A-record TTL to 300-600 seconds so changes propagate within minutes.
- Maintain a fully deployed and tested mirror site on separate hosting.
- Host corporate email with a different provider and keep local copies of messages.
- Download full local backups at least monthly.
- Configure availability monitoring with alerts via Telegram or SMS.
- Store all credentials in a password manager accessible to at least two people.
- Consider a CDN for static content resilience.
For virtual hosting, deploy a mirror at another provider in a different city, verify that the hoster’s own backups are stored off-site, and perform regular manual or automated exports. Synchronize the mirror after major content updates and test CMS compatibility (PHP, MySQL versions) in advance.
For VPS or dedicated servers, perform daily backups to another city, set up database replication, create monthly full server images, and document the exact failover procedure. Code may be stored abroad, but personal data must remain in Russia to comply with 152-FZ.
For Tilda and other constructors, export a static version to ordinary hosting, update it regularly, and prepare alternative contact forms because constructor forms may stop working during an outage.
Automation options include cron scripts, plugins such as UpdraftPlus for WordPress, or tools like restic and BorgBackup for VPS environments. Follow the 3-2-1 backup rule and test restores quarterly.
During an incident, first confirm the scope, decide on failover within one to two hours, switch the domain via independent DNS, notify clients, and later synchronize data before returning to the primary platform. If no mirror exists, request fresh backups immediately and engage specialists to minimize SEO and traffic losses.


