According to AIN.ua, the data center of hosting provider MiroHost was destroyed in September 2026. This article is a guide for tomorrow: how to calculate what a day of downtime costs your store, and which five things to check in advance: DNS, 3-2-1 backups, where your data sits, domain and email, and a restore rehearsal.
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 YouTubeWhen a site is down, it is too late to do the math: all your effort goes into getting it back up. The time to calculate and check is tonight, while everything works. This article is about preparing in advance: how much a day of downtime costs your business and which five things to check so that downtime does not drag on. What to do when the site is already unavailable we covered separately, in the article “Hosting Down: What to Do in the First 24 Hours”.
On September 23, 2026, Kyiv and the surrounding region went through a massive attack. According to a September 24 report by AIN.ua, the data center of the hosting provider MiroHost was destroyed. According to data from the Ministry of Digital Transformation cited by AIN.ua, as of 16:40 on September 23, about 100,000 households were left without internet access. The company did not give a timeline for recovery. The vast majority of MiroHost’s customers, according to reports, were abroad.
On September 26, the Kyiv Independent wrote that several more data centers and providers had been damaged. Datagroup reported that customer data was preserved at backup sites. Some media outlets experienced failures in their video players and on air.
For the owner of a small store, one simple thing follows from this. “The cloud,” “hosting,” “a server” is someone’s building with equipment, electricity and security. A building can lose power or be damaged. Small businesses usually do not think about this, because “the host is responsible, right?” The host is responsible for its building. Where the copy of your store is kept and who knows the domain passwords is your responsibility.
Nobody can name the exact amount of the loss, and anyone who quotes an “average cost of downtime” made it up. But you can estimate the order of magnitude of your own bill in five minutes.
Take a hypothetical store with a turnover of 500,000 UAH per month. The figure is for illustration only; no client data is used here.
The word “turnover” matters here. It is not profit: out of this money you would have paid suppliers, delivery and taxes. But turnover shows the scale: how many orders that week went somewhere else.
The second part of the bill is one people remember late. If the store runs ads, they do not know the site is down. Ads keep showing, people click, the budget is charged for every click, and the person lands on an error page. How much this costs you specifically is visible in your ad account: daily spend multiplied by the days of downtime.
Plug in your own numbers:
Downtime bill ≈ monthly turnover ÷ 30 × days of downtime + ad spend for those days + returns and canceled orders
The last term covers orders a customer placed before the outage and then canceled because they could not check the status or pay. It is different for every store, so we do not put a percentage pulled “out of thin air” here.
Apart from the formula, there are things that cannot be measured but still exist. A customer who twice could not open the site may go straight to a competitor next time. Someone will leave a review saying “the store doesn’t work.” You cannot put this in hryvnias, so just keep it in mind: the real bill is larger than the formula.
Calculate your figure for a week and compare it with the evening the checks below will take.
DNS is the internet’s “phone book”: when someone types your store’s address, DNS tells the browser which server to go to. NS records show who maintains this book for your domain. An A record shows the IP address the domain points to.
The easiest way is through Google’s public DNS resolver in a browser. Open https://dns.google/resolve?name=your-domain.ua&type=NS, substituting your domain. In the response, the Answer field will contain the names of the servers that serve your DNS. Replace type=NS with type=A to see the IP address the domain points to.
If you prefer the command line:
dig NS your-domain.ua +short
dig A your-domain.ua +short
On Windows without dig, nslookup -type=NS your-domain.ua shows the same thing.
One caveat about the A record. If the site runs through a proxy CDN, such as Cloudflare, the A record will show the CDN’s address, and the server where the site physically lives is hidden behind it. So the A record does not answer the question of where the site is hosted. That is found out in the hosting control panel, which is what the third check is about.
Look at the names in the NS records. If they are on your host’s domain, it means DNS lives in the same place as the site. On an ordinary day, this is convenient. On the day of an outage, it is a vulnerability: DNS can become unavailable together with the server. Then you cannot quickly point the domain to a copy of the site elsewhere, because the panel where that is done is down too.
A good result is DNS with a separate provider, not the one where the server is. Then, in an outage, you change one A record to the new server, and visitors gradually start reaching it.
The 3-2-1 rule for backups goes like this: three copies of the data, on two different media, and one of them in another location, meaning another city or another country. For a site, this means: the live site on the server, a copy in another provider’s storage and one more copy somewhere else, for example in another cloud storage or on a drive in the office.
The first is that the copy is on the same server as the site. The hosting panel may show a green “backups: yes” checkmark, but if they are in the same building, they will disappear together with the server. Ask yourself: if this building is shut down for good, where will at least one copy of my store physically remain?
The second mistake is subtler: the copy exists, but nobody has ever restored the site from it. The archive may turn out to be incomplete, the database may be missing the latest tables, and the password to the storage may be known only to a former developer. People find this out at the worst possible moment. That is why a copy has to be tested by restoring it, as described in the fifth check.
For a store, a copy means both the site files and the database. The database is where products, orders and customers are stored. A copy of the files alone, without the database, will restore an empty storefront.
Open the hosting panel and look for where your server is located: country, city, data center name. This is often visible in the plan description or in the server details. If you cannot find it, write to support directly with two questions:
Good support will answer specifically: the city, whether there are copies at another site, how long restoring from them will take. If the answer is vague, along the lines of “everything is reliable with us,” ask again and request a written answer: where exactly the copies are kept and what will happen to the site if the main location is shut down.
There is no right country or city here. The goal of the check is simply to know. An owner who knows where their server is and where the copy is kept does not have to figure it out from scratch on the day of an outage.
The domain is your address. A server can be replaced if you have a copy. With a domain you have no access to, a copy will not help.
Check three things.
Where the domain is registered and who has access to the registrar account. If the domain was bought “together with hosting” and is managed from the same panel, then in a host outage you can lose both the server and the ability to manage your address. It is better when the domain is registered separately, in your name or your company’s name.
Where email lives. If email is on the same server as the site, it disappears on the day of an outage too: emails from customers, from payment systems and from the registrar itself stop arriving. And the registrar’s password reset email may be sent to exactly this mailbox. Email with a separate provider removes this trap.
Who knows the passwords. If access to the registrar, hosting and email is known to one person, that is a vulnerability, even if that person is you. Record the access details in a password manager or a secure place that someone else you trust can also access. Keeping them only with the developer who once built the site is risky.
This is the most important of the five checks.
Take your latest copy and bring the site up from it at a test address: on another server or in a test environment, without touching the live site. Time it from “we take the archive” to “the site opens, the products are in place, a test order can be placed.” Write down what got in the way: there was no password to the storage, the database did not match the PHP version, someone forgot about the settings file.
The recorded time is your real downtime on the day of an outage, measured on your site and your copy. Plug it into the formula from the beginning of the article, and you will see the real bill.
How often should you repeat it? After every significant change to the site: a migration, an engine update, new modules. And at least from time to time without any reason, because copies break quietly.
On September 30, 2026, we looked at the public DNS records of 22 well-known sites: stores, a postal operator, a classifieds service and a job search service.
Sample: rozetka.com.ua, prom.ua, epicentrk.ua, foxtrot.com.ua, allo.ua, citrus.ua, comfy.ua, eldorado.ua, moyo.ua, brain.com.ua, hotline.ua, makeup.com.ua, stylus.ua, intertop.ua, kasta.ua, eva.ua, jysk.ua, watsons.ua, novaposhta.ua, ukrposhta.ua, olx.ua, work.ua.
Method. For each domain, we requested NS and A records through a public DNS resolver (Google DNS over HTTPS). We compared the NS records against global DNS providers and the A records against Cloudflare’s public list of IPv4 ranges.
Result.
The limits of the measurement have to be stated plainly; otherwise, the numbers are easy to misread.
This is a sample of well-known sites, not a census of the Ukrainian internet. The measurement does not show where a site’s server is: DNS and the server are different things. It shows only one thing: whether a site has a “backup route” at the address level, that is, whether its DNS is managed independently of any single building. An address in a CDN range does not mean the site will survive its server going down. And the measurement says nothing about the reliability of specific companies, so we do not give results for individual sites.
The measurement produces only two numbers: 18 of 22 sites have NS records with a global DNS provider, and 12 of 22 have an address in Cloudflare’s ranges. You can check the same for your own domain using the instructions from the first check.
For a small store, a backup route consists of simple things, and it does not require a second data center.
A copy outside the main location. An archive of the site and the database that is shipped out daily to another provider, in another city or country. Not to the same building, not to the same server.
DNS separate from hosting. Then, in an outage, you change one record and point the domain to a new server without waiting for the old host’s panel to come back up.
A one-page action plan. Where the copy is kept, who has access, where to bring it up, who changes the DNS, how long it took in the rehearsal. The page should be kept where you will find it when the site and email are down: printed out or in another cloud storage.
A site can go down even with all of these in place. What they give you is something else: on the day of an outage, you know where to restore from, where to restore to, and how long it took in the rehearsal.
If you would rather have someone else keep an eye on backups and uptime, that is what our pages on backups, uptime monitoring and server administration are about.
| Check | What to look at | Good result | If not |
|---|---|---|---|
| 1. Address (DNS) | NS and A via dns.google or dig NS, dig A |
NS records with a separate provider, not with your host | Move DNS to a separate provider, export the zone in advance |
| 2. Copy | Where the copies are kept, whether they include the database | Three copies, two media, one in another city or country | Set up a daily transfer of the copy to another provider |
| 3. Location | Data center country and city in the panel, support’s answer | You know where the server and the copies are, and what happens if it is shut down | Ask support the two questions, write down the answer |
| 4. Domain and email | Registrar, where email lives, who knows the passwords | Domain and email separate from hosting, at least two people know the access details | Move the domain and email out separately, store access details in a password manager |
| 5. Rehearsal | Bring the site up from a copy at a test address, time it | The site came up, the time is recorded | Fix what got in the way and repeat |
Then this article is for later. Start with the step-by-step instructions in “Hosting Down: What to Do in the First 24 Hours”. If you have an off-site copy and need to bring the site up on a new server quickly, the order of work is described on the page on emergency site migration.
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
There is no universal figure: it depends on turnover, advertising and how long the downtime lasts. For a hypothetical store with a turnover of 500,000 UAH per month, a day of downtime means about 16,700 UAH of lost turnover, and a week about 117,000 UAH. That is turnover, not profit, and on top of it comes the cost of ads that keep showing and lead to a site that does not work.
Use the formula: monthly turnover ÷ 30 × days of downtime + ad spend for those days + returns and canceled orders. Ad spend is visible in your ad account. Separately, keep in mind what cannot be measured in hryvnias: customers who went to a competitor and negative reviews.
Three copies of the data, on two different media, and one of them in another location, meaning another city or country. For a site, this is the live site on the server, a copy in another provider’s storage and one more somewhere else. A copy on the same server as the site does not count under this rule: it will disappear together with the server.
Start with DNS: open https://dns.google/resolve?name=your-domain.ua&type=NS in a browser, and the response will list the servers that serve the domain’s DNS. On the command line, dig NS your-domain.ua +short shows the same thing. The A record (dig A your-domain.ua +short) shows the IP address the domain points to; if the site runs through a proxy CDN, such as Cloudflare, this will be the CDN’s address, not the server’s. So where the server physically sits is found out in the hosting panel or by asking support directly.
A copy in another country protects against an event that affects all sites in one region. There are downsides too: a different jurisdiction, payment in foreign currency, support in another language. The main thing is that at least one copy is outside the building where the site is. Whether that is another city or another country is up to you, weighing these pros and cons. Neither option guarantees that the site will not go down.
After every significant change: a migration, an engine update, installing new modules. And from time to time without any reason, because copies break unnoticed. Each time, write down how long the restore took: that is your real downtime on the day of an outage.
You can, but it makes them dependent on a single platform. If the hosting is unavailable, email disappears along with the site, and the domain management panel may be unavailable. It is more reliable when the domain is registered separately in your name or your company’s name, email runs with a separate provider, and more than one person knows the access details.
While the site is working, make a copy of the files and the database and ship it out to another provider, and then set this up to happen daily. If the site is already unavailable, check every place a copy might have ended up: with the developer, in cloud storage, on a computer, in a git repository. Step by step, this is covered in the article “Hosting Down: What to Do in the First 24 Hours.”
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.
