Третий час ночи, 2 ноября. Я открыл панель Beget и получил бесконечную загрузку. Сайты клиентов в соседней вкладке отдавали 502 Bad Gateway. Минут пять я по старой привычке искал проблему у себя.
Что случилось с Beget
Первые сбои мониторинги зафиксировали около 3:00 по Москве. Жалобы пошли из 33 городов, чаще всего из Москвы, Петербурга, Московской и Самарской областей. Отказ был полный: не отвечали панель управления и личный кабинет, лежали виртуальный хостинг, VPS, почтовые серверы и DNS.
За сутки мониторинги насчитали около 7,5 тыс. жалоб, Downdetector к вечеру показал больше 9,8 тыс. Масштаб понятен из одной цифры. Beget работает с 2007 года и обслуживает больше 200 тыс. клиентов. На октябрь у него размещалось более 334,5 тыс. действующих сайтов в зонах .ru, .рф и .su. Это 14,6% всех работающих сайтов рунета, больше, чем у Reg.ru и Timeweb.
Вечером 2 ноября провайдер признал массированную кибератаку и объявил обстоятельства непреодолимой силы. 3 ноября компания сообщила, что виртуальный хостинг полностью выведен из строя. Для восстановления нужно вручную проверить больше 1000 серверов на скрытые уязвимости и шпионский софт. Часть резервных копий для быстрого восстановления уничтожена, остались только «медленные» бэкапы. В тот же день BFM опубликовал заявление Beget: полного восстановления данных не будет.
Почему это история про меня, а не про Beget
Признаваться неприятно, но я годами делал ровно то, о чём потом писали эксперты. DNS, почта, серверы и бэкапы у меня жили в одном личном кабинете. Так удобно: один логин, одна оплата, всё под рукой. Андрей Мишуков из iTPROTECT описал эту схему точно. Компании ради удобного кабинета держат всё в одном домене отказа, а когда он падает, переключить NS-записи нечем.
Ещё не нравится, что это снова один провайдер, и надеяться на него как на последний рубеж я больше не буду
Мне тоже было нечем. Панель не открывалась, DNS не отвечал, а бэкапы лежали там же, где сайты. Получалось, что запасной ключ от квартиры хранится внутри этой же квартиры.
«Данные, существующие в одном экземпляре, не существуют вовсе». — Вадим Смирнов, «Софтайм»
Провайдер в атаке не виноват. Атакуют всех, и большого игрока с 14,6% рунета атакуют чаще. Виноват в моей ситуации я сам: я не предусмотрел, что сломаться может любое звено.
Как я перевёз четыре сайта
Переезд занял один вечер. Я собрал окружение, перенёс файлы, поднял базы, переключил DNS и выпустил сертификаты. Никакой магии, обычная работа, которую я откладывал года два.
| Что | Было (Beget) | Стало (Timeweb и не только) |
|---|---|---|
| Сайты | 4 сайта у одного провайдера | 4 сайта на своём VPS |
| DNS | У того же провайдера | На отдельном провайдере |
| Резервные копии | Там же, где сайты | Хранилище у другого провайдера и локальная копия |
| Доступ при сбое | Только через панель, которая лежит | Сайты, DNS и копии разнесены, одна авария не отключает всё |
| План действий | «Разберусь по ходу» | Записанный порядок на первые 15 минут |
Сервер скромный. На замере 10 ноября: 4 vCPU, 4 ГБ оперативной памяти, диск 29 ГБ, из них занято 21 ГБ. Стоит Ubuntu 24.04.3 LTS, виртуализация KVM, дата-центр в Санкт-Петербурге. Uptime 17 дней, с момента сборки машина не перезагружалась.
Кроме четырёх перенесённых сайтов, здесь живут nasloy.ru (287 адресов в карте сайта, 137 статей), моя CRM и ещё несколько проектов. Свободных 8 ГБ на диске мне пока хватает. Если честно, это самая тесная цифра во всей конфигурации, и её придётся увеличивать.
Честно про минусы переезда
Во-первых, вечер работы. Если у вас не четыре сайта, а сорок, вечер превращается в неделю. Делал я всё руками: волшебной кнопки «перенести с Beget» нет, а если бы и была, панель Beget всё равно не открывалась.
DNS приходится ждать. Записи обновляются не сразу, и пару часов часть посетителей видела старый адрес. К новой панели тоже надо привыкать: я дважды искал раздел, который был перед глазами.
Главный минус в другом. Переезд сам по себе ничего не решает. Timeweb могут атаковать точно так же, как Beget. Если перенести сайты и бэкапы к другому провайдеру одной кучей, получится та же проблема, просто с другим логотипом. Владислав Шелепов из «Газинформсервиса» отдельно предупредил, что вывод «всем срочно переходить к нескольким провайдерам» делать не стоит. Бэкапы надо держать отдельно и проверять, что из них действительно получается восстановиться.
Что я настроил после
Однажды сайт уже лежал, а доступа к панели не было. Это было во время сбоя Яндекса, я писал о нём и о том, что творилось со статистикой, в разборе про ИИ-ответы и клики. Второй раз я нашёл уязвимость в собственном сервисе, подробности в разборе платного доступа через cookie. Оба раза меня выручило не «настроим потом», а заранее записанный порядок действий. Теперь он есть и для хостинга:
- Бэкапы не на сервере. Отдельное хранилище у другого провайдера плюс локальная копия. Это и есть принцип 3-2-1, который советует Анатолий Сазонов из Softline: три копии, два типа носителей, одна за пределами основной площадки.
- Проверка восстановления раз в месяц. Я разворачиваю копию на чистой машине и смотрю, открывается ли сайт. Бэкап, который ни разу не восстанавливали, пока только надежда.
- Мониторинг доступности. Об отказе мне сообщает робот, а не клиент в три часа ночи.
- DNS у отдельного провайдера. Если ляжет хостинг, я смогу переключить NS-записи, а не смотреть на них через окно.
- План на первые 15 минут. На одной странице записано, куда смотреть, что проверить и кому написать. Пароли и адреса там же, но в зашифрованном виде.
Кому что подходит
Маленькому сайту или блогу хватит одного VPS и внешних бэкапов. Сайт может полежать день, если копия лежит в другом месте и вы знаете, как её поднять.
Интернет-магазину нужна схема серьёзнее: отдельный сервер и резерв у другого провайдера. Час простоя для него — это потерянные заказы, и считать их лучше заранее.
Кому-то переезжать не надо совсем. Если у вас уже есть внешние бэкапы, DNS на стороне и проверенное восстановление, сам по себе провайдер мало что меняет. Это мой опыт с четырьмя сайтами, а не исследование. У крупных проектов своя логика: географическое резервирование, договоры с SLA и отдельный человек, который отвечает за инфраструктуру. Мой опыт к ним не применим.
Куда переехал я
Я выбрал Timeweb. Выбирал по трём вещам, которые важны для статики: быстрая машина, предсказуемый KVM и дата-центр в Петербурге, ближе к моей аудитории. Рекомендую потому, что сам на нём сижу и перенёс сюда четыре проекта.
Нравится мне вот что. Сервер поднялся быстро, KVM ведёт себя предсказуемо, дата-центр в Петербурге, и 17 дней всё работает без перезагрузок. Не нравится, что к панели пришлось привыкать. Ещё не нравится, что это снова один провайдер, и надеяться на него как на последний рубеж я больше не буду. Поэтому бэкапы лежат не там.
Сегодня вечером проверьте одну вещь: где физически лежит последняя копия вашего сайта. Если ответ «там же, где сайт», откройте календарь и поставьте на субботу «восстановить из бэкапа на чистой машине». У меня такое напоминание стоит на первое число каждого месяца, в 10:00.