Сайт после сбоя Beget: как вернуть доступ и не потерять заявки
Кибератака 2 ноября нарушила работу инфраструктуры Beget; провайдер продолжает восстановление, а владельцам сайтов нужно решить, как вернуть доступ и сохранить поступающие обращения. Практические советы приводит «Соловей.Инфо». Об этом пишет сайт Самара онлайн 24.
Сначала проверяют архив и доступ к домену. Иногда хватает страницы с контактами, но для полноценного возврата понадобится перенести всю CMS. Владельцу стоит уточнить, кто ведёт домен, почту, DNS и сам сайт, а также определить дату последней проверенной копии. Для типовой CMS нужны код, база данных и загруженные файлы; скачанные страницы или изображения этот набор не заменят.
Готовность инфраструктуры Beget отражается в хронологии провайдера, но состояние конкретного сайта проверяют отдельно. Если перерыв в работе приемлем, можно дождаться возврата сервиса и запросить у поддержки доступ к резервным копиям. Когда посетителям срочно нужен контакт, на стороннем сервисе размещают статичную страницу и честно описывают на ней ограниченный режим. Корзину, закрытый кабинет и автоматическую запись она не вернёт.
Проект с внешним бэкапом разворачивают на другой площадке, даже когда к старому серверу нет доступа. Как только прежнее размещение заработает, редактирование там запрещают и выгружают свежий согласованный набор. Если копии нет, проверяют диски разработчика, собственные хранилища и возможности службы поддержки. Изменения, не попавшие в архив, восстановить нельзя.
Менять регистратора необязательно; при работающих DNS можно поправить адрес сайта, а перед сменой NS подготавливают всю зону. Для доменов .ru, .рф и .su, зарегистрированных у Beget и работающих на его NS, провайдер создал специальную форму. В остальных ситуациях звонят своему регистратору либо DNS-оператору. TTL означает, сколько ответ хранится в кэше, а не обязывает ждать целые сутки; ответы из кэша порой продолжают работать, поэтому доступность проверяют из разных сетей, не смешивая NS разных компаний и не воспринимая пару произвольных A-записей как гарантию от сбоя.
Перед переключением новый сайт проверяют под обычным доменом через локальный файл hosts: формы, вход, изображения, страницы и HTTPS. Почтовый сервис переносят отдельно; когда он не меняется, сохраняют MX-записи и данные проверки отправителя, а копию готовят и проверяют заранее. На старой копии останавливают приём заявок, фоновые записи и редактирование, а база для работы остаётся единственной. Прежние настройки сохраняют для возврата, но если придётся откатываться, берут в расчёт заявки, которые уже пришли на новую площадку; после запуска создают резерв и проверяют восстановление из него.
