Сайт и база уничтожены за один день: что проверить, чтобы с вами этого не случилось

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

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

Что мы увидели у своих клиентов

На пострадавшем хостинге работали около 15 проектов десяти наших клиентов. Сайты остановились у всех одновременно, а дальше пути разошлись.

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

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

Хуже всего пришлось тем, кто не был у нас на поддержке и не делал бэкапы сам. Их сайты до сих пор не работают, а данные пока не получены.

Разница между этими тремя группами — не в технологиях и не в бюджете. Она в одном: была ли у сайта копия за пределами пострадавшего хостинга.

Бэкап, который действительно спасает

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

Копий несколько

Одна свежая копия — это одна точка отказа. Нужны копии за разные даты: если проблему заметили не сразу (например, вирус или порча данных), последняя копия может уже содержать ошибку.

Хотя бы одна копия — вне основной инфраструктуры

Не у того же хостера, не в его облаке и не на соседнем сервере того же провайдера. И доступ к ней — не с тех же логинов и паролей. Злоумышленник, получивший доступ к панели хостинга, не должен одним действием удалить и сайт, и все его копии.

Восстановление проверено

Копия, из которой никто ни разу не пробовал поднять сайт, — это надежда, а не бэкап. Архив может оказаться неполным, без базы данных, без загруженных файлов или в формате, который не разворачивается на другом сервере. Проверять это стоит заранее, а не в день аварии.

Понятно, сколько вы готовы ждать

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

Не всё в одной корзине: раздельная инфраструктура

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

Мы считаем правильной такую схему:

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

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

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

Короткий чек-лист: что ещё проверить

Бэкапы — главное, но не единственное. Ниже пункты, которые мы проверяем у клиентов на поддержке. Если хотя бы по одному из них вы не знаете ответа — это повод разобраться.

1. Резервные копии. Есть ли копия вне хостинга, когда она сделана, когда последний раз проверяли восстановление.
2. Двухфакторная аутентификация. Включена ли на всех ключевых сервисах: регистратор домена, хостинг, почта, админка сайта, Яндекс ID, платёжные кабинеты. Подтверждение по SMS — самый слабый вариант; надёжнее приложение-аутентификатор или аппаратный ключ.
3. Пароли. Разные для разных сервисов, хранятся в менеджере паролей, меняются при увольнении сотрудника и смене подрядчика.
4. Права доступа. У каждого сотрудника и подрядчика — своя учётная запись, а не общий «admin». Прав — ровно столько, сколько нужно для работы. Доступы ушедших людей отозваны.
5. Обновления. Устаревшие версии PHP, CMS и модулей не получают исправлений безопасности — это одна из самых частых дверей для взлома.
6. Мониторинг. Узнаёте ли вы о том, что сайт не работает, раньше клиентов.

Эта статья — о том, что сделать до проблемы. Если сайт уже взломан или заражён, читайте статью «Внимание, вирус! Что делать, если сайт заражён».

Что мы делаем для клиентов на поддержке

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

Если бэкапа не оказалось

Если сайт уже пропал, а своей копии нет, шансы вернуть хотя бы часть всё равно есть. Порядок действий такой:

1. Спросите хостинг. Напишите в поддержку, остались ли у них резервные копии вашего аккаунта. Если копия есть, сайт вернётся целиком — с базой, формами и админкой.
2. Спросите разработчика. У студии или фрилансера, который делал или дорабатывал сайт, может остаться рабочая или тестовая копия.
3. Проверьте веб-архив. Откройте и введите адрес сайта. Если там есть снимки за последние месяцы, по ним можно восстановить тексты, структуру страниц, картинки и внешний вид.

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

Вопросы и ответы

• У хостинга есть бэкапы в панели. Этого недостаточно?

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

• Как часто нужно делать резервную копию сайта?

  Зависит от того, как часто меняются данные и сколько вы готовы потерять. Если на сайте идут заявки и бронирования каждый день, копия раз в неделю означает потерю до недели работы.

• Можно ли хранить бэкап у себя на компьютере?

  Можно как дополнительную копию. Но компьютер тоже ломается, а копия на нём быстро устаревает, если её не обновлять автоматически.

• Сколько времени занимает перенос сайта на другой хостинг из бэкапа?

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

• Если хостинг крупный и надёжный, зачем всё это?

  Потому что этот хостинг тоже был крупным и надёжным. Размер провайдера снижает вероятность аварии, но не отменяет её.