За повідомленням AIN.ua, у вересні 2026 року знищено дата-центр хостинг-провайдера MiroHost. Ця стаття — інструкція на завтра: як порахувати, скільки коштує день простою вашого магазину, і які п'ять речей перевірити заздалегідь: DNS, копії за правилом 3-2-1, місце даних, домен і пошту, репетицію відновлення.
Розбір того, що сталося з клієнтами хостинг-провайдера після знищення його дата-центру: чому одні клієнти продовжили працювати, а інші постраждали, і короткий список справ на завтра — де лежить копія сайту і що перевірити заздалегідь.
Відкрити на YouTubeКоли сайт лежить, рахувати пізно: усі сили йдуть на те, щоб його підняти. Рахувати й перевіряти варто сьогодні ввечері, поки все працює. Ця стаття — про заздалегідь: скільки коштує день простою для вашого бізнесу і які п'ять речей перевірити, щоб простій не затягнувся. Що робити, коли сайт уже недоступний, ми розібрали окремо, у статті «Хостинг впав: що робити в перші 24 години».
23 вересня 2026 року Київ і область пережили масовану атаку. За повідомленням AIN.ua від 24 вересня, знищено дата-центр хостинг-провайдера MiroHost. За даними Мінцифри, які наводить AIN.ua, станом на 16:40 23 вересня близько 100 000 домогосподарств лишилися без інтернету. Строків відновлення компанія не називала. Переважна більшість клієнтів MiroHost, за повідомленнями, була за кордоном.
Kyiv Independent 26 вересня писав, що пошкоджено ще кілька дата-центрів і провайдерів. Datagroup повідомив, що дані клієнтів збережені на резервних майданчиках. У деяких медіа були збої у відеоплеєрах і в ефірі.
Для власника невеликого магазину з цього випливає одна проста річ. «Хмара», «хостинг», «сервер» — це чиясь будівля з обладнанням, електрикою й охороною. Будівлю можна знеструмити або пошкодити. Малий бізнес зазвичай про це не думає, бо «хостер же відповідає». Хостер відповідає за свою будівлю. За те, де лежить копія вашого магазину і хто знає паролі від домену, відповідаєте ви.
Точну цифру збитку не назве ніхто, і той, хто називає «середній збиток від простою», її вигадав. Але порахувати порядок свого рахунку можна за п'ять хвилин.
Візьмемо умовний магазин з обігом 500 000 ₴ на місяць. Число взято для прикладу, дані клієнтів тут не використано.
Слово «обіг» тут важливе. Це не прибуток: з цих грошей ви заплатили б постачальникам, за доставку, податки. Але саме обіг показує масштаб: скільки замовлень за цей тиждень пішло кудись в інше місце.
Друга частина рахунку, про яку згадують пізно. Якщо в магазину налаштована реклама, вона не знає, що сайт лежить. Оголошення показуються, люди клікають, бюджет списується за кожен клік, а людина потрапляє на сторінку з помилкою. Скільки це коштує саме вам, видно у вашому рекламному кабінеті: денна витрата, помножена на дні простою.
Підставте свої цифри:
Рахунок простою ≈ місячний обіг ÷ 30 × дні простою + витрати на рекламу за ці дні + повернення й скасовані замовлення
Останній доданок — це замовлення, які клієнт оформив до аварії, а потім скасував, бо не міг дізнатись статус чи оплатити. У кожного магазину він свій, тому відсоток «з повітря» ми сюди не ставимо.
Окремо від формули є речі, які не міряються, але існують. Клієнт, який двічі не зміг відкрити сайт, наступного разу може піти одразу до конкурента. Хтось залишить відгук про те, що «магазин не працює». Порахувати це в гривнях не вийде, тому просто тримайте в голові: реальний рахунок більший за формулу.
Порахуйте свою цифру за тиждень і порівняйте її з вечором, який займуть перевірки нижче.
DNS — це «телефонна книга» інтернету: коли людина вводить адресу вашого магазину, DNS підказує браузеру, на який сервер іти. Записи NS показують, хто цю книгу веде для вашого домену. Запис A показує IP-адресу, на яку домен вказує.
Найпростіше — через публічний DNS-резолвер Google у браузері. Відкрийте адресу https://dns.google/resolve?name=ваш-домен.ua&type=NS, підставивши свій домен. У відповіді, у полі Answer, будуть імена серверів, що обслуговують ваш DNS. Замініть type=NS на type=A, щоб побачити IP-адресу, на яку вказує домен.
Якщо звичніше командний рядок:
dig NS ваш-домен.ua +short
dig A ваш-домен.ua +short
На Windows без dig те саме покаже nslookup -type=NS ваш-домен.ua.
Одне застереження щодо запису A. Якщо сайт працює через проксі-CDN, наприклад Cloudflare, запис A покаже адресу CDN, а сервер, де фізично лежить сайт, за нею не видно. Тому запис A не відповідає на питання, де хоститься сайт. Це з'ясовують у панелі хостингу, про що третя перевірка.
Подивіться на імена в NS-записах. Якщо вони на домені вашого хостера, це означає, що DNS живе там само, де й сайт. У звичайний день це зручно. У день аварії це вразливість: разом із сервером може стати недоступним і DNS. Тоді ви не зможете швидко направити домен на копію сайту в іншому місці, бо панель, де це робиться, теж лежить.
Хороший результат — DNS у окремого постачальника, не того, де стоїть сервер. Тоді при аварії ви змінюєте один запис A на новий сервер, і відвідувачі поступово починають потрапляти туди.
Правило 3-2-1 для резервних копій звучить так: три копії даних, на двох різних носіях, і одна з них в іншому місці — іншому місті чи іншій країні. Для сайту це означає: робочий сайт на сервері, копія у сховищі іншого постачальника і ще одна копія деінде, наприклад в іншому хмарному сховищі чи на диску в офісі.
Перша — копія лежить на тому ж сервері, що й сайт. Панель хостингу може показувати зелену позначку «резервні копії: є», але якщо вони в тій самій будівлі, то зникнуть разом із сервером. Запитайте себе: якщо цю будівлю вимкнуть назавжди, де фізично лишиться хоч одна копія мого магазину?
Друга помилка тонша: копія є, але з неї ніхто ніколи не відновлював сайт. Архів може виявитись неповним, база даних може бути без останніх таблиць, а пароль до сховища може знати тільки колишній розробник. Про це дізнаються в найгірший момент. Тому копію треба перевіряти відновленням, як описано в п'ятому пункті.
Для магазину копія — це і файли сайту, і база даних. Саме в базі лежать товари, замовлення, клієнти. Копія лише файлів без бази відновить порожню вітрину.
Відкрийте панель хостингу й пошукайте, де розташований ваш сервер: країна, місто, назва дата-центру. Часто це видно в описі тарифу чи в даних сервера. Якщо не знайшли, напишіть у підтримку прямо, двома питаннями:
Добра підтримка відповість конкретно: місто, чи є копії на іншому майданчику, скільки часу займе відновлення з них. Якщо відповідь розмита, на кшталт «у нас усе надійно», перепитайте й попросіть відповісти письмово: де саме лежать копії і що буде з сайтом, якщо основне місце вимкнуть.
Тут немає правильної країни чи міста. Мета перевірки — просто знати. Власнику, який знає, де стоїть його сервер і де лежить копія, у день аварії не доводиться з'ясовувати це з нуля.
Домен — це ваша адреса. Сервер можна замінити, якщо є копія. З доменом, до якого немає доступу, копія не допоможе.
Перевірте три речі.
Де зареєстровано домен і хто має доступ до кабінету реєстратора. Якщо домен куплено «разом із хостингом» і керується з тієї ж панелі, при аварії хостера ви можете втратити і сервер, і можливість керувати адресою. Краще, коли домен зареєстровано окремо, на ваше ім'я чи вашу компанію.
Де живе пошта. Якщо пошта на тому ж сервері, що й сайт, у день аварії зникає і вона: не приходять листи від клієнтів, від платіжних систем, від самого реєстратора. А лист для відновлення пароля реєстратора може прийти саме на цю пошту. Пошта в окремого постачальника знімає цю пастку.
Хто знає паролі. Якщо доступи до реєстратора, хостингу й пошти знає одна людина, це вразливість, навіть якщо ця людина — ви. Запишіть доступи в менеджер паролів чи в захищене місце, до якого має доступ ще хтось, кому ви довіряєте. Тримати їх лише в розробника, який колись робив сайт, ризиковано.
Це найважливіша перевірка з п'яти.
Візьміть свою останню копію й підніміть із неї сайт на тестовій адресі: на іншому сервері чи в тестовому середовищі, не чіпаючи робочий сайт. Засічіть час від «беремо архів» до «сайт відкривається, товари на місці, можна оформити тестове замовлення». Запишіть, що заважало: не було пароля до сховища, база не підходила до версії PHP, забули про файл налаштувань.
Записаний час — ваш справжній час простою в день аварії, виміряний на вашому сайті й вашій копії. Підставте його у формулу з початку статті, і ви побачите реальний рахунок.
Як часто повторювати? Після кожної суттєвої зміни сайту: переїзду, оновлення рушія, нових модулів. І хоча б час від часу без приводу, бо копії ламаються тихо.
30 вересня 2026 року ми подивились публічні DNS-записи 22 відомих сайтів: магазинів, оператора поштових відправлень, сервісу оголошень і сервісу вакансій.
Вибірка: 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.
Метод. Для кожного домену ми запросили записи NS і A через публічний DNS-резолвер (Google DNS over HTTPS). NS-записи порівняли з глобальними постачальниками DNS, A-записи — з публічним списком IPv4-діапазонів Cloudflare.
Результат.
Межі заміру треба назвати прямо, інакше цифри легко прочитати не так.
Це вибірка з відомих сайтів, а не перепис українського інтернету. Замір не показує, де стоїть сервер сайту: DNS і сервер — різні речі. Він показує лише одне: чи є в сайту «запасна дорога» на рівні адреси, тобто чи керується його DNS незалежно від будь-якої однієї будівлі. Адреса в діапазоні CDN не означає, що сайт переживе падіння свого сервера. І замір нічого не каже про надійність конкретних компаній, тому результатів по окремих сайтах ми не наводимо.
Замір дає лише два числа: у 18 із 22 сайтів NS-записи в глобального постачальника DNS, у 12 із 22 адреса в діапазонах Cloudflare. Перевірити те саме для свого домену можна за інструкцією з першої перевірки.
Для невеликого магазину запасна дорога складається з простих речей, і другий дата-центр для неї не потрібен.
Копія поза основним місцем. Архів сайту й бази, який щодня вивозиться до іншого постачальника, в інше місто чи країну. Не в ту саму будівлю, не на той самий сервер.
DNS окремо від хостингу. Тоді при аварії ви змінюєте один запис і направляєте домен на новий сервер, не чекаючи, поки підніметься панель старого хостера.
План дій на одну сторінку. Де лежить копія, хто має доступ, куди її піднімати, хто змінює DNS, скільки часу це зайняло на репетиції. Сторінка має лежати там, де ви її знайдете, коли сайт і пошта не працюють: роздрукована чи в іншому хмарному сховищі.
Сайт може впасти й за всіх цих умов. Вони дають інше: у день аварії ви знаєте, звідки відновлюватись, куди, і скільки це зайняло на репетиції.
Якщо зручніше, щоб за копіями й доступністю стежили не ви, про це — наші сторінки резервних копій, моніторингу доступності й адміністрування сервера.
| Перевірка | Що дивитись | Хороший результат | Якщо ні |
|---|---|---|---|
| 1. Адреса (DNS) | NS і A через dns.google або dig NS, dig A |
NS-записи в окремого постачальника, не у вашого хостера | Перенести DNS до окремого постачальника, заздалегідь експортувати зону |
| 2. Копія | Де лежать копії, чи є в них база даних | Три копії, два носії, одна в іншому місті чи країні | Налаштувати щоденне вивезення копії до іншого постачальника |
| 3. Місце | Країна й місто дата-центру в панелі, відповідь підтримки | Ви знаєте, де сервер і де копії, і що буде при вимкненні | Спитати підтримку двома питаннями, записати відповідь |
| 4. Домен і пошта | Реєстратор, де живе пошта, хто знає паролі | Домен і пошта окремо від хостингу, доступи знають щонайменше двоє | Винести домен і пошту окремо, зберегти доступи в менеджері паролів |
| 5. Репетиція | Підняти сайт із копії на тестовій адресі, засікти час | Сайт піднявся, час записано | Виправити те, що заважало, і повторити |
Тоді ця стаття на потім. Почніть із покрокової інструкції «Хостинг впав: що робити в перші 24 години». Якщо копія поза площадкою є, а підняти сайт на новому сервері потрібно швидко, порядок робіт описано на сторінці аварійного перенесення сайту.
Ваша думка допомагає нам створювати кращий контент
Допоможіть іншим дізнатись про це — поділіться статтею в соціальних мережах
Дякуємо, що допомагаєте нам рости
Пише про те, що робить руками: інтернет-магазини на OpenCart, застосунки на Next.js, інтеграції та швидкість сайтів. У статтях — заміри й перевірки, які читач може повторити на своєму проєкті, а не загальні поради. Комерційна розробка з 2015 року.
Відповіді на популярні питання по темі
Універсальної цифри немає: вона залежить від обігу, реклами й того, скільки триває простій. Для умовного магазину з обігом 500 000 ₴ на місяць день простою — це близько 16 700 ₴ недоотриманого обігу, тиждень — близько 117 000 ₴. Це обіг, а не прибуток, і до нього додаються витрати на рекламу, яка далі показується й веде на непрацюючий сайт.
Скористайтеся формулою: місячний обіг ÷ 30 × дні простою + витрати на рекламу за ці дні + повернення й скасовані замовлення. Витрати на рекламу видно у вашому рекламному кабінеті. Окремо пам'ятайте про те, що не міряється в гривнях: клієнтів, які пішли до конкурента, і негативні відгуки.
Три копії даних, на двох різних носіях, і одна з них в іншому місці — іншому місті чи країні. Для сайту це робочий сайт на сервері, копія у сховищі іншого постачальника і ще одна деінде. Копія на тому ж сервері, що й сайт, за це правило не рахується: вона зникне разом із сервером.
Почніть із DNS: відкрийте в браузері https://dns.google/resolve?name=ваш-домен.ua&type=NS — у відповіді будуть сервери, які обслуговують DNS домену. У командному рядку те саме покаже dig NS ваш-домен.ua +short. Запис A (dig A ваш-домен.ua +short) показує IP-адресу, на яку вказує домен; якщо сайт працює через проксі-CDN, наприклад Cloudflare, це буде адреса CDN, а не сервера. Тому де фізично стоїть сервер, дізнаються в панелі хостингу або прямим питанням до підтримки.
Копія в іншій країні захищає від події, яка зачіпає всі майданчики в одному регіоні. Мінуси теж є: інша юрисдикція, оплата у валюті, підтримка іншою мовою. Головне — щоб хоча б одна копія була поза будівлею, де стоїть сайт. Чи це інше місто, чи інша країна, вирішуєте ви, зважуючи ці плюси й мінуси. Жоден варіант не гарантує, що сайт не впаде.
Після кожної суттєвої зміни: переїзду, оновлення рушія, встановлення нових модулів. І час від часу без приводу, бо копії ламаються непомітно. Кожного разу записуйте, скільки зайняло відновлення: це ваш справжній час простою в день аварії.
Можна, але це робить їх залежними від однієї площадки. Якщо хостинг недоступний, разом із сайтом зникає пошта, а панель керування доменом може бути недоступною. Надійніше, коли домен зареєстровано окремо на вас чи вашу компанію, пошта працює в окремого постачальника, а доступи до них знає більше ніж одна людина.
Поки сайт працює, зробіть копію файлів і бази даних і вивезіть її до іншого постачальника, а потім налаштуйте, щоб це відбувалось щодня. Якщо сайт уже недоступний, перевірте всі місця, де копія могла опинитись: у розробника, у хмарному сховищі, на комп'ютері, у git-репозиторії. Покроково про це — у статті «Хостинг впав: що робити в перші 24 години».
Підпишіться на нашу розсилку та отримуйте корисні поради, інсайти та новини про веб-розробку, маркетинг та бізнес.
E-commerce та БізнесКомісія від 4,2 %, 10 грн за кожне оформлене замовлення на сайті з власним доменом, а сайти на піддоменах, зареєстровані від 30.05.2025, не індексуються. Що ви платите Prom, що можна забрати з собою, що Prom і далі робить краще і як перевірити рішення за власним вивантаженням замовлень. Умови — за даними на 14.10.2026.
E-commerce та БізнесТема, модуль доставки, фід, правка в кошику — і через кілька років ніхто не скаже, що в рушії штатне. Чотири місця, де каталог на OpenCart упирається в ядро, перевірка кожного за кілька хвилин і чесна межа: що лікується без зміни платформи, а що ні.
E-commerce та БізнесКартка тарифу Хорошопу показує нижню межу. Рахунок рухають лічильник товарів із модифікаціями, ліміт замовлень і функції, які відкриваються лише у старших тарифах. Розбір за сторінкою цін на 14.10.2026 і чесна відповідь, коли оренда вигідніша, а коли власний рушій.
