Восстановление на момент времени и снимки: что вы теряете

Кто-то выполняет DELETE без условия WHERE в 16:15. Последняя резервная копия сделана в 03:00. Всё, что произошло между этими моментами, потеряно, и никакое восстановление не вернёт эти данные.

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

Две модели

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

Восстановление на момент времени объединяет базовую резервную копию с непрерывным потоком журнала предварительной записи базы данных. Поскольку каждое изменение записывается в определённом порядке, можно воспроизвести состояние на любой момент, покрываемый сохранённым журналом, — включая 16:14, то есть за минуту до удаления.

Разница здесь не постепенная. Это разница между «мы потеряли день» и «мы потеряли минуту».

Число, которое всё решает

Честно ответьте на один вопрос: что произойдёт, если вы потеряете всё, что было записано за последние двенадцать часов?

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

Для всего, где данные постоянно создают клиенты, ответ обычно звучит примерно так: «Нам придётся писать людям и всё объяснять». Заказы, которых больше не существует. Загруженные файлы, которые исчезли. Отправленные сообщения, которых теперь нет. Одни только расходы на поддержку обычно превышают разницу в затратах на инфраструктуру за целый год.

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

Для чего снимки действительно подходят

Это не более слабый продукт. Они покрывают сценарии сбоев, которые PITR не решает:

• Полная потеря диска. Снимок на отдельном хранилище восстанавливает всё, включая файлы, которыми владеет не база данных.
• Быстрый откат с крупным шагом. Откат неудачной миграции в staging-среде из снимка быстрее, чем воспроизведение журнала.
• Стоимость. Хранить одну копию в день дешевле, чем хранить каждую запись.
• Простота. Меньшее количество компонентов — важное операционное преимущество, особенно для небольшой команды.

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

Что вам стоит PITR

Это не бесплатно, и связанные с ним затраты стоит назвать прямо:

• Хранилище. Вам нужно хранить базовую резервную копию и каждую запись за весь период хранения.
• Сложность. Архивирование должно работать непрерывно. Если архиватор незаметно не работал неделю, доступное для восстановления окно заканчивается неделю назад — поэтому мониторинг архива так же важен, как и его настройка.
• Время восстановления. Воспроизведение журнала занимает больше времени, чем восстановление снимка. RPO улучшается, а RTO обычно становится хуже.

Последний компромисс часто становится неприятным сюрпризом. PITR означает, что вы теряете меньше данных, а не то, что быстрее возвращаетесь к работе.

Многоуровневый ответ, который на практике нужен большинству команд

На практике это не выбор из двух вариантов. Для рабочих баз данных обычно нужны три уровня, потому что они выходят из строя по-разному:

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

Логические дампы — ежедневно, хранить отдельно от хоста. pg_dump переносим и по определению создаёт согласованную копию. Его можно восстановить на другой мажорной версии, у другого провайдера или на ноутбуке — именно это нужно, когда проблема связана с платформой, а не с данными.

Непрерывное архивирование, если в базе есть данные клиентов. Именно этот уровень превращает «мы потеряли сегодняшний день» в «мы потеряли минуту».

Каждый уровень покрывает то, чего не делают остальные. Снимок не поможет перейти к другому провайдеру. Логический дамп не поможет восстановить файл, которого не было в базе данных. Ни один из них не поможет отменить удаление четырёхчасовой давности.

Где здесь Dockup

Dockup предоставляет два уровня, которые покрывают наиболее распространённые сбои, и важно точно понимать, о каких именно уровнях идёт речь.

Снимки томов — по требованию или по расписанию с указанием количества хранимых копий:

dockup volume snapshot <volumeId> my-project/my-api
dockup volume schedule <volumeId> my-project/my-api --daily --retention 7
dockup volume restore <volumeId> <snapshotId> my-project/my-api

Логические резервные копии баз данных, которые напрямую передаются в объектное хранилище и шифруются во время передачи:

dockup db backup my-project/main-db --json
dockup db backups my-project/main-db --json

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

Сегодня Dockup не выполняет непрерывное архивирование за вас. Если вам действительно нужен RPO в несколько минут, это стоит знать до принятия решения. Вполне разумно настроить такое архивирование самостоятельно для управляемой базы данных, а платформу использовать для всего остального.

Упражнение, которое стоит выполнить на этой неделе

Запишите два числа для рабочей базы данных:

1. RPO — сколько данных вы можете потерять. Измеряется во времени.
2. RTO — сколько времени вы можете оставаться недоступными. Тоже измеряется во времени.

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

Часто задаваемые вопросы

В чём разница между RPO и RTO? RPO — это объём потерянных данных: разрыв между последним доступным для восстановления моментом и сбоем. RTO — время, необходимое для восстановления. Снимки дают большой RPO и короткий RTO, а PITR меняет их местами.

Можно ли восстановить строки, удалённые час назад, из ночного снимка? Нет. Снимок восстанавливает состояние на момент создания. Всё, что было записано после этого, в файле отсутствует. Для восстановления произвольного момента требуется непрерывное архивирование.

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

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