Затемнённое изображение с силуэтами страниц и крупными номерами 502 и 503, текст нечитаем
О компании

Атака на Beget: как мы за два дня восстановили сайт и два сервиса

Опубликовано

Время чтения

8 мин

Beget потерял данные облачных серверов: под удар попали сайт студии, sozdai.art и управленческие дашборды. Рассказываю, что уцелело, как искали 1827 изображений по компьютеру и веб-архивам и почему два дня с ИИ не отменяют нормальные бэкапы.

Меня зовут Алексей Гусев, я основатель и генеральный директор студии АРТэврика.

Что случилось

Утром 2 ноября перестал работать наш сервис sozdai.art. Сотрудник написал: «не могу работать» — и это было первое, что я узнал об атаке.

Я написал ИИ-агенту и получил ответ: сервер недоступен. Панель управления Beget, где размещалась инфраструктура, тоже не открывалась. В официальном канале хостера уже висела новость о кибератаке.

Проверил artevrika.ru. Сайт студии не работал.

Масштаб: это коснулось не только нас

По сообщению Beget, злоумышленники получили доступ к управляющему контуру инфраструктуры и запустили обнуляющие скрипты. Компания сообщила о потере данных облачных сервисов, включая виртуальные серверы и файловое хранилище S3.

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

Самое тревожное было с резервными копиями. Бинарные бэкапы виртуальных серверов оказались утрачены. Шестого ноября компания уточнила: файловые копии, по актуальной оценке, будут доступны только половине пользователей VPS.

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

Что упало у нас и что уцелело

Недоступными оказались три проекта: сайт студии, sozdai.art и управленческие дашборды.

Прихожая с овальными зеркалами в пол, тёмными стенами, дверью и консолью, фронтальный ракурс
Интерфейс сайта студии дизайна с баннером об архитектурной идее и карточками моделей для изображений

На стороне Beget безвозвратно потеряны базы данных PostgreSQL: вероятность восстановления оценивали в 50%. Файлы в S3 утрачены полностью.

Исходный код сохранился в моих репозиториях. Но из одного кода работающий проект не восстановить — нужны данные, которыми приложения наполнялись во время работы.

Дальше всё зависело от того, что сохранилось за пределами Beget.

Управленческие дашборды поднялись быстро: их основная база жила в Notion. Приложения стояли на пострадавшей инфраструктуре, а данные остались целы.

Для сайта нашлась локальная копия базы от 16 октября. Перед выкатом большого обновления транскрибации анкеты клиента я сделал бэкап — именно для сайта студии. Он вернул страницы, описания проектов и связи между материалами. Более поздние изменения пришлось проверять отдельно; в итоге это оказалась одна статья про AirWet, которую я написал заново.

Для Sozdai такой копии не было. Его восстановление шло параллельно и отдельно.

План вместо паники: 70 пунктов и 9 этапов

Тёмная панель контроля переноса сайта на новый сервер: шкала готовности 93 % и список этапов с подпунктами

Код у меня был. Значит, можно было поднять новые серверы и запустить приложения заново. Дальше предстояло понять, какие данные сохранились независимо от Beget.

С ИИ-агентом я собрал интерактивный план-дашборд восстановления сайта: 70 пунктов, разделённых на 9 этапов. За одной галочкой стояло восстановление базы, за другой — подготовка сервера, ротация API-ключей, проверка форм, возврат изображений. Часть задач нельзя было закрыть, пока не готовы предыдущие.

Второй дашборд был реестром изображений. Мне нужно было видеть прогресс поиска, источник каждого файла, его качество, привязку к проекту и к конкретной зоне интерьера.

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

Библиотечный каталог без книг: 1827 записей

Рабочая зона с деревянным столом, ноутбуком и чёрным креслом у окна, встроенные шкафы

В реестре сайта было 1827 записей медиа.

Локальная база помнила названия файлов, размеры и места, где они использовались. Самих изображений в ней не было: они хранились в потерянном S3.

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

Я собрал отдельный интерактивный реестр: в нём можно было отфильтровать найденные и отсутствующие файлы, посмотреть привязку к проектам, открыть конкретный интерьер и увидеть пробелы.

Так я контролировал поиск глазами: вот проект, вот его фотографии, вот пустое место. Появилась находка — открываю, сравниваю с соседними кадрами, проверяю, откуда она взялась.

Где искали изображения

Основную поисковую работу делала модель. Она перебирала папки и файлы на компьютере, загрузки, старые архивы и экспорты. Искала материалы на старой Тильде и в публикациях проектов в интернете.

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

В такие моменты хочется верить фразе «интернет помнит всё». На практике сохранилось далеко не всё: где-то не было страницы, где-то остался текст без картинок. Но даже неполные снимки давали зацепки.

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

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

Перцептивный поиск: как модель узнавала кадр

Скриншот статьи о перцептивном поиске: чек-лист этапов и раздел По шагам на тёмном фоне

Во время восстановления я впервые узнал термин «перцептивный поиск».

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

На сайте используются webp и avif, на компьютере — png. Модель сама конвертировала кандидатов с нужными настройками, получала вес файла с допустимой погрешностью и подтверждала: это тот самый файл.

После отбора кандидатов она сравнивала содержимое и учитывала контекст проекта. Та ли это комната? Тот ли ракурс? Как кадр соотносится с фотографиями рядом, относится ли к той же съёмке?

Соседние изображения тоже становились подсказками. По отдельной картинке не всегда понятно, откуда она. Рядом с другими кадрами — проще: видно, к какому интерьеру и к какой его части она относится.

Перцептивное сравнение отбирало похожие варианты, а модель сопоставляла их с уже известными материалами проекта. Так находились файлы, которые по одному названию я бы уже не опознал.

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

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

Предел возможностей ИИ

Когда я строил сайт, я сразу решил, что он будет AI-native: внутри работают LLM-модели, а внешние агенты могут подключаться и помогать с контентом. При восстановлении это сыграло: каждое изображение описано и размечено, поэтому модель понимала, что именно ищет.

Но ИИ работал только с тем, что где-то сохранилось. Код, локальная база сайта, данные в Notion, файлы на компьютере, веб-архивы и старые публикации дали материал. Если файл исчез отовсюду — модель его не вернёт.

Работа делилась просто. Агенты искали материалы, сравнивали изображения, писали скрипты и разбирались с ошибками. Я приносил исходники, принимал решения и проверял результат через дашборды.

Выкат: 11 995 файлов и семь заглушек

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

Модель писала и выполняла скрипты для этой работы. В новом хранилище получилось 11 995 файлов с учётом производных версий.

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

Когда всё было собрано, я выкатил сайт на новый сервер. Он открылся сразу, и всё заработало.

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

После проверки я переключил домен с временной Тильды на восстановленную версию. Управленческие дашборды к тому времени уже работали, Sozdai восстановили днём раньше.

Что я изменил в подходе к бэкапам

После этой истории я иначе смотрю на резервное копирование.

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

Если IT стало важной частью бизнеса, его сохранность нельзя оставлять на уровне «у хостера вроде есть бэкапы».

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

История с Notion — самый наглядный пример. Данные дашбордов были за пределами пострадавшей инфраструктуры, поэтому восстановление прошло быстро. С сайтом пришлось собирать фотографии по папкам и старым публикациям.

Notion тоже требует резервного копирования. Но в этот раз отдельное место хранения уберегло меня от ещё одной большой работы.

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

И проверять восстановление. Пока я не запустил проект из копии, я не знаю, что она меня выручит.

Коротко

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

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

Если вы тоже пострадали от этой атаки — напишите, помогу с восстановлением или проконсультирую.