Клиенты Beget потеряли сайты, базы и бэкапы разом. Почему копия у провайдера не спасла
После атаки на Beget в ночь на 2 ноября оператор подтвердил: данные в его облаке – VPS, S3 и Kubernetes – были утрачены, вместе с ними исчезли и бинарные бэкапы VPS. Файловые копии уцелели, но пока недоступны.
Копия была. Но в той же зоне отказа, что и данные, – поэтому авария провайдера забрала обе.
Бэкап на том же хостинге хорошо спасает от собственных ошибок: удалили таблицу, сломали конфиг, откатили неудачное обновление. При недоступности самого провайдера, его панели управления или хранилища такой бэкап может исчезнуть вместе с рабочими данными – либо остаться недоступным в самый неподходящий момент.
Для бизнеса это не абстрактная «недоступность». Это остановленные продажи, сорванные SLA, потерянные заявки и восстановление за свой счёт – у некоторых счёт идёт на миллионы рублей. И особенно больно, когда владелец рассказывает: сайт, база и единственный бэкап лежали у одного провайдера и исчезли разом.
Время задать себе неудобные вопросы
Есть ли хотя бы одна копия за пределами основной площадки или облака? «Другой сервер у того же провайдера» не считается – это не резервная копия, а сосед по камере.
Можно ли до неё добраться без основной консоли – с другими учётными записями и по другому каналу связи? Если только через ту же панель, то в день аварии вы будете искать не бэкап, а вход в панель, которая как раз и лежит.
Отделены ли ключи, права и учётные записи резервных копий от ключей, прав и учётных записей продакшена? Иначе одна скомпрометированная учётка открывает и прод, и бэкапы, а потеря доступа к проду заодно отрезает вас от копий.
Защищены ли копии от удаления и перезаписи политикой хранения? Без этого бэкап – просто файл, который можно случайно перезаписать, а через N дней он ещё и сам удалится по расписанию.
И главный вопрос: команда проверяла полноценное восстановление – или только создание бэкапа? Это два разных навыка, и второй проверяется только руками.
Данные и их единственная резервная копия на одной площадке – это одна точка отказа. Резервная копия должна пережить проблему того места, где работает основная система.
Кстати…
🎅 Red Hat в документации по службе каталогов рекомендует хранить бэкапы на отдельной от продуктивной файловой системе и архивировать отдельно. Бэкап LDAP-данных не стоит держать в том же контуре, что и сам каталог. Иначе вместе с каталогом можно потерять доступ к хранилищу, ключам или управляющей части.