Бэкап, который никто не восстанавливал, — это не бэкап

На вопрос «у нас делаются резервные копии?» технический специалист почти всегда отвечает утвердительно, и отвечает честно: задание в планировщике есть, файлы создаются, место занимается. Руководитель ставит мысленную галочку и возвращается к своим делам.

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

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

Что выясняется в этот день

Список короткий и повторяется из компании в компанию.

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

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

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

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

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

Репликация — это не резервная копия

Отдельного разговора заслуживает самое частое заблуждение.

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

Реплика защищает от отказа железа. Резервная копия защищает от ошибки, а ошибки случаются чаще, чем отказывают диски.

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

Классическое правило остаётся рабочим: три копии данных, на двух разных носителях или у двух провайдеров, одна — вне основной площадки.

Что должно попадать в копии

Помимо базы данных:

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

Учения: как проверить, ничего не сломав

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

1. Чистая площадка. Возьмите новый сервер в изолированной среде. Именно новый: восстановление на машину, где уже настроено окружение, ничего не доказывает — вы проверите копию, но не полноту процедуры.

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

3. Хронометраж и проверка результата. Засекается время от начала до момента, когда система открывается и способна принять заказ. Проверять нужно именно рабочий сценарий целиком, а не доступность стартовой страницы.

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

Полученное время — ваше реальное RTO. Не то, которое написано в документе, а то, которое подтверждено. Разумная периодичность — раз в квартал, и обязательно после серьёзных изменений в архитектуре.

Ещё одна проверка, о которой забывают

Восстановление проверяет, что данные вернутся. Отдельно стоит проверить, что они правильные.

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

Три вопроса, которые стоит задать сегодня

Их можно задать в рабочем чате прямо сейчас. Абстрактные ответы вроде «всё настроено» не принимаются — нужны конкретные.

1. Где физически лежат копии? Приемлемый ответ: у другого провайдера или как минимум на другой площадке, в хранилище, откуда продуктивная система не может их удалить.

2. Когда мы в последний раз разворачивали систему из этих копий на чистом сервере и сколько это заняло? Приемлемый ответ: конкретная дата в пределах последнего квартала и конкретное время в часах. Ответ «когда настраивали, три года назад» означает отсутствие проверенных копий.

3. Что именно не восстановится, если площадка исчезнет целиком? Здоровая реакция — короткий и честный список. Ответ «всё восстановится» без проведённых учений означает, что вопрос не изучался.

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

Смежные разборы: RTO и RPO — как задать требования к восстановлению в терминах бизнеса, и первые 30 минут после падения — что делает команда, пока идёт восстановление.