У ніч з 23 на 24 вересня 2026 року в Україні зруйновано дата-центр хостинг-провайдера. Покроково: як за першу годину зрозуміти, що саме не працює, що з'ясувати за першу добу, у якому порядку переїжджати з копії і як більше не залежати від однієї площадки.
Розбір того, що сталося з клієнтами хостинг-провайдера після знищення його дата-центру: чому одні клієнти продовжили працювати, а інші постраждали, і короткий список справ на завтра — де лежить копія сайту і що перевірити заздалегідь.
Відкрити на YouTubeУ ніч з 23 на 24 вересня 2026 року в Україні зруйновано дата-центр хостинг-провайдера. Для частини власників сайтів ранок почався з того, що сайт не відкривається, пошта не приходить, а панель хостингу не відповідає. Ця стаття — не розбір події й не оцінка провайдерів. Це порядок дій: що перевірити першою годиною, що вирішити першою добою і як улаштувати сайт так, щоб наступного разу він не залежав від однієї площадки.
Нижче лише те, що повідомили Forbes.ua і AIN.ua 24 вересня 2026 року.
Скільки сайтів це зачепило і чиїх, ми не знаємо й рахувати не будемо. Для подальшого це й не потрібно: площадка може зникнути з різних причин, а порядок дій власника сайту від причини майже не залежить.
«Сайт не працює» — це п'ять різних поломок, і лікуються вони по-різному. Між відвідувачем і вашою сторінкою стоять кілька ланок:
Часто домен, DNS, сервер і пошта куплені в одного постачальника. Тоді при його аварії падає все разом, і зовні це виглядає як одна проблема.
Цього разу без інтернету лишились і самі домогосподарства, тож перша перевірка банальна: відкрийте сайт з іншої мережі, наприклад із мобільного інтернету на телефоні, або попросіть когось з іншого міста. Якщо з іншої мережі сайт відкривається, падіння немає — є проблема з вашим провайдером.
Вони працюють у терміналі на macOS і Linux; nslookup і curl є й у Windows. Замість example.com підставте свій домен.
# Хто обслуговує DNS домену (список серверів імен)
dig NS example.com +short
# Чи відповідає конкретний з них: підставте ім'я з попередньої команди
dig @ns1.example-dns.net example.com A +short
# На яку IP-адресу вказує сайт і з яким TTL (другий стовпець у рядку — секунди)
dig example.com A +noall +answer
# Куди доставляється пошта домену
dig example.com MX +short
# Що відповідає сервер: код і заголовки, без самої сторінки
curl -I https://example.com/
У Windows замість dig — nslookup -type=NS example.com, nslookup -type=MX example.com. Реєстратора й дату закінчення реєстрації покаже whois example.com або сторінка whois на сайті реєстратора.
На ping не покладайтесь: багато серверів його просто не пропускають, тож відсутність відповіді на ping ще нічого не доводить. Коди відповіді для кількох адрес зручно подивитись нашим інструментом перевірки кодів відповіді.
| Що бачите | Що це найімовірніше | Перша дія |
|---|---|---|
dig NS порожній чи з помилкою, або запит dig @сервер_імен … не дає відповіді |
домен не делеговано (перевірте whois і строк реєстрації) або не відповідає DNS-хостинг — часто той самий, що впав |
з'ясувати в реєстратора, де обслуговується DNS, і чи є у вас копія записів зони |
dig A дає IP-адресу, а curl -I довго чекає й обривається з таймаутом |
сервер недоступний: проблема на рівні хостингу чи дата-центру | перевірити статус провайдера; шукати копію сайту поза цим сервером |
curl -I повертає код 5xx (500, 502, 503, 504) |
сервер відповідає, але сайт чи його бекенд не працює: код, база, оновлення, вичерпані ресурси | дивитися журнали помилок; якщо й хостер мовчить — питання до нього, а не переїзд одразу |
521 або 522 на сторінці Cloudflare |
Cloudflare працює, а сервер за ним — ні | те саме, що з таймаутом: проблема на сервері, а не в Cloudflare |
| браузер попереджає про сертифікат | сертифікат прострочено або домен уже вказує не на той сервер | звірити IP-адресу з dig A з тією, де має бути сайт |
| сайт відкривається, листи на домен не приходять | пошта живе окремо, і впала саме вона | dig MX — де пошта; перевірити цього постачальника |
Рядок таблиці, у який ви потрапили, вирішує решту дня. Поломка сайту на живому сервері лікується на місці. Недоступний сервер означає вибір: чекати провайдера чи піднімати сайт деінде. Якщо провайдер називає строк, запишіть його й звірте через кілька годин: не кожне повідомлення про відновлення збігається з реальністю.
Рішення «чекати чи переїжджати» тримається на трьох питаннях. Їх варто з'ясувати до того, як замовляти новий сервер.
Копія, яка лежала в панелі того самого хостера, найімовірніше, була в тому самому дата-центрі. Якщо недоступний дата-центр, вважайте, що цієї копії теж немає, поки провайдер не скаже інше.
Пошукайте копії поза площадкою: у розробника, у хмарному сховищі, на вашому комп'ютері, у git-репозиторії. І подивіться, що саме в кожній:
Якщо копії поза площадкою немає зовсім, чекати відновлення від провайдера — теж рішення, і часом єдине розумне. Переїзд без даних — це запуск нового сайту, а не переїзд. Веб-архів тут не рятує: як ми показували на власній втраті домену, з нього дістаються адреси й тексти, але не база й не замовлення.
Без панелі реєстратора ви не зміните ні DNS-сервери, ні записи. Перевірте три речі.
Хто власник домену за записом: ви чи ваша компанія, чи розробник, який колись його купував. Чи пам'ятаєте ви пароль до панелі реєстратора. І куди прийде лист для відновлення пароля. Пастка тут проста: якщо пошта для входу в реєстратора — скринька на тому самому домені, а пошта жила на хостингу, що впав, лист для відновлення доступу не прийде нікуди.
TTL — час, протягом якого сервери провайдерів і браузери пам'ятають стару відповідь DNS, перш ніж перепитати. Його видно в другому стовпці виводу dig example.com A +noall +answer.
Під час планового переїзду TTL знижують за кілька днів до перемикання, щоб зміна розійшлась швидко. В аварії цього зробити вже не вийде: діє те значення, яке стояло. Якщо там 3600 секунд, більшість відвідувачів побачить нову адресу приблизно протягом години після зміни запису. Якщо 86400 — протягом доби. Це орієнтир: окремі провайдери й пристрої тримають стару адресу довше, тому перевіряйте dig з кількох мереж і не вимикайте старий сервер одразу.
Окремий і повільніший випадок — коли DNS-сервери домену були в постачальника, що впав. Тоді змінювати доведеться не запис, а самі DNS-сервери в панелі реєстратора, і створювати зону заново на новому DNS-хостингу. Як швидко розійдеться така зміна, від вас майже не залежить. І записи зони доведеться відтворювати з пам'яті, якщо їхньої копії немає.
Якщо копія є і рішення переїжджати ухвалене, ось порядок, у якому ми б це робили. Плановий переїзд, коли старий сервер ще працює, влаштований інакше: там можна зробити копію сьогодні й перемикатись без простою — це окрема робота, перенесення на інший хостинг. В аварії старого сервера немає, і все будується від копії.
hosts на своєму комп'ютері або командою curl -skI --resolve example.com:443:NEW_SERVER_IP https://example.com/, підставивши замість NEW_SERVER_IP адресу нового сервера. Ключ -k тут потрібен, бо сертифіката на новому сервері ще може не бути. Порівняйте кількість товарів, замовлень і клієнтів з тим, що пам'ятаєте, і дату останнього замовлення в копії.www, записи пошти (MX), текстові записи SPF, DKIM і DMARC, без яких листи магазину потраплятимуть у спам, і записи підтвердження для Search Console та інших сервісів.MX-записи рятують частину вхідної пошти.Тут найбільше шкоди роблять не простої, а поспішні зміни.
Код відповіді. Для пошукових роботів тимчасова недоступність — це код 503: він каже, що сторінка є, і повертатись варто пізніше. Заголовок Retry-After за стандартом HTTP підказує, коли саме. Google у довідці про помилки HTTP і мережі пише, що на 5xx і 429 його роботи тимчасово сповільнюють обхід, а адреси з 4xx, навпаки, прибирає з індексу. Якщо сервер не відповідає взагалі, 503 віддати нічим. Але якщо DNS у ваших руках, а переїзд затягується, домен можна тимчасово спрямувати на сервер-заглушку, який на всі адреси віддає саме 503. Чого не робити: віддавати 404, ставити сторінку «ведуться роботи» з кодом 200 на всі адреси чи перенаправляти все на головну.
Адреси не міняти. Сайт з копії має жити за тими самими адресами. Що буває, коли адреси змінюються без переадресацій, ми бачили на собі: майже шість днів 404 на адресах, які ми перейменували.
Не поєднувати переїзд з іншими змінами. Новий дизайн, інший рушій, перехід на інший домен — окремими кроками, коли сайт уже стабільно працює на новому місці. Якщо зміна структури все ж потрібна, для неї є окремий порядок: міграція без втрати трафіку і редиректи після міграції.
Про позиції — чесно. Скільки днів недоступності переживає сайт без наслідків для видачі, ми назвати не можемо: публічних даних, на які можна спертися, у нас немає. Можна сказати лише загальне: чим довше сайт недоступний, тим більший ризик, що сторінки почнуть випадати з індексу. Після повернення коливання показів у перші дні ще не означають втрати. Як відрізнити звичайну волатильність від власної поломки, ми розбирали окремо.
Усе, що нижче, робиться у спокійний день. В аварії на це вже немає часу.
Три копії даних, на двох різних типах сховища, і одна з них — поза площадкою. «Поза площадкою» означає в іншого постачальника, а не на іншому сервері в тому самому дата-центрі. Для сайтів, що працюють в Україні, розумно тримати одну копію в іншій країні: вона лишається доступною, коли недоступна українська інфраструктура.
Копія, з якої жодного разу не відновлювались, — ще не копія, а файл. Перевірка проста: розгорнути її на тестовому домені й відкрити сайт. Робити це регулярно й після кожної зміни схеми копіювання. Налаштування копій разом із тестовим відновленням описано на сторінці резервних копій з перевіркою відновлення.
І чесна межа частоти: копія раз на добу означає, що в найгіршому випадку втрачаються зміни за добу. Для блогу це дрібниця. Для магазину — замовлення цього дня, які доведеться збирати з листів і платіжних систем.
Якщо DNS-зона живе не в хостера, а в реєстратора чи окремого DNS-провайдера, після аварії сервера достатньо змінити одну IP-адресу. Незалежно від того, де зона, зберігайте в себе її експорт — текстовий список усіх записів. Пошта для реєстратора має бути скринькою, яка не залежить від вашого домену й хостингу.
Монітор доступності, що працює на тому самому сервері, падає разом із ним і нікого не попереджає. Перевірка має йти з іншої мережі, а сповіщення — туди, де їх побачать уночі. Як наш власний моніторинг місяцями існував лише в документації, ми розповідали без прикрас. Налаштування зовнішньої перевірки — моніторинг доступності.
План аварійного відновлення для невеликого сайту — не корпоративний документ. Достатньо однієї сторінки, яку можна знайти, коли сайт і пошта лежать:
Дві останні відповіді визначають усе інше. Якщо допустимо втратити день і простояти день, досить нічної копії в іншого постачальника та інструкції. Якщо ні — потрібна друга площадка, яку постійно підтримують у робочому стані, а це вже інші гроші й інша складність. Для більшості невеликих магазинів розумний компроміс — перше.
Жодна площадка не обіцяє безперервної роботи, і наша теж. Дата-центри в інших країнах мають власні ризики: інша юрисдикція, оплата у валюті, підтримка іншою мовою. Переїзд навіть з готовою копією займає години, а не хвилини. Незалежність від площадки не прибирає аварію — вона робить аварію керованою: ви знаєте, звідки відновлюватись і що саме втрачено.
Сайт агенції й наші власні проєкти працюють на орендованих серверах у Німеччині, у Hetzner. Щоночі копія вивозиться на окреме сховище того ж провайдера — за межі сервера, але не за межі постачальника. Метрики сервера стежать за навантаженням, пам'яттю й диском, тривоги йдуть у Telegram. Чесно про межі: і сховище копій, і моніторинг сьогодні в межах одного постачальника, тож від втрати самого Hetzner нас це не страхує, а зовнішнього монітора з іншої мережі поки немає. Зовнішню перевірку й копію в іншого постачальника ми вважаємо наступним кроком, а не тим, що вже зроблено. Це не гарантія безперервності: це означає, що копія лежить поза самим сервером; від втрати сервера ми відновимось, від втрати постачальника — ні. А про вичерпану пам'ять, диск чи недоступність сайту на працюючому сервері ми дізнаємось із тривоги, а не від клієнтів.
Якщо сайт уже недоступний і копія поза площадкою є, піднімемо його на новому сервері — порядок робіт описано на сторінці аварійного перенесення сайту. Якщо сайт працює, але ви не впевнені, чи зможете відновити його з поточних копій, почніть із безкоштовної перевірки копій: подивимось, де вони лежать і чи з них справді можна відновитись.
Ваша думка допомагає нам створювати кращий контент
Допоможіть іншим дізнатись про це — поділіться статтею в соціальних мережах
Дякуємо, що допомагаєте нам рости
Пише про те, що робить руками: інтернет-магазини на OpenCart, застосунки на Next.js, інтеграції та швидкість сайтів. У статтях — заміри й перевірки, які читач може повторити на своєму проєкті, а не загальні поради. Комерційна розробка з 2015 року.
Відповіді на популярні питання по темі
Спершу відкрийте сайт з іншої мережі, наприклад із мобільного інтернету: іноді проблема у вашому з'єднанні. Далі команда curl -I з адресою сайту. Якщо вона повертає код 5xx (наприклад, 500), сервер відповідає, але не працює сайт чи його бекенд — спершу журнали помилок і питання до хостера. Якщо запит довго чекає й обривається, недоступний сервер, тобто хостинг чи дата-центр. Якщо dig NS порожній, а запит безпосередньо до сервера імен не відповідає, проблема в DNS домену.
Перевірте всі місця, де копія могла опинитись: у розробника, у хмарному сховищі, на комп'ютері, у git-репозиторії. Якщо бази даних ніде немає, переїзд неможливий — можна лише запустити новий сайт. Тоді розумніше чекати, поки провайдер відновить інфраструктуру, а тим часом перевірити доступ до реєстратора домену. Веб-архів поверне адреси й тексти сторінок, але не базу й не замовлення.
Лише з копії, що лежала поза старим хостингом. Порядок такий: сервер з тими самими версіями PHP і бази, файли, відновлення бази з дампу, перевірка сайту на новому сервері до зміни DNS, потім записи DNS разом із поштовими, сертифікат, задачі за розкладом, інтеграції з платіжними системами й службами доставки і тестове замовлення від кошика до листа менеджеру.
Точного строку, який сайт переживає без наслідків, назвати не можна: чим довше недоступність, тим більший ризик, що сторінки почнуть випадати з індексу. Зменшити ризик допомагає код 503 на час недоступності замість 404 чи заглушки з кодом 200, незмінні адреси сторінок і відмова від редизайну чи зміни структури під час переїзду.
За правилом 3-2-1: три копії, на двох різних типах сховища, одна з них поза площадкою, тобто в іншого постачальника, а не на сусідньому сервері того самого дата-центру. Для сайтів в Україні розумно тримати одну копію в іншій країні. І раз у раз розгортати копію на тестовому домені: копія, з якої ніколи не відновлювались, може виявитись непридатною саме тоді, коли знадобиться.
Це визначає TTL запису, яке стояло до аварії: його видно в команді dig example.com A +noall +answer. При 3600 секундах більшість відвідувачів побачить нову адресу приблизно за годину, при 86400 — протягом доби. Якщо ж DNS-сервери домену були в постачальника, що впав, доведеться міняти самі DNS-сервери в реєстратора, і така зміна поширюється повільніше й від вас майже не залежить. Це орієнтир, а не строк: частина відвідувачів побачить зміну пізніше.
Зробіть тестове замовлення від кошика до кінця: оплата, лист покупцю й менеджеру, поява замовлення в адмінці та CRM. Окремо перевірте адресу зворотного виклику платіжних систем, дозволені IP в API, обмін з обліковою системою, актуальність фідів для маркетплейсів і записи SPF та DKIM, без яких листи магазину потрапляють у спам.
Підпишіться на нашу розсилку та отримуйте корисні поради, інсайти та новини про веб-розробку, маркетинг та бізнес.
E-commerce та БізнесКомісія від 4,2 %, 10 грн за кожне оформлене замовлення на сайті з власним доменом, а сайти на піддоменах, зареєстровані від 30.05.2025, не індексуються. Що ви платите Prom, що можна забрати з собою, що Prom і далі робить краще і як перевірити рішення за власним вивантаженням замовлень. Умови — за даними на 14.10.2026.
E-commerce та БізнесТема, модуль доставки, фід, правка в кошику — і через кілька років ніхто не скаже, що в рушії штатне. Чотири місця, де каталог на OpenCart упирається в ядро, перевірка кожного за кілька хвилин і чесна межа: що лікується без зміни платформи, а що ні.
E-commerce та БізнесКартка тарифу Хорошопу показує нижню межу. Рахунок рухають лічильник товарів із модифікаціями, ліміт замовлень і функції, які відкриваються лише у старших тарифах. Розбір за сторінкою цін на 14.10.2026 і чесна відповідь, коли оренда вигідніша, а коли власний рушій.
