On the night of 23 to 24 September 2026, a hosting provider’s data center in Ukraine was destroyed. Step by step: how to figure out within the first hour what exactly is not working, what to establish in the first day, in what order to move from a backup, and how to stop depending on a single facility.
A breakdown of what happened to a hosting provider's customers after its data center was destroyed: why some customers kept running while others suffered, and a short to-do list for tomorrow — where your site's backup lives and what to check in advance.
Open on YouTubeOn the night of 23 to 24 September 2026, a hosting provider’s data center in Ukraine was destroyed. For some site owners, the morning began with a site that would not open, email that was not arriving and a hosting control panel that did not respond. This article is not an analysis of the event or an assessment of providers. It is a sequence of actions: what to check in the first hour, what to decide in the first day, and how to set up a site so that next time it does not depend on a single facility.
Below is only what Forbes.ua and AIN.ua reported on 24 September 2026.
How many sites this affected, and whose, we do not know and will not try to count. It is not needed for what follows: a facility can disappear for various reasons, and what a site owner should do barely depends on the reason.
“The site is down” is five different failures, and each is fixed differently. Several links stand between a visitor and your page:
The domain, DNS, server and email are often bought from one supplier. Then, when that supplier fails, everything goes down at once, and from the outside it looks like a single problem.
This time households themselves were left without internet, so the first check is basic: open the site from another network, for example from mobile data on your phone, or ask someone in another city. If the site opens from another network, nothing is down: the problem is with your internet provider.
They work in the terminal on macOS and Linux; nslookup and curl are also available on Windows. Replace example.com with your own domain.
# Who serves the domain's DNS (list of name servers)
dig NS example.com +short
# Whether a specific one of them responds: use a name from the previous command
dig @ns1.example-dns.net example.com A +short
# Which IP address the site points to and with what TTL (second column in the line, in seconds)
dig example.com A +noall +answer
# Where the domain's email is delivered
dig example.com MX +short
# What the server returns: status code and headers, without the page itself
curl -I https://example.com/
On Windows, instead of dig use nslookup -type=NS example.com and nslookup -type=MX example.com. The registrar and the registration expiry date are shown by whois example.com or by the whois page on the registrar’s site.
Do not rely on ping: many servers simply do not let it through, so no reply to ping proves nothing yet. Status codes for several URLs are easy to check with our HTTP status code checker.
| What you see | What it most likely means | First action |
|---|---|---|
dig NS is empty or returns an error, or the dig @nameserver … query gets no answer |
the domain is not delegated (check whois and the registration term) or the DNS hosting is not responding, often the same one that went down |
find out from the registrar where DNS is served and whether you have a copy of the zone records |
dig A returns an IP address, but curl -I hangs for a long time and ends in a timeout |
the server is unreachable: the problem is at the hosting or data center level | check the provider’s status; look for a copy of the site outside that server |
curl -I returns a 5xx code (500, 502, 503, 504) |
the server responds, but the site or its backend is not working: code, database, an update, exhausted resources | look at the error logs; if the host is silent too, it is a question for them, not an immediate move |
521 or 522 on a Cloudflare page |
Cloudflare is working, the server behind it is not | same as a timeout: the problem is on the server, not at Cloudflare |
| the browser warns about the certificate | the certificate has expired or the domain already points to the wrong server | compare the IP address from dig A with the one where the site should be |
| the site opens, but email to the domain does not arrive | email lives separately, and it is email that went down | dig MX shows where email is; check that supplier |
The table row you land in decides the rest of the day. A site failure on a live server is fixed in place. An unreachable server means a choice: wait for the provider or bring the site up elsewhere. If the provider gives a timeline, write it down and check it again a few hours later: not every recovery announcement matches reality.
The decision to wait or to move rests on three questions. It is worth answering them before ordering a new server.
A backup that sat in the control panel of the same host was most likely in the same data center. If the data center is unreachable, assume that backup is gone as well until the provider says otherwise.
Look for backups outside the facility: with your developer, in cloud storage, on your computer, in a git repository. And check what exactly each one contains:
If there is no backup outside the facility at all, waiting for the provider to recover is also a decision, and sometimes the only sensible one. Moving without data is launching a new site, not moving. The web archive will not save you here: as we showed with our own lost domain, you can get URLs and texts out of it, but not the database or the orders.
Without the registrar’s panel you cannot change either the DNS servers or the records. Check three things.
Who owns the domain according to the record: you or your company, or the developer who once bought it. Whether you remember the password to the registrar’s panel. And where the password recovery email will go. The trap here is simple: if the email address used to sign in to the registrar is a mailbox on the same domain, and email lived on the hosting that went down, the recovery email will not arrive anywhere.
TTL is the time during which providers’ servers and browsers remember the old DNS answer before asking again. You can see it in the second column of the output of dig example.com A +noall +answer.
During a planned move, TTL is lowered a few days before the switch so the change spreads quickly. In an emergency this is no longer possible: whatever value was set is the one that applies. If it is 3600 seconds, most visitors will see the new address within about an hour of the record change. If it is 86400, within a day. This is a guideline: some providers and devices keep the old address longer, so check dig from several networks and do not shut down the old server right away.
A separate and slower case is when the domain’s DNS servers were with the supplier that went down. Then you have to change not a record but the DNS servers themselves in the registrar’s panel, and create the zone anew at a new DNS host. How fast such a change spreads is almost out of your hands. And the zone records will have to be recreated from memory if there is no copy of them.
If there is a backup and the decision to move has been made, here is the order in which we would do it. A planned move, while the old server is still running, works differently: there you can take a backup today and switch over without downtime; that is separate work, moving to another hosting provider. In an emergency there is no old server, and everything is built from the backup.
hosts file on your computer or with the command curl -skI --resolve example.com:443:NEW_SERVER_IP https://example.com/, substituting the new server’s address for NEW_SERVER_IP. The -k flag is needed here because the new server may not have a certificate yet. Compare the number of products, orders and customers with what you remember, and check the date of the last order in the backup.www, the email records (MX), the SPF, DKIM and DMARC text records, without which the store’s emails will land in spam, and the verification records for Search Console and other services.MX records save part of the incoming mail.Here the most damage is done not by downtime but by hasty changes.
Status code. For search crawlers, temporary unavailability is a 503 code: it says the page exists and it is worth coming back later. The Retry-After header, per the HTTP standard, suggests exactly when. Google, in its documentation on HTTP and network errors, writes that on 5xx and 429 its crawlers temporarily slow down crawling, while URLs returning 4xx, on the contrary, are removed from the index. If the server does not respond at all, there is nothing to return a 503 with. But if DNS is in your hands and the move drags on, the domain can be temporarily pointed to a placeholder server that returns exactly 503 for every URL. What not to do: return 404, put up a “maintenance in progress” page with a 200 code on every URL, or redirect everything to the home page.
Do not change URLs. The site restored from backup must live at the same URLs. What happens when URLs change without redirects, we saw for ourselves: almost six days of 404s on URLs we had renamed.
Do not combine the move with other changes. A new design, a different engine, switching to another domain: take these as separate steps, once the site is running stably in its new place. If a structural change is needed after all, there is a separate procedure for it: migration without losing traffic and redirects after migration.
About rankings, honestly. How many days of unavailability a site survives without consequences in search results, we cannot say: we have no public data to rely on. Only the general point can be made: the longer a site is unavailable, the greater the risk that its pages start dropping out of the index. After it comes back, fluctuations in impressions during the first days do not yet mean a loss. How to tell ordinary volatility from a failure of your own, we covered separately.
Everything below is done on a calm day. In an emergency there is no time left for it.
Three copies of the data, on two different types of storage, with one of them off-site. “Off-site” means with a different supplier, not on another server in the same data center. For sites operating in Ukraine, it makes sense to keep one copy in another country: it stays available when Ukrainian infrastructure is not.
A backup you have never restored from is not yet a backup, just a file. The check is simple: deploy it on a test domain and open the site. Do it regularly and after every change to the backup setup. Setting up backups together with a test restore is described on the page on backups with restore testing.
And an honest limit on frequency: a daily backup means that in the worst case a day’s worth of changes is lost. For a blog that is a minor thing. For a store it means that day’s orders, which will have to be pieced together from emails and payment systems.
If the DNS zone lives not with the host but with the registrar or a separate DNS provider, after a server failure it is enough to change one IP address. Wherever the zone is, keep its export on your side: a text list of all the records. The email address for the registrar should be a mailbox that does not depend on your domain or your hosting.
An uptime monitor running on the same server goes down with it and warns no one. The check should come from another network, and alerts should go where they will be seen at night. How our own monitoring existed for months only in the documentation, we told without embellishment. Setting up an external check: uptime monitoring.
A disaster recovery plan for a small site is not a corporate document. One page is enough, as long as you can find it while the site and email are down:
The last two answers determine everything else. If losing a day and being down for a day is acceptable, a nightly backup at another supplier plus instructions is enough. If not, you need a second facility kept in working order at all times, and that means different money and different complexity. For most small stores, the first is a reasonable compromise.
No facility promises uninterrupted operation, and ours does not either. Data centers in other countries have their own risks: a different jurisdiction, payment in foreign currency, support in another language. A move, even with a ready backup, takes hours, not minutes. Independence from a single facility does not eliminate the emergency; it makes the emergency manageable: you know where to restore from and what exactly has been lost.
The agency’s site and our own projects run on rented servers in Germany, at Hetzner. Every night a backup is shipped to a separate storage at the same provider: off the server, but not off the supplier. Server metrics track load, memory and disk, and alerts go to Telegram. To be honest about the limits: both the backup storage and the monitoring are currently within a single supplier, so this does not protect us from losing Hetzner itself, and there is no external monitor from another network yet. We consider an external check and a backup at another supplier the next step, not something already done. This is not a guarantee of continuity: it means the backup sits outside the server itself; we will recover from losing the server, but not from losing the supplier. And we will learn about exhausted memory, a full disk or the site being unavailable on a running server from an alert, not from customers.
If your site is already unavailable and you have a backup outside the facility, we will bring it up on a new server; the procedure is described on the page on emergency site migration. If the site is working but you are not sure you could restore it from your current backups, start with a free backup check: we will look at where they are stored and whether you can actually restore from them.
Your opinion helps us create better content
Help others learn about it - share the article on social networks
Thank you for helping us grow
Writes about what he builds himself: online stores on OpenCart, applications on Next.js, integrations and site speed. The articles carry measurements and checks a reader can repeat on their own project, not general advice. Commercial development since 2015.
Answers to common questions on the topic
First open the site from another network, for example from mobile data: sometimes the problem is your own connection. Next, run curl -I with the site’s URL. If it returns a 5xx code (for example, 500), the server responds, but the site or its backend is not working: start with the error logs and a question to the host. If the request hangs for a long time and then drops, the server is unreachable, meaning the hosting or the data center. If dig NS is empty and a query sent directly to the name server gets no answer, the problem is in the domain’s DNS.
Check every place a copy could have ended up: with your developer, in cloud storage, on a computer, in a git repository. If the database is nowhere to be found, moving is impossible: you can only launch a new site. In that case it is wiser to wait for the provider to restore its infrastructure and, in the meantime, check your access to the domain registrar. The web archive will return page URLs and texts, but not the database or the orders.
Only from a backup that was stored outside the old hosting. The order is: a server with the same PHP and database versions, the files, restoring the database from the dump, checking the site on the new server before changing DNS, then the DNS records including the email ones, the certificate, scheduled tasks, integrations with payment systems and delivery services, and a test order from the cart to the email to the manager.
No exact period that a site survives without consequences can be named: the longer it is unavailable, the greater the risk that its pages start dropping out of the index. The risk is reduced by a 503 code while the site is unavailable instead of a 404 or a placeholder page with a 200 code, by unchanged page URLs, and by not redesigning or changing the structure during the move.
By the 3-2-1 rule: three copies, on two different types of storage, one of them off-site, that is, with a different supplier rather than on a neighboring server in the same data center. For sites in Ukraine, it makes sense to keep one copy in another country. And deploy a backup on a test domain from time to time: a backup you have never restored from may turn out to be unusable exactly when you need it.
That is determined by the record’s TTL as it was set before the failure: you can see it with the command dig example.com A +noall +answer. At 3600 seconds, most visitors will see the new address in about an hour; at 86400, within a day. If the domain’s DNS servers were with the supplier that went down, you will have to change the DNS servers themselves at the registrar, and such a change spreads more slowly and is almost out of your hands. This is a guideline, not a deadline: some visitors will see the change later.
Place a test order from the cart to the very end: payment, emails to the customer and the manager, the order appearing in the admin panel and the CRM. Separately check the payment systems’ callback URL, the allowed IPs in APIs, the exchange with the accounting system, whether marketplace feeds are up to date, and the SPF and DKIM records, without which the store’s emails land in spam.
Subscribe to our newsletter and receive useful tips, insights and news about web development, marketing and business.
E-commerce and businessA commission from 4.2%, 10 UAH for every order placed on a site with its own domain, and subdomain sites registered on or after 5/30/2025 are not indexed. What you pay Prom, what you can take with you, what Prom still does better, and how to check the decision against your own order export. Terms as of 10/14/2026.
E-commerce and businessA theme, a shipping module, a feed, a tweak in the cart — and a few years later nobody can say what in the engine is built in. Four places where an OpenCart catalog runs into the core, a check for each that takes a few minutes, and an honest line: what can be fixed without changing the platform and what can't.
E-commerce and businessA Horoshop plan card shows the lower bound. The bill is driven by a product counter that includes variants, an order limit, and features that unlock only in higher plans. A breakdown based on the pricing page as of October 14, 2026, and an honest answer on when renting pays off and when your own engine does.
