Backup & Restore

Простое правило, которое я повторяю чаще всего на ревью: backup, который никто никогда не восстанавливал, не существует. На бумаге он есть. В архиве — какие-то данные. Но пока кто-то фактически не достал его и не прогнал восстановление — это не backup, это надежда. Лист — про то, как превратить надежду в гарантию. Главная практика внутри L1 Database Reliability; соседи (Replication & Failover, Schema Migration Patterns, DB Performance Tuning) — в открытых вопросах.

Что должен уметь

Главный навык на уровне L5 — превратить проверку восстановлением из задачи в ритуал. Я регулярно встречаю команды, где учения по восстановлению «делали в прошлом году, тогда работало». За год окружение уехало, ключи ротированы, runbook устарел, а главное — инженер, который делал прошлый раз, работает в другой команде. Проверка ценна периодичностью, не разовостью.

Различает RPO (сколько данных потерять допустимо) и RTO (сколько времени есть на восстановление); знает, где лежат backup’ы его сервиса и кто ими владеет.
Находит backup конкретного сервиса; выполняет базовое восстановление в staging по готовому runbook.

Определяет RPO и RTO своего сервиса исходя из требований бизнеса; фиксирует их в SLO-документе сервиса; согласует с продуктовой командой.
Проверяет backup’ы регулярным восстановлением в staging, минимум раз в квартал; засекает, сколько заняло; найденные проблемы уходят в задачи со сроком.

Проектирует стратегию бэкапа: полные копии, инкрементальные, отгрузка журналов и их периодичность, срок хранения с оглядкой на регуляторику, шифрование через KMS, копия в другом регионе под DR.
Превращает учения по восстановлению в ритуал: случайная неделя в квартале, восстановление в изолированном окружении, замер времени.
Реализует восстановление на произвольный момент (PITR) там, где источник это умеет: архив WAL в PostgreSQL, binlog в MySQL, oplog в MongoDB, версионирование в S3. Понимает размен между ценой хранения и RPO.

L6+

Проектирует восстановление после катастрофы на уровне организации: восстановление в другом регионе, целевые RTO для критичных систем, runbook на потерю всего региона, требования регуляторов.
Балансирует стратегию с ценой и регуляторикой: классы хранения (горячий, холодный, архивный), срок хранения с явной чисткой, шифрование на диске с ротацией ключей, журнал обращений к архивам.

Материалы

Книги

Raymond Blum, Rhandeev Singh — Site Reliability Engineering (O’Reilly, 2016), глава 26 «Data Integrity: What You Read Is What You Wrote». База: канонический подход Google — три уровня защиты (мягкое удаление, backup’ы вместе со способами восстановления, раннее обнаружение); тезис «secret to superior data integrity is proactive detection and rapid repair and recovery».

Статьи

Twelve-Factor App, фактор IV «Backing Services». Базы и хранилища трактуются как подключаемые ресурсы; с бэкапом пересекается там, где речь о лёгкой замене и переносимости.
GitLab database outage 2017-01-31. См. ниже в Best practices — главный публичный кейс по теме.

Инструменты

Управляемые сервисы бэкапа в облаке — AWS Backup, GCP Backup and DR, Azure Backup: для управляемых баз (RDS, Cloud SQL, Cosmos DB) дают восстановление на момент, копию в другом регионе и шифрование из коробки. По моим наблюдениям, это первый выбор для команд, которые целиком живут в одном облаке, — интегрировать почти нечего.
Штатные выгрузки СУБД плюс архив журналов — pg_dump и архивирование WAL в PostgreSQL, mysqldump и binlog в MySQL, mongodump и oplog в MongoDB. Базовый набор, когда база своя, а не управляемая.
Velero — open-source бэкап и восстановление для кластера Kubernetes: ресурсы кластера вместе с постоянными томами. Стандарт для команд, живущих в k8s.
restic — современный инструмент для файлов и томов: шифрование на стороне клиента, дедупликация, десяток поддерживаемых хранилищ (S3, Backblaze, GCS, SFTP). Часто берут, когда всё крутится на своём железе.
Borg / Bacula — традиционные системы бэкапа для своих машин; Borg заметно чаще встречается в HPC и в самостоятельных установках.
Классы хранения — S3 и S3 Glacier с Glacier Deep Archive (AWS), Coldline и Archive (GCS), Archive Tier (Azure Blob). Срок хранения с автоматическим переводом старых копий в холодный класс — стандартная практика.

Best practices

GitLab database outage 31 января 2017 — главный публичный кейс к этому листу. У GitLab было пять механизмов бэкапа и репликации одновременно (pg_dump, снапшот LVM, снапшот диска в Azure, выгрузка в S3, репликация). Когда понадобилось восстанавливаться, выяснилось, что не работает ни один: pg_dump молча падал из-за несовпадения версий, выгрузки в S3 оказались пустыми, снапшоты дисков для этого сервера не делались, репликация была сломана самой аварией. Спасла случайность — снапшот LVM, снятый шестью часами ранее для нужд staging, не как бэкап. Данные за эти шесть часов потеряны безвозвратно. Главный урок не «нужно иметь много механизмов бэкапа» (их было пять и не помогло), а «каждый из них должен быть проверен реальным восстановлением»: пять непроверенных копий дают ровно ноль гарантий, и это самый дорогой способ узнать, что ноль — это ноль. Если читаете это и впервые сталкиваетесь с темой — сначала туда, потом сюда.

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

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

Третье: шифрование на диске и журнал обращений. Backup — это снимок всей боевой базы с персональными данными, платёжной информацией и секретами, так что доступ к бакету с копиями равен доступу к самой базе. KMS с ротацией ключей, права по принципу наименьших привилегий, запись в журнал аудита на каждое обращение. Для SOC 2, PCI DSS и GDPR это не рекомендация, а условие.

RPO и RTO — явные числа, а не «максимально часто». Формулировка «делаем backup’ы каждый день, восстановимся быстро» не даёт ни спроектировать стратегию, ни проверить, достигнута ли цель. Числа берутся из требований бизнеса: часы простоя, помноженные на потери выручки, если они известны, плюс ущерб пользователю от потери данных за N часов. Дальше они живут в SLO-документе сервиса и пересматриваются вместе с ним. Без явных чисел любая стратегия бэкапа — это «выглядит достаточно».

Учения по восстановлению с замером времени — ритуал, а не «когда-нибудь». «Мы делали проверку год назад, тогда работало» — фраза, которую я слышу регулярно. За год окружение уехало, нужные инструменты не установлены, ключи ротированы, runbook устарел, а инженер, который тогда всё делал, работает в другой команде. Квартальные учения с замером от обнаружения до возвращения сервиса дают настоящий RTO. Всё остальное — благие надежды.

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

Связанные листья

Service Ownership — каталог сервисов содержит данные о бэкапах: где хранятся, кто владеет, какие RPO и RTO, ссылка на runbook восстановления. Без каталога в момент аварии инженеры ищут копии вслепую.
Runbooks — runbook на восстановление обязателен; его качество определяет время возврата сервиса в момент аварии.
Infrastructure as Code — конфигурация бэкапа (бакеты, политики IAM, ключи KMS, расписания) сама описывается как код; git становится запасным вариантом для всего, что окружает конвейер бэкапа.
Incident Response — потеря или порча данных — отдельный класс инцидентов со своими путями эскалации.
Secrets Management — ключи шифрования для backup’ов сами живут в Vault или KMS с ротацией; потеря ключа равна потере всех копий, которые им закрыты.
SLI-based Alerting — свежесть копии — отдельный SLI («последний успешный backup не старше N часов»); алерт на пропавший backup обязателен.
DR Policy & Stakeholders — без работающего восстановления любая политика DR — обещание; без политики у восстановления нет правил применения на уровне организации. Этот лист — технический слой одного сервиса; DR Policy — правила поверх всех.

Открытые вопросы

Три соседние практики внутри Database Reliability пока не написаны. Replication & Failover (TBD) — потоковая репликация в PostgreSQL и MySQL, автоматическое переключение через Patroni, Orchestrator или Multi-AZ у управляемых RDS, защита от split-brain. Schema Migration Patterns (TBD) — expand-contract, двойная запись, backfill, теневое чтение; это уже стык с управлением изменениями. DB Performance Tuning (TBD) — проектирование индексов, планы запросов, пулы соединений, стратегии vacuum и compaction.

Отдельно висит Data Validation & Reconciliation: мягкое удаление (упомянуто в SRE Book, глава 26), контрольные суммы, периодическая сверка основной базы с репликами как защита от тихой порчи данных.

И самый неприятный вопрос — GDPR и право на забвение. Как удалить данные пользователя из всех копий и не потерять способность восстановиться, я внятно не понимаю. Тема лежит на стыке Database Reliability и Information Security.