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