Сбой хостинга — это когда сайт перестал открываться, а причина находится на стороне сервера, домена или аккаунта у провайдера. Ниже порядок действий: что проверить в первые минуты, откуда взять копию данных, если своего архива нет, и как убедиться, что после восстановления работают заказы, письма и обмен с 1С. План подходит и для визитки на WordPress, и для магазина на «1С-Битрикс», и для самописного сервиса на VPS.
Что проверить в первые 15 минут после сбоя?
Откройте сайт в режиме инкогнито и посмотрите код ответа. Ошибки 500 и 502 говорят о проблеме внутри сервера, 403 означает спор с правами доступа, страница «аккаунт заблокирован» намекает на биллинг. Если сайт открывается по IP-адресу, но не по домену, смотрите на DNS.
Дальше три быстрые проверки, которые закрывают большинство случаев:
- Статус услуг в личном кабинете провайдера. Просроченный платёж убирает сайт целиком, а после оплаты аккаунт иногда поднимают вручную через поддержку.
- Свободное место на диске и лимиты тарифа. Переполненный диск останавливает запись в базу, и страницы с данными начинают отдавать ошибку.
- Срок действия домена и SSL-сертификата. Истёкшая регистрация уводит посетителя на заглушку регистратора, и хостинг здесь ни при чём.
Когда все три пункта в порядке, а сайт лежит, переходите к диагностике внутри сервера: логи веб-сервера, логи CMS, свободная память, состояние процессов.
Пошаговый план восстановления
Действуйте по порядку. Переустановку «с нуля» оставьте на крайний случай: она стирает логи и последние данные.
- Зафиксируйте симптомы. Скриншот ошибки, время, что менялось перед сбоем: обновление CMS, установка модуля, переход на другой тариф. Эта деталь экономит час поиска.
- Проверьте доступ к серверу. Панель управления, SSH, файловый менеджер. Доступ есть, значит причину ищем внутри. Доступа нет — вопрос к провайдеру.
- Соберите все копии, которые существуют. Свой архив, бэкап хостинга, дамп базы от разработчика, файлы на рабочем компьютере. Запишите дату каждой копии.
- Восстановите файлы, затем базу. Сначала файлы возвращаются на место, потом импортируется база. Так проще откатить шаг, если что-то пойдёт не так.
- Проверьте подключение к базе. Логин, пароль и имя базы прописаны в конфигурационном файле. После смены тарифа или переезда провайдер меняет эти данные, и сайт не запускается именно из-за них.
- Проверьте то, что не видно снаружи. Отправку писем, приём заказов, оплату, обмен с 1С, уведомления в CRM. Копирование файлов и базы идёт быстро, а на эти проверки уходит основное время.
- Верните мониторинг. Сервис доступности напишет в мессенджер, если сайт снова перестанет отвечать.
Как проверить, что сайт восстановлен полностью
Пройдите по списку, а не по ощущению «вроде открывается»:
- Главная и пять-десять внутренних страниц, включая карточку товара и страницу категории.
- Вход в админку. Если доступ пропал, причины обычно те же: пароль, блокировка аккаунта хостингом или подменённый файл авторизации после вируса.
- Формы заявок, корзина, тестовое оформление заказа.
- Письма клиенту и менеджеру, восстановление пароля.
- Платежи и обмен с 1С, если они подключены.
- Адреса страниц и редиректы. После развёртывания старой копии часть URL может отдавать 404.
- Карта сайта и robots.txt. Их стоит перегенерировать, чтобы поисковики быстрее увидели актуальные версии страниц.
Отдельный случай — сайт на VPS не поднимается сам после перезагрузки. Причина часто в автозапуске служб, разбор этой ситуации есть в статье почему после перезагрузки VPS не работает сайт.
Где взять бэкап, если своего архива нет?
Копии обычно лежат в четырёх местах, и у каждого свои ограничения.
| Источник копии | Что даёт | Ограничения |
|---|---|---|
| Автоматические бэкапы хостинга | Файлы и база на определённую дату, восстановление через панель | Глубина хранения задана тарифом, более старые состояния недоступны |
| Свой архив на VPS или внешнем диске | Полный контроль, восстановить можно в любой момент | Нужно настроить, проверить и поддерживать самостоятельно |
| Дамп базы от подрядчика | Спасает, когда файлы целы, а данные потеряны | Подрядчик может быть недоступен, доступы остались у него |
| Ручная копия на компьютере | Быстро достать, если архив свежий | Заявки и заказы за пропущенный период теряются |
Предсказуемее всего собственный бэкап на отдельном сервере, а не на том же диске, где живёт сайт. Как это устроить, разобрано в материале пошаговая настройка резервного копирования на VPS.
Сколько времени занимает восстановление?
Срок зависит от четырёх вещей, и три из них вы контролируете заранее.
- Свежесть копии. Бэкап за вчера означает потери в несколько часов, бэкап за месяц — ручное сведение заказов и заявок.
- Размер сайта и базы. Каталог на несколько тысяч товаров с изображениями поднимается дольше, чем лендинг.
- Тип проекта. Статичный сайт запускается быстрее, чем магазин с обменом с 1С и внешними платежами.
- Доступы. Когда пароли от панели, DNS и конфигов под рукой, работа идёт без остановок. Когда они у прежнего подрядчика, добавляются дни переписки.
По опыту переноса проектов на «1С-Битрикс» четыре технических действия — копия файлов, копия базы, правка подключения к базе и переключение DNS — занимают меньше времени, чем проверки после них. Именно на проверках ловятся потери заказов, писем и обмена с 1С.
Типичные ошибки при восстановлении сайта
- Разворачивать копию поверх рабочей системы, не сохранив текущее состояние. Если бэкап окажется старее нужного, откатиться будет некуда.
- Держать копии на том же сервере. Сбой диска или блокировка аккаунта забирает и сайт, и архивы.
- Проверять только главную страницу. Формы, письма и обмен данными ломаются чаще, чем вёрстка.
- Не менять пароли после взлома. Вредоносный скрипт возвращается вместе с восстановленными файлами.
- Забыть про DNS. При переезде на другой сервер старые записи живут в кэше ещё несколько часов, и часть посетителей видит прежнюю версию сайта.
- Восстанавливать в разгар рабочего дня без предупреждения. Клиенты видят ошибку, а поддержка получает десяток одинаковых вопросов.
Что подготовить заранее, чтобы сбой прошёл спокойно
Три вещи закрывают почти все риски. Регулярный бэкап на отдельный сервер, причём раз в квартал стоит проверять, что из копии действительно поднимается сайт. Документ с доступами: панель хостинга, DNS, админка, база, регистратор домена. Мониторинг доступности, который замечает падение раньше клиентов.
Полезно держать отдельный тестовый контур и следить за состоянием самого сервера. Логи, временные файлы и старые копии постепенно съедают диск, а переполненный диск останавливает запись в базу. Что и как чистить, описано в разборе как найти и удалить мусор на VPS, замедляющий сайт.
Если разбираться с тарифами, провайдерами и резервным копированием нет времени, эти задачи берут на себя: на inRB.by помогают сравнить провайдеров, подобрать сервер под нагрузку и выстроить защиту данных.
3 шага, которые можно сделать на этой неделе:
- Проверить, когда сделан последний бэкап и где он лежит. Если копия на том же сервере, перенести её на другой носитель.
- Выписать в один документ доступы от панели хостинга, DNS, админки, базы и регистратора домена, затем проверить, что пароли рабочие.
- Развернуть копию на отдельном тестовом адресе и замерить, сколько времени занимает восстановление.
