RPO, RTO и проверка бэкапов

Два числа, из которых растёт схема

RPO (recovery point objective) - сколько данных допустимо потерять, измеряется во времени. Копия раз в сутки означает потерю до суток. Архив журнала изменений (базы пишут все правки в отдельный журнал) с выгрузкой раз в пять минут - до пяти минут. Синхронная реплика - ноль, но за неё платят задержкой каждой записи.

RTO (recovery time objective) - за сколько надо вернуться в строй. Именно оно упирается в физику: мой расчёт с 500 гигабайтами и часовым обещанием показывает, что копированием тут не обойтись. Если нужен час, то нужна уже поднятая и работающая копия базы, готовая принять трафик, - на неё переключаются, а не восстанавливаются из архива.

// Эти два числа не выбираются техническим отделом. Их называет бизнес, отвечая на вопрос «сколько стоит час простоя и сколько стоит потеря часа данных», а инженеры переводят ответ в схему и в её цену. Разговор в обратную сторону («мы сделали копии раз в сутки, вам хватит?») почти всегда заканчивается неприятным открытием в момент аварии.

RPO

допустимая потеря данных во времени (recovery point objective)

RTO

допустимое время восстановления (recovery time objective)

Реплика не заменяет копию

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

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

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

неизменяемая копия

копия, которую нельзя переписать или удалить раньше срока

поколения копий

несколько копий разной давности, а не одна последняя

Проверка и учения

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

Поэтому восстановление проверяют по расписанию и автоматически: развернуть копию в отдельном месте, проверить, что данные читаются и сходятся, ЗАМЕРИТЬ время. Это время и есть настоящее значение, которое можно обещать бизнесу, а не то, которое кажется.

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

проверка восстановления

регулярное разворачивание копии с замером времени

учения по переключению

перевод трафика на резервную площадку в спокойное время

Как отвечать: «Есть реплика. Зачем ещё и бэкапы?»

Потому что они закрывают разные классы бед. Реплика повторяет за основной базой всё, включая ошибки: команда удаления без условия доедет до неё за миллисекунды, и испорченные приложением данные тоже. Она защищает от смерти машины, диска или зоны и ни от чего больше. Копия защищает именно тем, что отстаёт и неизменна: можно вернуться на состояние до ошибки. Поэтому держат несколько поколений копий, в другом месте, и по возможности в режиме, где их нельзя удалить раньше срока - иначе тот, кто добрался до инфраструктуры, удалит и копии. И третье, о чём спрашивают реже, чем стоило бы: копию надо регулярно восстанавливать и замерять время. Я считал простой пример - 500 гигабайт на канале 120 мегабайт в секунду это 1,2 часа только на копирование, так что обещание «поднимемся за час» такой схемой не выполняется.

Ответ разводит два класса аварий, добавляет требование неизменности и заканчивается измеримым временем восстановления. Именно эти три вещи и проверяются вопросом.

На чём валятся

• −Считают реплику заменой копии и теряют данные при ошибке человека.
• −Держат копии рядом с базой: авария или взлом уносит и то и другое.
• −Не проверяют восстановление и называют время наугад.
• −Не следят за архивацией журнала: она отваливается молча.
• −Пишут план переключения и ни разу не проходят его целиком.