Назовите реально использованный инструмент, тип резервирования, объём данных и свой участок ответственности. RPO подтверждают доступной точкой восстановления и допустимой потерей изменений; RTO — замером всего согласованного процесса восстановления. Размер БД влияет на длительность, но сам по себе не доказывает достижимость целей. Если восстановление не проверяли, не представляйте заявленный RTO как измеренный результат.
Чем вы делали бэкапы PostgreSQL, каков был объём БД и чем подтверждались RPO/RTO?
Как обосновать реальные RPO/RTO: инструмент, размер данных, сохранность WAL, условия восстановления и замеры до готовности сервиса, а не только наличие бэкапа.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Начните с фактов своего проекта: чем создавали копии, кто настраивал процесс, что проверяли лично. Не подставляйте произвольный объём БД и красивое время восстановления.
Сначала опишите схему. Укажите логическую копию через pg_dump либо физическое резервирование, например pg_basebackup, и наличие архивирования WAL. Это разные механизмы. Для PITR нужна подходящая физическая копия и непрерывная последовательность нужных WAL; обычный dump нельзя дополнить WAL и восстановить таким способом. Основание — документация PostgreSQL.
Затем поясните объём. Что именно измеряли: одну БД, весь кластер, таблицы с индексами или сжатый архив? Какой объём WAL появлялся между копиями? Размер архива и размер восстанавливаемых данных не равны автоматически. Назовите только известные значения и период измерения.
Разделите цели и результаты. RPO задаёт требуемую точку восстановления, то есть допустимую потерю последних изменений; RTO — допустимую длительность восстановления. Это требования, а не свойства выбранной утилиты.
Для обоснования RPO расскажите о последней пригодной точке восстановления, задержках доставки WAL и контроле пропусков. Одного расписания копирования недостаточно.
Для RTO приведите результаты восстановления на сопоставимой инфраструктуре: получение копии, распаковку, восстановление данных, проигрывание WAL, проверки и возвращение сервиса в согласованное рабочее состояние. Обозначьте границы отсчёта. Размер копии, делённый на скорость чтения, оценивает лишь один этап, а не весь RTO.
Завершите ограничениями: какой сценарий аварии проверяли, насколько репрезентативны данные и как часто повторяли проверку. Если участвовали только в создании копий, прямо скажите, что не можете подтвердить фактическое время полного восстановления.