How to Prepare Your Website for Data Center Outages: Business Resilience Checklist
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.
Related articles
How to Properly Compare CDNs: TTFB, p95 Latency, Caching, DDoS Protection and True Pricing
Selecting a CDN based solely on the number of points of presence is as unreliable as choosing a car by dashboard buttons. Networks with dozens of global PoPs may underperform for audiences concentrated in Novosibirsk or Yekaterinburg, while smaller regional providers often deliver superior peering with Russian operators. The article evaluates CDNVideo, EdgeCenter, Curator, NGENIX and Yandex Cloud CDN across verifiable features, network design, caching behavior, security controls, operations and commercial models. Performance data is separated because marketing claims cannot substitute for independent measurements from services such as CDNMON. Emphasis is placed on p95 metrics, cache hit ratios, origin shielding, raw logs and API limits rather than marketing scores. The analysis shows that no single universal ranking exists; optimal choice depends on traffic profile, audience geography, security requirements and operational workflows.
Innostage Lab Benchmarks PT NGFW 1.10.3 Performance in Eight Load Scenarios
Innostage researchers conducted extensive performance testing of PT NGFW version 1.10.3, the certified release at the time of trials. The evaluation covered TCP connection setup rates, concurrent session capacity, and throughput on a custom EMIX traffic profile with varying security modules enabled. Tests used Cisco TRex generators and a high-rule-count policy of 100,000 entries to simulate realistic enterprise conditions. Results showed the device sustaining 700,000 CPS and 6.4 million concurrent connections, matching or approaching vendor claims under HA-cluster configuration. Throughput remained above 27 Gbps even with IPS, application control, antivirus, NAT, URL filtering, and logging active. The report highlights differences in test methodology compared with vendor figures, including packet sizes and clustering setup.
Java Card Tutorial: Implementing Supplementary Security Domain to Limit ISD Privileges
A detailed technical guide demonstrates how to create a Supplementary Security Domain (SSD) on Java Card platforms to isolate applet management from the Issuer Security Domain (ISD). The approach prevents full card compromise if ISD keys are exposed by restricting SSD privileges to specific functions such as accepting extradition only from the ISD. Using the FunGP library and SCP02 protocol, the tutorial walks through installation, personalization with encrypted keys, and extradition of applets under the new domain. GlobalPlatform specifications including GP CS v2.3 and GP CIC v2.0 are followed for install parameters, privileges, and STORE DATA commands. After personalization the SSD reaches the PERSONALIZED lifecycle state, allowing secure delegation of applet control while the ISD retains overall card management rights. The method eliminates the need for custom operating systems and provides a standards-compliant way to enforce least-privilege access on smart cards.
Linus Torvalds Embraces Generative AI for Coding After Initial Skepticism
Linus Torvalds has publicly shared his evolving views on generative AI tools for programming during the Open Source Summit Europe. The Linux creator noted that AI assistance makes small personal projects more enjoyable by accelerating the path from idea to working result. He described using an AI model to modernize the outdated C-based user interface of a custom guitar pedal project. Initial AI output proved unusable until Torvalds supplied the existing implementation and clear instructions on required changes. Torvalds emphasized that AI helps newcomers achieve tangible outcomes that feel meaningful compared to professional-grade software. At the same time he urged caution when applying these tools to serious kernel development work. He also highlighted the growing burden on maintainers who must review increasing volumes of low-quality, AI-generated vulnerability reports and superficial patches.