TL;DR. 2 ноября сервер моей соцсети «Агора» на Beget перестал отвечать. 3 ноября хостинг подтвердил: данные VPS обнулены, бинарные бэкапы потеряны. Меня спасли три вещи: зашифрованные офсайт‑бэкапы базы, которые я настроил за день до аварии; escrow‑ключ для личных сообщений, заложенный в схему ещё раньше; и скрипты переезда, которые я успел написать в репозитории. Агора открылась на новом сервере примерно через 3 часа после того, как Beget подтвердил потерю. Цена: примерно сутки данных и несколько граблей, о которых расскажу ниже. Главная моя ошибка: мастер‑ключ шифрования лежал только в окружении серверного процесса и в бэкап не входил.

Коротко для тех, кто не читал прошлые статьи

Я Арсений, единственный разработчик «Агоры», российской соцсети для учеников, учителей и студентов. В первой статье я рассказывал, как написал её с нуля, во второй разбирал комментарии и то, что изменилось за три месяца. Сейчас пользователей около 200, и всё так же без единого рубля на рекламу.

Стек, чтобы было понятно, что именно падало:

• React + TypeScript + Vite, статика сайта лежит на обычном хостинге (jino);

• self‑hosted Supabase (Postgres 17) в Docker, рядом Bun‑сервисы под PM2 и Caddy в Docker;

• личные сообщения с E2E‑шифрованием;

• Android‑приложение на Expo / React Native;

• медиа в Яндекс Object Storage.

Весь бэкенд жил на одном VPS у Beget. Спойлер: это была главная архитектурная ошибка, и в выводах я к ней вернусь.

Хронология

• 01.11: днём я настроил офсайт‑бэкапы базы: pg_dump → GPG‑шифрование → Яндекс S3, недельные и месячные копии. Последняя копия сделана 01.11 в 03:00 UTC.

• 02.11: сервер перестал отвечать: SSH сбрасывает соединение, API молчит. Статика сайта на другом хостинге жива. Позже выяснилось, что это кибератака на Beget (новость на Хабре).

• 03.11, около 15:10 UTC: Beget подтвердил, что данные VPS, S3 и K8s обнулены, бинарные бэкапы VPS потеряны, остались только файловые. Совет один: сменить все ключи.

• 03.11, около 18:00 UTC: Агора снова открыта на новом сервере.

В копии, с которой я поднимался: 203 пользователя, 1030 постов и около 1800 личных сообщений. Всё, что случилось после 03:00 UTC 01.11, потеряно, то есть примерно сутки.

Бэкап базы: настроил за день до аварии (повезло)

Я давно знал, что копия «на том же сервере» на самом деле не копия. Скрипт после ночного дампа шифрует его GPG (на сервере лежит только открытый ключ, закрытый у меня) и кладёт в Яндекс S3: воскресные копии храню 4 недели, копии первого числа 6 месяцев.

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

А вот настройки сервера в бэкап не входили. Ни .env, ни конфиги Caddy, ни compose‑файлы. Это оказалось самым болезненным, об этом дальше.

Мастер‑ключ потерян, личные сообщения нечитаемы

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

В итоге база есть, а все приватные ключи превратились в набор нечитаемых байтов. Вся старая переписка нечитаема. Это моя ошибка.

Выручило то, что в схему заранее был заложен escrow: к каждому зашифрованному сообщению прилагается копия, которую открывает ключ оператора. Этот ключ хранился у меня локально, отдельно от сервера. Это был «план Б», в который я, честно говоря, не очень верил.

Я написал скрипт, который работает целиком на моём компьютере (ни тексты сообщений, ни escrow‑ключ никуда не уходят):

1. читает выгрузку шифротекстов и состав диалогов из копии базы;

2. генерирует новую пару ключей каждому из 203 пользователей, приватную часть оборачивает новым мастер‑ключом;

3. расшифровывает каждое сообщение через escrow;

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

5. каждое новое сообщение проверяет обратной расшифровкой;

6. пишет SQL одной транзакцией, который я применяю на сервере до запуска сервиса ключей с новым мастер‑ключом.

Спойлер: Упрощённая логика скрипта (без ключей)

for (const msg of data.messages) {
  const text = await decryptEscrow(msg.escrow_content);   // ключ оператора, только в памяти
  const members = membersOf[msg.conversation_id];

  if (members.length === 2) {
    content = await encryptForPair(text, sender, peer);    // на пару ключей
    assert(await decryptAsPeer(content) === text);        // проверка с обеих сторон
    assert(await decryptAsSender(content) === text);
  } else if (members.length === 1) {
    content = await encryptForOne(text, members[0]);      // на ключ единственного участника
    assert(await decryptAsOwner(content) === text);
  } else continue;                                        // диалог без участников

  sql.push(updateMessage(msg.id, content));
}

Сначала я полностью прогнал скрипт на копии базы: ошибок не было. Только после этого пошёл боевой прогон.

Результат: новые ключи получили 160 пользователей, восстановлено 1218 сообщений, ещё 44 лежали в пустых диалогах (из них не осталось ни одного участника), ошибок 0. Клиенты сами замечают новый публичный ключ в профиле и забирают новый приватный из сервиса ключей.

Раз я писал про E2E в прошлых статьях, скажу про escrow отдельно. Escrow это компромисс, и делать вид, что его нет, я не буду. Он ослабляет идею «сервер ничего не может прочитать», зато именно он вернул людям переписку. Если у вас так не устроено, храните мастер‑ключ хотя бы в нескольких местах офлайн.

Новый сервер: переехал по скриптам из репозитория

Я арендовал VPS в Санкт‑Петербурге: 2 vCPU, 4 ГБ, 50 ГБ. План переезда и скрипты я написал ещё 02.11, пока ждал ответа от Beget, поэтому разворачивание шло по списку:

Все ключи Supabase (JWT‑секрет, anon‑ и service‑ключи, пароль базы) пришлось сделать новыми: старые значения лежали на уничтоженном сервере. Из‑за этого появилась первая проблема.

Старые сборки приложения получали 401, починил в Caddy

Публичный anon‑ключ был вшит в уже вышедшие сборки Android‑приложения и в другие мои проекты. JWT‑секрет утерян, ключ теперь новый, и старые клиенты получали 401. За первые три часа набралось 106 неудачных входов по OTP. Обновление по воздуху (OTA) до людей со старыми сборками не доходило.

Решение: Caddy подменяет старый ключ на новый в заголовках apikey и Authorization и в query‑параметре (так подключаются websocket‑ы Supabase Realtime):

@old_apikey header apikey {$OLD_ANON_KEY}
request_header @old_apikey apikey {$ANON_KEY}

@old_bearer header Authorization "Bearer {$OLD_ANON_KEY}"
request_header @old_bearer Authorization "Bearer {$ANON_KEY}"

@old_ws query apikey={$OLD_ANON_KEY}
uri @old_ws query apikey {$ANON_KEY}

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

Веб‑пуши умерли, Android‑пуши отправил вручную

Новые VAPID‑ключи значит старые подписки мертвы, браузеры переподписываются при следующем входе. Пуши в Android я разослал прямо с сервера по токенам устройств из офсайт‑копии (Expo‑токены от наших ключей не зависят).

Экран «технические работы» не показывался (завис ≠ упал)

Флаг тех. работ лежит отдельно, как status.json на статик‑хостинге, и задумано это было ровно на такой случай. Но экран не показывался. Причина в том, что сервер не упал, а завис. Запрос в базу без таймаута держал загрузку минутами, а флаг проверялся вместе с этим запросом.

Исправил так: AbortSignal на 8 секунд на запрос в базу, а если во флаге enabled: true, экран показывается сразу, не дожидаясь базы. Вывод: таймауты нужны везде, особенно в проверках «всё ли в порядке».

Мониторинг дважды промолчал

У меня была внешняя проверка доступности в GitHub Actions раз в час. Во время аварии она дважды не прислала алерт:

• code=$(curl ...) под bash -e падал на таймауте (код 28), и шаг умирал вместо отправки уведомления. Лечится || true;

• четыре проверки с повторами не влезали в timeout-minutes.

Исправленный кусок:

check() {
  for i in 1 2; do
    # || true: при таймауте curl выходит с ошибкой, и без этого
    # bash -e ронял весь шаг вместо уведомления
    code=$(curl -s -m 10 --connect-timeout 8 -o /dev/null -w '%{http_code}' "$2" || true)
    [ "$code" -ge 200 ] && [ "$code" -lt 500 ] && return
    sleep 10
  done
  echo "• $1 (код $code)" >> problems.txt
}

Ещё заметил, что GitHub‑cron срабатывал заметно реже, чем раз в час. Как единственная защита этого мало, но как внешняя проверка лучше, чем ничего.

Деплой не работал, потому что раннер стоял на упавшем сервере

Деплой шёл через self‑hosted раннер GitHub Actions, который стоял на самом сервере. Сервер лёг, и деплоить стало нечем. Я добавил в deploy.yml входной параметр runner: по умолчанию self‑hosted, но в аварию можно запустить на ubuntu-latest. Заливка с GitHub‑раннеров по FTP ловила таймауты хостинга, поэтому для неё я заменил FTP‑экшен на lftp mirror (заливка занимает около 15 минут).

Звонки: TURN‑сервер тоже был на Beget

Звонки 1-на-1 (WebRTC) требуют TURN‑сервера для пользователей за NAT. Мой TURN тоже стоял на Beget и тоже был уничтожен. Какое‑то время при нажатии на звонок показывалось сообщение «временно не работают» (флаг лежит в базе, чтобы клиенты не пытались соединяться зря).

Потом я поднял coturn на основном сервере. Раз он теперь делит машину с Supabase, ограничений пришлось добавить побольше:

• слушает только публичный IP;

• квоты на сессии и ограничение скорости;

• запрещён relay на приватные и служебные диапазоны (защита от SSRF через TURN и от доступа к docker‑сетям Supabase);

• без TCP‑relay и без CLI;

• ограниченный диапазон relay‑портов.

Креды выдаются по схеме TURN REST: временное имя <время жизни>:<id пользователя> и пароль как HMAC от него. Эндпоинт сначала проверяет токен пользователя. Проверка через релей между разными сетями: около 115 пакетов в секунду в каждую сторону.

Ещё одна ловушка: TTL кредов я поднял до 8 часов, иначе звонок через релей обрывается, когда протухают креды.

Telegram‑алерты с нового сервера: IPv6 не доступен, HTTP/2 виснет

С нового сервера Telegram по IPv6 недоступен, а POST по HTTP/2 просто висел. Помогло curl -4 --http1.1. Сами алерты это скрипт, который каждые 5 минут проверяет диск, память, PM2, контейнеры, API и свежесть бэкапа и пишет сообщение только при смене состояния.

Мелочи, которые вылезли позже

• Ссылки на старый CDN‑домен в базе (в постах, комментариях, группах) переписал на новый, остатков не осталось.

• Модель NSFW‑проверки лежала только на старом сервере. После переезда проверка загрузок молча не работала: ни ошибки, ни предупреждения. Скачал модель заново, и сервис написал «модель загружена». Тихие отказы самые неприятные.

• Платёжный магазин в ЮKassa оказался другим, чем в моих старых записях: на «старых» данных приходил 401. Разобрался, и платежи заработали.

Выводы

1. Ключи шифрования и .env надо класть в зашифрованный офсайт‑бэкап, а не держать только в окружении процесса. Теперь отдельный скрипт собирает все .env, конфиги Caddy и compose‑файлы в GPG‑архив и отправляет в облако.

2. Бэкап, который не проверяли восстановлением, не бэкап. Мне повезло, что я успел проверить хотя бы базу. Но проверял только её, а про мастер‑ключ так и не спросил себя «а что, если его нет?».

3. Скрипты переезда надо хранить в репозитории. Не «я помню, как это делается», а bootstrap.sh и README с порядком шагов и списком подводных камней. Например, подсеть Docker для Supabase пришлось создавать вручную с конкретным диапазоном: триггеры в базе шлют вебхуки на фиксированный адрес шлюза.

4. Мониторинг не должен жить на том же хосте, что и проверяемое. Раннер, алерты, проверки здоровья должны переживать падение основного сервера.

5. Таймауты везде: запросы к базе, curl, джобы Actions. Зависший сервер хуже упавшего.

6. Один провайдер это одна точка отказа. Это известная истина, но «хостинг большой, с бэкапами» оказался слабым аргументом: бинарные бэкапы VPS пропали вместе с самим VPS.

7. У E2E должен быть «план Б» (escrow или несколько офлайн‑копий мастер‑ключа), иначе одна потерянная переменная окружения стоит всей переписки.

Цифры на сегодня

• ~3 часа от подтверждения потери данных до открытой Агоры;

• ~сутки данных потеряно (копия от 01.11, 03:00 UTC);

• 203 пользователя, 1030 постов в копии;

• 1218 личных сообщений восстановлено, 0 ошибок;

• 106 неудачных OTP‑входов со старых сборок за первые три часа.

Что дальше

Осталось много уборки: часть настроек (например, конфиг coturn) всё ещё не входит в автоматический бэкап, и при следующем переезде мне придётся воссоздавать его по заметкам. TLS для TURN не настроен, клиенты откатываются на обычный порт. И я хочу, наконец, вынести мониторинг на отдельный сервер, чтобы он не падал вместе с остальным.

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

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

Ссылка на проект, социальную сеть для учеников, учителей и студентов: agorasocial.ru.