Стратегия бэкапов PostgreSQL
Вопрос
Интервьюер: «База PostgreSQL на 1 ТБ, бизнес готов потерять не больше 5 минут данных и восстановиться за 2 часа. Как организуете бэкапы?»
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Физические бэкапы с непрерывным архивом WAL (pgBackRest, WAL-G), PITR
Полная копия раз в неделю, инкрементальные или дифференциальные ежедневно
Хранение вне площадки и неизменяемость, правило 3-2-1
Регулярное автоматическое восстановление и замер времени против RTO
Мониторинг: возраст последнего бэкапа и архива WAL, алерты
Отдельно реплики для отказа железа: бэкап и реплика решают разные задачи
Что могут спросить следом
- Почему pg_dump здесь не подходит?
- Что делать, если восстановление идёт дольше двух часов?
Разбор
Образцовый ответ: «RPO 5 минут исключает суточные дампы, поэтому физические бэкапы через pgBackRest: полный раз в неделю, дифференциальный ежедневно, WAL архивируется непрерывно, с archive_timeout не больше пары минут. Хранилище S3 в другом аккаунте с object lock, плюс копия в другом облаке. Раз в неделю пайплайн разворачивает бэкап на стенде, восстанавливает на случайный момент времени, проверяет данные и меряет время. Если восстановление дольше двух часов, это сигнал: параллельное восстановление, чаще полные копии или держать отложенную реплику. Мониторю возраст последнего успешного бэкапа и задержку архива WAL. Для отказа сервера есть реплика с Patroni, но от DELETE без WHERE спасает только бэкап».
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.