Сайт не работает: хостинг или дата-центр вышел из строя — что делать владельцу сайта в первые 24 часа и как не зависеть от одной площадки

В ночь с 23 на 24 сентября 2026 года в Украине разрушен дата-центр хостинг-провайдера. Для части владельцев сайтов утро началось с того, что сайт не открывается, почта не приходит, а панель хостинга не отвечает. Эта статья — не разбор события и не оценка провайдеров. Это порядок действий на случай, когда сайт не работает и хостинг недоступен: что проверить в первый час, что решить в первые сутки и как устроить сайт так, чтобы в следующий раз он не зависел от одной площадки.

Что известно о событии

Ниже только то, что сообщили Forbes.ua и AIN.ua 24 сентября 2026 года.

• В ночь с 23 на 24 сентября российский удар уничтожил украинский дата-центр хостинг-провайдера MiroHost.
• Основатель компании Александр Ольшанский сказал, что последствия касаются только украинской инфраструктуры MiroHost. По его словам, примерно 90–95% клиентов (по данным Forbes.ua; AIN.ua пишет о примерно 90%) работают за пределами Украины, и для них сервисы работают в обычном режиме. Назвать сроки восстановления украинской инфраструктуры компания не может.
• Повреждена также инфраструктура UTELS (дата-центр со столичным узловым оборудованием), «Павутины», Crazy Network и FEX.NET. По данным Минцифры, в Киеве и области без интернета осталось около 100 000 домохозяйств.

Сколько сайтов это затронуло и чьих, мы не знаем и считать не будем. Для дальнейшего это и не нужно: площадка может исчезнуть по разным причинам, а порядок действий владельца сайта от причины почти не зависит.

Первый час: сайт не работает — понять, что именно

«Сайт не работает» — это пять разных поломок, и лечатся они по-разному. Между посетителем и вашей страницей стоят несколько звеньев:

• домен — запись у регистратора, которая должна быть оплачена и делегирована;
• DNS — серверы, которые отвечают, на какой IP-адрес вести посетителя и куда доставлять почту;
• сервер — машина в дата-центре, где лежат файлы и база;
• сам сайт — код и база данных на этом сервере;
• почта на домене — нередко живёт у того же хостера, что и сайт.

Часто домен, 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 ещё ничего не доказывает. Коды ответа для нескольких адресов удобно посмотреть нашим инструментом проверки кодов ответа.

Как читать ответы

Строка таблицы, в которую вы попали, определяет остаток дня. Поломка сайта на живом сервере лечится на месте. Недоступный сервер означает выбор: ждать провайдера или поднимать сайт в другом месте. Если провайдер называет срок, запишите его и сверьте через несколько часов: не каждое сообщение о восстановлении совпадает с реальностью.

Первые сутки: копия, доступы, TTL

Решение «ждать или переезжать» держится на трёх вопросах. Их стоит выяснить до того, как заказывать новый сервер.

Где ваша резервная копия и что в ней

Копия, которая лежала в панели того же хостера, скорее всего, была в том же дата-центре. Если недоступен дата-центр, считайте, что этой копии тоже нет, пока провайдер не скажет иное.

Поищите копии вне площадки: у разработчика, в облачном хранилище, на вашем компьютере, в git-репозитории. И посмотрите, что именно в каждой:

• файлы сайта — код, шаблоны, модули;
• загруженные файлы — фото товаров, документы; в git их обычно нет;
• база данных — товары, заказы, клиенты, настройки; без неё магазина нет;
• дата — из копии за прошлый месяц вернётся сайт прошлого месяца, а новые заказы придётся восстанавливать из писем и платёжных систем.

Если копии вне площадки нет совсем, ждать восстановления от провайдера — тоже решение, и порой единственное разумное. Переезд без данных — это запуск нового сайта, а не переезд. Веб-архив здесь не спасает: как мы показывали на собственной потере домена, из него достаются адреса и тексты, но не база и не заказы.

Доступ к регистратору домена

Без панели регистратора вы не измените ни DNS-серверы, ни записи. Проверьте три вещи.

Кто владелец домена по записи: вы, ваша компания или разработчик, который когда-то его покупал. Помните ли вы пароль к панели регистратора. И куда придёт письмо для восстановления пароля. Ловушка здесь простая: если почта для входа к регистратору — ящик на том же домене, а почта жила на упавшем хостинге, письмо для восстановления доступа не придёт никуда.

TTL: сколько ждать после переключения

TTL — время, в течение которого серверы провайдеров и браузеры помнят старый ответ DNS, прежде чем переспросить. Его видно во втором столбце вывода dig example.com A +noall +answer.

При плановом переезде TTL снижают за несколько дней до переключения, чтобы изменение разошлось быстро. В аварии этого сделать уже не получится: действует то значение, которое стояло. Если там 3600 секунд, большинство посетителей увидит новый адрес примерно в течение часа после изменения записи. Если 86400 — в течение суток. Это ориентир: отдельные провайдеры и устройства держат старый адрес дольше, поэтому проверяйте dig из нескольких сетей и не выключайте старый сервер сразу.

Отдельный и более медленный случай — когда DNS-серверы домена были у упавшего поставщика. Тогда менять придётся не запись, а сами DNS-серверы в панели регистратора, и создавать зону заново на новом DNS-хостинге. Как быстро разойдётся такое изменение, от вас почти не зависит. И записи зоны придётся воссоздавать по памяти, если их копии нет.

Перенос сайта на другой хостинг: порядок действий

Если копия есть и решение переезжать принято, вот порядок, в котором мы бы это делали. Плановый переезд, когда старый сервер ещё работает, устроен иначе: там можно сделать копию сегодня и переключаться без простоя — это отдельная работа, перенос на другой хостинг. В аварии старого сервера нет, и всё строится на восстановлении сайта из бэкапа.

1. Сервер с теми же версиями. Версия PHP, базы данных, расширений — как была. Обновлять посреди аварии не стоит: если сайт не запустится, вы не будете знать, виновата копия или новая версия.
2. Файлы, потом база. Развернуть файлы, восстановить базу из дампа, прописать новые доступы к базе в конфигурации сайта.
3. Проверка до переключения DNS. Сайт можно открыть на новом сервере, пока домен ещё указывает на старый: через файл hosts на своём компьютере или командой curl -skI --resolve example.com:443:NEW_SERVER_IP https://example.com/, подставив вместо NEW_SERVER_IP адрес нового сервера. Ключ -k здесь нужен, потому что сертификата на новом сервере ещё может не быть. Сравните количество товаров, заказов и клиентов с тем, что помните, и дату последнего заказа в копии.
4. Записи DNS. Не только адрес сайта. Перенесите www, записи почты (MX), текстовые записи SPF, DKIM и DMARC, без которых письма магазина будут попадать в спам, и записи подтверждения для Search Console и других сервисов.
5. Сертификат. Бесплатный сертификат с проверкой по HTTP выдаётся, когда домен уже указывает на новый сервер. Поэтому его выпускают сразу после переключения или заранее через проверку по DNS-записи. Как убедиться, что он потом будет продлеваться сам, мы разбирали на 116 сайтах.
6. Задачи по расписанию. Они не переезжают вместе с файлами. Обмен с 1С или BAS, генерация фидов, обновление курсов, рассылки, очистка кэша — всё это нужно снова добавить на новом сервере и проверить, что запускается.
7. Почта. Ящики, которые жили на упавшем хостинге, вместе со старыми письмами могут быть потеряны. Новые письма серверы отправителей обычно пытаются доставить повторно в течение некоторого времени, поэтому быстро восстановленные MX-записи спасают часть входящей почты.
8. Интеграции, привязанные к адресу или IP. Платёжные системы (LiqPay, monobank) сообщают сайту об оплате на указанный адрес обратного вызова; часть API пропускает запросы только с разрешённых IP, а у нового сервера IP другой. Новая Почта, маркетплейсы, учётная система, склад — пройдите каждую. Фид для Rozetka или Prom по тому же адресу может открываться, но быть устаревшим, если задача, которая его перегенерирует, не перенесена.
9. Тестовый заказ от начала до конца. Корзина, оплата, письмо покупателю, письмо менеджеру, появление заказа в админке и в CRM. Пока он не прошёл, переезд не закончен.

Поиск, пока сайт недоступен

Здесь больше всего вреда наносят не простои, а поспешные изменения.

Код ответа. Для поисковых роботов временная недоступность — это код 503: он говорит, что страница есть, и возвращаться стоит позже. Заголовок Retry-After по стандарту HTTP подсказывает, когда именно. Google в справке об ошибках HTTP и сети пишет, что при 5xx и 429 его роботы временно замедляют обход, а адреса с 4xx, наоборот, убирает из индекса. Если сервер не отвечает вообще, 503 отдать нечем. Но если DNS в ваших руках, а переезд затягивается, домен можно временно направить на сервер-заглушку, который на все адреса отдаёт именно 503. Чего не делать: отдавать 404, ставить страницу «ведутся работы» с кодом 200 на все адреса или перенаправлять всё на главную.

Адреса не менять. Сайт из копии должен жить по тем же адресам. Что бывает, когда адреса меняются без переадресаций, мы видели на себе: почти шесть дней 404 на адресах, которые мы переименовали.

Не совмещать переезд с другими изменениями. Новый дизайн, другой движок, переход на другой домен — отдельными шагами, когда сайт уже стабильно работает на новом месте. Если изменение структуры всё же нужно, для него есть отдельный порядок: миграция без потери трафика и редиректы после миграции.

О позициях — честно. Сколько дней недоступности переживает сайт без последствий для выдачи, мы назвать не можем: публичных данных, на которые можно опереться, у нас нет. Можно сказать лишь общее: чем дольше сайт недоступен, тем больше риск, что страницы начнут выпадать из индекса. После возвращения колебания показов в первые дни ещё не означают потери. Как отличить обычную волатильность от собственной поломки, мы разбирали отдельно.

Как не зависеть от одной площадки

Всё, что ниже, делается в спокойный день. В аварии на это уже нет времени.

Резервное копирование сайта по правилу 3-2-1

Три копии данных, на двух разных типах хранилища, и одна из них — вне площадки. «Вне площадки» означает у другого поставщика, а не на другом сервере в том же дата-центре. Для сайтов, работающих в Украине, разумно держать одну копию в другой стране: она остаётся доступной, когда недоступна украинская инфраструктура.

Копия, из которой ни разу не восстанавливались, — ещё не копия, а файл. Проверка простая: развернуть её на тестовом домене и открыть сайт. Делать это регулярно и после каждого изменения схемы копирования. Настройка копий вместе с тестовым восстановлением описана на странице резервных копий с проверкой восстановления.

И честная граница частоты: копия раз в сутки означает, что в худшем случае теряются изменения за сутки. Для блога это мелочь. Для магазина — заказы этого дня, которые придётся собирать из писем и платёжных систем.

DNS и домен отдельно от хостинга

Если DNS-зона живёт не у хостера, а у регистратора или отдельного DNS-провайдера, после аварии сервера достаточно изменить один IP-адрес. Независимо от того, где зона, храните у себя её экспорт — текстовый список всех записей. Почта для регистратора должна быть ящиком, который не зависит от вашего домена и хостинга.

Мониторинг снаружи

Монитор доступности, работающий на том же сервере, падает вместе с ним и никого не предупреждает. Проверка должна идти из другой сети, а уведомления — туда, где их увидят ночью. Как наш собственный мониторинг месяцами существовал только в документации, мы рассказывали без прикрас. Настройка внешней проверки — мониторинг доступности.

План на одну страницу

План аварийного восстановления для небольшого сайта — не корпоративный документ. Достаточно одной страницы, которую можно найти, когда сайт и почта лежат:

• где лежат копии и у кого есть к ним доступ;
• доступы к регистратору, DNS и платёжным системам, сохранённые вне сайта;
• экспорт DNS-зоны;
• перечень интеграций и задач по расписанию;
• сколько данных вы готовы потерять и сколько часов простоя выдержит бизнес.

Два последних ответа определяют всё остальное. Если допустимо потерять день и простоять день, достаточно ночной копии у другого поставщика и инструкции. Если нет — нужна вторая площадка, которую постоянно поддерживают в рабочем состоянии, а это уже другие деньги и другая сложность. Для большинства небольших магазинов разумный компромисс — первое.

Граница, о которой стоит знать

Ни одна площадка не обещает непрерывной работы, и наша тоже. У дата-центров в других странах свои риски: другая юрисдикция, оплата в валюте, поддержка на другом языке. Переезд даже с готовой копией занимает часы, а не минуты. Независимость от площадки не отменяет аварию — она делает аварию управляемой: вы знаете, откуда восстанавливаться и что именно потеряно.

Что делаем мы

Сайт агентства и наши собственные проекты работают на арендованных серверах в Германии, в Hetzner. Каждую ночь копия вывозится на отдельное хранилище того же провайдера — за пределы сервера, но не за пределы поставщика. Метрики сервера показывают нагрузку, память и диск, тревоги уходят в Telegram. Честно о границах: и хранилище копий, и мониторинг сегодня в пределах одного поставщика, так что от потери самого Hetzner нас это не страхует, а внешнего монитора из другой сети пока нет. Внешнюю проверку и копию у другого поставщика мы считаем следующим шагом, а не тем, что уже сделано. Это не гарантия непрерывности: это означает, что копия лежит вне самого сервера; после потери сервера мы восстановимся, после потери поставщика — нет. А об исчерпанной памяти, диске или недоступности сайта на работающем сервере мы узнаем из тревоги, а не от клиентов.

Если сайт уже недоступен и копия вне площадки есть, поднимем его на новом сервере — порядок работ описан на странице аварийного переноса сайта. Если сайт работает, но вы не уверены, что сможете восстановить его из текущих копий, начните с бесплатной проверки копий: посмотрим, где они лежат и можно ли из них действительно восстановиться.