Beget лежит вторые сутки: что делать, если упал хостинг, и как хранить бэкапы отдельно от провайдера

В 04:50 по Москве 2 ноября Beget написал в своём канале, что у него «крупный инцидент». Через несколько часов уточнил: проблема затрагивает все уровни архитектуры, инженеры вручную настраивают инфраструктуру прямо в дата-центрах. Днём провайдер опубликовал официальное уведомление о форс-мажоре. По данным самого Beget, на его облачных серверах больше 450 тысяч сайтов.

На 3 ноября картина такая: выделенные серверы уже работают, восстановление NS-серверов провайдер называет главным приоритетом, по почте сроков нет, а когда заработает всё остальное, Beget пока не говорит. У двух моих клиентов, интернет-магазина и информационного сайта, на Beget и хостинг, и регистрация домена. У них до сих пор не работает ничего.

Обновление, 3 ноября. Причиной сбоя Beget называет кибератаку, об этом же пишет Координационный центр доменов .RU и .РФ. В комментариях своей официальной группы Beget отвечает клиентам, что правовая позиция по услугам и последствиям будет сформирована после окончания расследования.

Обновление, 3 ноября, 15:15 по Москве. Beget опубликовал разбор ситуации. По его словам, атакующие получили доступ к управляющему контуру всей архитектуры и запустили обнуляющие скрипты. Файловые бэкапы хостинга и облака сохранены, но доступа к ним пока нет: больше 1000 серверов проверяют вручную на скрытые уязвимости и вредоносные скрипты. Сайты виртуального хостинга, по предварительной оценке, удастся восстановить почти все. В облаке (VPS, S3, Kubernetes) все данные утрачены, бинарные бэкапы VPS потеряны полностью, остались файловые. Для доменов .ru, .рф и .su, зарегистрированных в Beget и работающих на его DNS, снова можно менять записи A, MX и TXT. Провайдер советует сменить все пароли и ключи доступа, которые могли храниться на его серверах.

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

Кратко. Если упал хостинг, сначала проверьте две вещи: у кого зарегистрирован домен и где лежит последняя копия сайта. Есть копия вне упавшего провайдера и доступ к регистратору: переезжайте, ждать нет смысла. Копии нет или домен у того же провайдера: остаётся временная страница с контактами и ожидание. На будущее нужна копия у другого провайдера, которую сервер сайта может записать, но не может удалить, и проверенное время восстановления из неё. Это правило 3-2-1-1-0, ниже оно разобрано вместе с кодом.

Что делать, если хостинг упал и не поднимается

Порядок действий зависит от того, к чему у вас остался доступ. Начните с домена.

Где ваш DNS и кто регистратор домена

Откройте whois своего домена (например, на сайте регистратора или любом whois-сервисе) и посмотрите два поля: регистратор и NS-серверы.

• NS-серверы у упавшего хостера, регистратор другой. Это поправимо: в панели регистратора меняете NS на работающий DNS-хостинг и заводите там записи. Сайт всё равно нужно где-то поднять, но домен вы контролируете.
• Регистратор и хостинг - одна компания. Beget, например, аккредитованный регистратор доменов .RU и .РФ. Если его панель лежит, сменить NS негде, и даже свежий бэкап быстро не поможет: сайт поднимется на новом сервере, но домен будет указывать в старое место. В такой ситуации сейчас мои клиенты. С 3 ноября Beget вернул смену DNS-записей для доменов .ru, .рф и .su на своих NS: теперь A-записью можно направить сайт на новый сервер. Управление международными доменами пока не восстановлено.

Перенос домена к другому регистратору - задача на спокойное время. Схема на будущее простая: домен у одного регистратора, хостинг у другого провайдера.

Что делать, если срок регистрации домена истекает, а регистратор лежит

Это самый неприятный случай, и в комментариях у Beget про него уже спрашивают. Правила регистрации доменов .RU и .РФ отвечают так:

• После окончания срока есть 30 дней. Это период преимущественного продления: продлить домен может только прежний администратор и только через своего регистратора. Когда период заканчивается, регистрация аннулируется (п. 4.5 и 4.9).
• Уйти к другому регистратору в этот момент нельзя. После окончания срока регистрации перенос запрещён (п. 7.8), а до него для переноса нужен код AuthInfo от текущего регистратора (п. 7.5).
• Отсчёт 30 дней может остановить Координатор. Правила позволяют ему приостановить период преимущественного продления, если регистратор бездействует, до восстановления его работы или до передачи доменов другому регистратору (п. 4.5). На 3 ноября Координационный центр сообщил, что помогает Beget восстановить инфраструктуру и готов к дополнительным мерам поддержки. Позже в тот же день Beget сообщил, что договорился с Координационным центром: домены .ru, .рф и .su с истекающим сроком не будут разделегированы и продолжат работать. Отдельного сообщения КЦ об этом пока нет.

Что сделать сейчас: посмотрите в whois дату окончания регистрации, сохраняйте подтверждения попыток продлить домен (скриншоты, письма в поддержку с датами) и, если срок уже истёк, напишите и регистратору, и в Координационный центр. На будущее продлевайте домены заранее: заявку можно подать за 60 дней до окончания срока (п. 4.4).

Сценарий 1: есть свежая копия вне хостинга

Лучший случай. Арендуете VPS или хостинг у другого провайдера, разворачиваете окружение, заливаете файлы и дамп базы, проверяете сайт по IP или через hosts, переключаете DNS. По времени ориентируйтесь на объём: крупный интернет-магазин на Битриксе с каталогом больше 100 тысяч товаров у меня переезжает примерно за рабочий день. Небольшой сайт на WordPress переезжает быстрее.

Перед переключением DNS стоит прогнать формы, корзину и оплату на новом сервере.

Сценарий 2: есть код, но нет свежей базы

Код проекта (если он лежит в Git у разработчика) поднимается заново где угодно, состояния в нём нет. Без базы данных полноценный магазин не заработает: товаров, заказов и пользователей нет. Но можно поднять временную витрину на тех же шаблонах: контакты, основные страницы, форма заявки, которая уходит на почту или в Telegram. Так рекламный трафик не уходит в ошибку соединения, пока провайдер восстанавливает сервисы.

Сценарий 3: нет ничего

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

Восстановить сайт из веб-архива можно, но только частично: Wayback Machine хранит снимки страниц, которые успел обойти, без базы данных, корзины и личных кабинетов. Для информационного сайта это способ вернуть тексты основных страниц. Совет «посмотрите кэш Google» больше не работает: оператор cache: Google отключил в сентябре 2024 года.

Почему бэкап у того же хостера не спасает

Потому что во время аварии провайдера такой бэкап недоступен вместе с сайтом. В том же уведомлении Beget пишет, что файловые бэкапы есть для подавляющего большинства ресурсов виртуального хостинга и облака, но восстановление из них из-за объёма данных «потребует длительного времени». То есть копии существуют, но пользоваться ими вы будете тогда, когда до них дойдёт очередь у провайдера.

С облаком хуже. В разборе 3 ноября Beget пишет, что данные VPS, S3 и Kubernetes утрачены, а бинарные бэкапы VPS потеряны полностью. Если копия сайта лежала в S3 того же провайдера, её больше нет.

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

Две похожие ловушки:

• Репликация вместо бэкапа. Второй сервер, на который база копируется в реальном времени, спасает от смерти диска. Но случайное удаление таблицы или шифрование данных уедут на реплику так же быстро, как любое другое изменение.
• Сервер сайта может удалять свои бэкапы. Если ключ доступа к хранилищу на боевом сервере позволяет удалять файлы, то взлом сервера означает и потерю бэкапов. Как это закрыть, ниже.

RPO и RTO: сколько данных и времени вы готовы потерять

RPO и RTO - две цифры, о которых стоит договориться с подрядчиком вместо абстрактной «надёжности»: сколько данных и сколько времени бизнес готов потерять при аварии. Обе определены в руководстве NIST по планированию на случай сбоев, SP 800-34.

• RPO (Recovery Point Objective) - точка во времени, на которую должны восстановиться данные после сбоя. Проще: сколько последних изменений вы готовы потерять. Если дамп базы делается раз в сутки ночью, а сервер упал в шесть вечера, пропали все заказы и регистрации за день.
• RTO (Recovery Time Objective) - сколько система может восстанавливаться, прежде чем это ударит по бизнесу. Сюда входит всё: скачать архив, развернуть, проверить, переключить DNS. Наличие бэкапа ничего не говорит о RTO - это видно на примере Beget, где копии есть, а сроков нет.

RPO уменьшается частотой копий. Для PostgreSQL есть способ точнее ночного дампа: непрерывное архивирование журнала транзакций (WAL) позволяет восстановить базу на любой момент после базовой копии. В архив уходят только заполненные сегменты журнала, поэтому параметром archive_timeout ограничивают, насколько старыми могут быть неотправленные данные. Документация называет разумным значение около минуты.

RTO уменьшается только одним способом: реально восстановиться из бэкапа на чистом сервере и засечь время.

Если сравнить три типичных варианта:

• Бэкап внутри хостинга. При аварии провайдера недоступен вместе с сайтом. RPO такой, как настроил хостер, а RTO такой, как получится у хостера.
• Копия у другого провайдера, защищённая от удаления. Переживает аварию основного хостинга и взлом сервера. RPO зависит от частоты копий, а RTO от отработанного порядка восстановления.
• Горячий резерв (второй сервер с автоматическим переключением). Минимальный простой, но дорого, и от удаления данных сам по себе не защищает: нужен ещё и бэкап.

Правило 3-2-1-1-0 для сайта: как это выглядит на практике

Классическое правило 3-2-1 в Veeam расширили до 3-2-1-1-0: добавили неизменяемую копию и ноль ошибок при проверке восстановления. Для обычного сайта или магазина это выглядит так:

1. Три копии. Рабочий сайт и минимум две резервные.
2. Два разных носителя. Например, бэкапы хостинга плюс объектное хранилище.
3. Одна копия вне площадки. У другого провайдера, с другим логином и другим договором, например в Yandex Object Storage.
4. Одна неизменяемая копия. Её нельзя удалить или перезаписать до истечения срока, даже имея полный доступ к серверу сайта.
5. Ноль ошибок при восстановлении. Копии регулярно проверяют пробным восстановлением.

Object Lock: копия, которую нельзя удалить

В Yandex Object Storage и в Amazon S3 неизменяемость делается через Object Lock. У блокировки три режима:

• Governance: управляемая блокировка. Пользователь с ролью storage.admin может её обойти, сократить или снять.
• Compliance: строгая блокировка. Обойти, сократить или снять её до окончания срока нельзя, можно только продлить. В Amazon S3 в этом режиме объект не удалит никто, включая root-пользователя аккаунта.
• Legal hold: бессрочная блокировка, действует до явного снятия.

Object Lock работает только в бакете с включённым версионированием. Если кто-то перезапишет файл с тем же именем, появится новая версия, а заблокированная останется на месте. Если блокировки на бакете потом выключить, уже установленные всё равно продолжат действовать.

У compliance есть обратная сторона: всё время блокировки копии нельзя удалить, и за их хранение придётся платить. Срок выбирайте под свой RPO и бюджет. AWS предлагает проверять настройки в режиме governance, прежде чем включать compliance.

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

Как защитить бэкапы от шифровальщика

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

• Ключ сервера только на запись. В Yandex Cloud это роль сервисного аккаунта storage.uploader: она позволяет загружать и перезаписывать объекты, но не позволяет удалять их и настраивать бакет.
• Object Lock в режиме compliance. Закрывает случай, когда утёк ключ с более широкими правами: удалить заблокированную версию до срока нельзя.

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

Код: бакет, ключ только на запись, бэкап и проверка

Ниже рабочий минимум для сайта на MySQL (WordPress, Битрикс) с хранилищем в Yandex Object Storage. Значения, помеченные TODO, нужно заменить на свои. Скрипты - отправная точка: прогоните их на тестовом бакете в режиме governance, прежде чем доверять им боевые данные.

Шаг 1. Бакет с версионированием и Object Lock. Выполняется с машины администратора, не с сервера сайта. Нужен ключ с ролью storage.admin, порядок команд взят из документации.

# Профиль aws cli с ключом администратора хранилища (НЕ тот, что ляжет на сервер сайта)
export AWS_PROFILE=storage-admin
ENDPOINT=https://storage.yandexcloud.net
BUCKET=example-backups   # TODO: своё имя бакета

aws s3api create-bucket --bucket "$BUCKET" --endpoint-url "$ENDPOINT"

# Без версионирования Object Lock не включится
aws s3api put-bucket-versioning --bucket "$BUCKET" \
  --versioning-configuration Status=Enabled --endpoint-url "$ENDPOINT"

# Каждая новая версия объекта автоматически блокируется на 30 дней.
# TODO: для первого запуска поставьте GOVERNANCE, проверьте, затем COMPLIANCE.
cat > lock.json <<'EOF'
{
  "ObjectLockEnabled": "Enabled",
  "Rule": { "DefaultRetention": { "Mode": "COMPLIANCE", "Days": 30 } }
}
EOF
aws s3api put-object-lock-configuration --bucket "$BUCKET" \
  --object-lock-configuration file://lock.json --endpoint-url "$ENDPOINT"

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

# Аккаунт, ключ которого будет лежать на сервере сайта
yc iam service-account create --name backup-writer

# storage.uploader: загрузка и перезапись есть, удаления нет
yc resource-manager folder add-access-binding <имя_или_ID_каталога_бэкапов> \
  --role storage.uploader \
  --service-account-name backup-writer

# Статический ключ для aws cli. Секрет показывается один раз - сразу на сервер в ~/.aws/credentials
yc iam access-key create --service-account-name backup-writer

# Второй аккаунт только на чтение: для проверки возраста копий (шаг 4) и восстановления (шаг 5).
# Его ключ на сервер сайта не кладём
yc iam service-account create --name backup-reader
yc resource-manager folder add-access-binding <имя_или_ID_каталога_бэкапов> \
  --role storage.viewer \
  --service-account-name backup-reader
yc iam access-key create --service-account-name backup-reader

На сервере сайта ключ backup-writer кладётся в отдельный профиль aws cli, а ключ backup-reader так же кладётся на машину, где работает проверка из шага 4 (профиль [profile backup-reader] с тем же region):

# ~/.aws/credentials
[backup-writer]
aws_access_key_id = <ID_ключа>
aws_secret_access_key = <секрет>

# ~/.aws/config
[profile backup-writer]
region = ru-central1
# aws cli v2 по умолчанию считает контрольные суммы CRC64NVME. Если хранилище отвечает
# на загрузку ошибкой контрольной суммы, эти две строки возвращают старое поведение
request_checksum_calculation = when_required
response_checksum_validation = when_required

Шаг 3. Скрипт бэкапа на сервере сайта. Пароль базы данных храните в ~/.my.cnf, не в скрипте. Архив шифруется публичным GPG-ключом, приватный хранится вне сервера: украденная копия без него бесполезна. Во временной папке архив лежит дважды (целиком и частями), так что места на диске нужно с запасом.

#!/usr/bin/env bash
set -euo pipefail
# У cron урезанный PATH, а aws cli часто стоит в /usr/local/bin
export PATH=/usr/local/bin:/usr/bin:/bin

BUCKET=example-backups                 # TODO
SITE_DIR=/var/www/example.com          # TODO: корень сайта
DB_NAME=example_db                     # TODO
GPG_RECIPIENT=backup@example.com       # TODO: публичный ключ, импортированный на сервер
STAMP=$(date -u +%Y-%m-%dT%H-%M-%SZ)
TMP=$(mktemp -d); trap 'rm -rf "$TMP"' EXIT

# --single-transaction: согласованный снимок InnoDB без блокировки таблиц на время дампа
mysqldump --single-transaction --routines --triggers "$DB_NAME" | gzip > "$TMP/db.sql.gz"

# Кеш и встроенные архивы Битрикса не копируем: кеш CMS пересоберёт сама, архивы раздувают копию.
# Сайт живой, файлы меняются во время архивации: код 1 у tar (file changed) не считаем ошибкой
tar -czf "$TMP/files.tar.gz" --warning=no-file-changed -C "$SITE_DIR" \
  --exclude='./bitrix/cache' --exclude='./bitrix/managed_cache' --exclude='./bitrix/backup' \
  --exclude='./wp-content/cache' . || [ $? -eq 1 ]

tar -cf - -C "$TMP" db.sql.gz files.tar.gz \
  | gpg --batch --encrypt --recipient "$GPG_RECIPIENT" --trust-model always -o "$TMP/backup.tar.gpg"

# Одним запросом загружается не больше 5 ГБ, поэтому архив режем на части по 4 ГБ
split -b 4G -d "$TMP/backup.tar.gpg" "$TMP/part."

# Бакет с блокировкой по умолчанию принимает загрузку только с заголовком Content-MD5.
# Ключ backup-writer: загрузить может, удалить старые копии - нет
for part in "$TMP"/part.*; do
  aws s3api put-object --bucket "$BUCKET" --key "example.com/$STAMP/${part##*/}" \
    --body "$part" --content-md5 "$(openssl md5 -binary "$part" | base64)" \
    --endpoint-url https://storage.yandexcloud.net --profile backup-writer > /dev/null
done

Запуск раз в сутки через cron (crontab -e):

# 03:30 каждую ночь; вывод - в лог, чтобы было что смотреть при сбое
30 3 * * * /opt/backup/backup.sh >> /var/log/site-backup.log 2>&1

Шаг 4. Проверка возраста последней копии. Самый опасный сбой тихий: сайт работает, а бэкап перестал делаться неделю назад из-за отозванного ключа или кончившегося места. Скрипт запускайте не на сервере сайта: если сервер умрёт, проверка должна продолжать работать. Ключ здесь нужен только на чтение (роль storage.viewer).

#!/usr/bin/env bash
set -euo pipefail
export PATH=/usr/local/bin:/usr/bin:/bin

BUCKET=example-backups; PREFIX=example.com/   # TODO
MAX_AGE_H=26                                  # копия раз в сутки + запас на долгий дамп
# Токен бота и ID чата храните в отдельном файле с правами 600, не в скрипте
source /etc/backup-alert.env                  # TODO: TG_TOKEN=... и TG_CHAT=...

alert() {
  curl -sf "https://api.telegram.org/bot$TG_TOKEN/sendMessage" \
    -d chat_id="$TG_CHAT" --data-urlencode text="$1" > /dev/null
}

# Отозванный ключ или нет сети: тоже алерт, без тихого выхода по set -e.
# Contents || `[]` нужен для пустого префикса, иначе max_by падает
LAST=$(aws s3api list-objects-v2 --bucket "$BUCKET" --prefix "$PREFIX" \
  --query 'max_by(Contents || `[]`, &LastModified).LastModified' --output text \
  --endpoint-url https://storage.yandexcloud.net --profile backup-reader) \
  || { alert "Не удалось проверить бэкапы $PREFIX"; exit 1; }

# Пустой бакет тоже авария
if [ -z "$LAST" ] || [ "$LAST" = "None" ]; then alert "Бэкапов $PREFIX нет вообще"; exit 1; fi

AGE_H=$(( ( $(date +%s) - $(date -d "$LAST" +%s) ) / 3600 ))
[ "$AGE_H" -gt "$MAX_AGE_H" ] && alert "Бэкап $PREFIX не обновлялся $AGE_H ч" || true

Шаг 5. Проверка восстановления. Это тот самый «0» в правиле. Раз в месяц или после крупных изменений скачайте последнюю копию на чистый сервер, расшифруйте приватным ключом, разверните и откройте сайт. Засеките, сколько времени прошло, пока сайт не открылся: это и есть ваш реальный RTO.

# <метка> - папка нужной копии, например 2026-11-03T00-30-00Z
aws s3 cp s3://example-backups/example.com/<метка>/ ./restore/ --recursive \
  --endpoint-url https://storage.yandexcloud.net --profile backup-reader
cat restore/part.* | gpg --decrypt | tar -xf -  # нужен приватный ключ
mysql -e 'CREATE DATABASE example_db_restore'    # отдельная база, не боевая
gunzip -c db.sql.gz | mysql example_db_restore
tar -xzf files.tar.gz -C /var/www/restore          # TODO: корень тестового сайта

Что проверить у своего подрядчика сегодня

Даже если сайт сейчас работает, задайте тому, кто его обслуживает, четыре вопроса:

1. Где лежат бэкапы и доступы, если личный кабинет хостинга перестанет открываться? Включая регистратора домена, DNS и почту.
2. Кто заметит, если бэкап три ночи подряд не сделается? И как он об этом узнает.
3. Может ли человек, получивший доступ к серверу сайта, удалить бэкапы? Теми же ключами, что лежат на сервере.
4. Когда последний раз проект разворачивали из бэкапа на чистом сервере и сколько это заняло? Если ни разу, RTO у вас неизвестен.

Чем я могу помочь

Если сайт сейчас лежит вместе с хостингом или ответы на вопросы выше не радуют, я подключусь:

• Экстренный переезд. Подниму сайт у другого провайдера из того, что есть на руках, перенесу базу и файлы, переключу DNS.
• Бэкапы «под ключ». Настрою выгрузку зашифрованных копий во внешнее хранилище с ключом только на запись и Object Lock, проверку возраста копий с уведомлением в Telegram и пробное восстановление с замером времени.
• Аудит. Проверю, где у вас точки отказа: домен, DNS, почта, бэкапы, доступы.

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

FAQ

Что делать, если хостинг не работает, а бэкапы остались у него? Ждать восстановления от провайдера, а пока поднять временную страницу с контактами, если вы контролируете домен. Свежего сайта без копии не будет. Beget, например, пишет, что файловые бэкапы есть для подавляющего большинства ресурсов, но восстановление из них займёт много времени.

Что делать, если истёк срок регистрации домена, а регистратор не работает? После окончания срока у домена .RU или .РФ есть 30 дней преимущественного продления, и продлить его можно только через своего регистратора, перенос к другому в это время запрещён. Сохраняйте подтверждения попыток продления и пишите регистратору и в Координационный центр: правила позволяют ему приостановить этот срок, если регистратор бездействует.

Можно ли восстановить сайт из веб-архива? Частично. Wayback Machine хранит снимки страниц, которые успел обойти: тексты и вёрстку, без базы данных, корзины и личных кабинетов. Кэш Google для этого больше не подходит, оператор cache: отключён в 2024 году.

Чем репликация отличается от бэкапа? Реплика повторяет все изменения основной базы почти сразу, включая ошибочное удаление и шифрование. А бэкап это снимок на конкретный момент, к которому можно вернуться после такой ошибки.

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

Как защитить бэкапы от удаления и шифровальщика? Хранить копию у другого провайдера, дать серверу сайта ключ только на запись (в Yandex Cloud это роль storage.uploader) и включить Object Lock в режиме compliance: до окончания срока заблокированную копию не удалит ни один пользователь, включая администратора.