Поднимется ли база из последней копии
Сам факт успешного backup-job не доказывает, что восстановление завершится без ошибок.
Recovery Proof • Доказуемое восстановление PostgreSQL
Проверьте, что ваш PostgreSQL реально восстановится до того, как случится инцидент
Recovery Proof автоматически выполняет тестовое восстановление PostgreSQL из реальных backup'ов, проверяет восстановление до нужной точки во времени, запускает SQL-checks и показывает фактический RTO/RPO. Вы заранее видите, где процесс сломается и что нужно исправить.
- Для кого: self-managed PostgreSQL, Patroni, pgBackRest, S3-compatible storage
- Как работает: runner запускается в вашем контуре
- Что важно: без доступа на запись в production
Проблема
Backup есть. Уверенности в восстановлении — нет.
У большинства команд backup-job'ы зеленые. Но в момент инцидента всплывают вопросы, на которые мониторинг backup'ов не отвечает.
Хватит ли WAL для восстановления до нужной точки
Пробелы в цепочке WAL обычно обнаруживаются в самый неудачный момент.
Сколько времени это реально займет
RTO на словах и measured RTO на конкретном сценарии часто сильно расходятся.
Пройдут ли критичные SQL-проверки после восстановления
База может стартовать, но приложение все равно не переживет инцидент.
Пока вы не делали реальное тестовое восстановление, готовность к инциденту остается предположением.
Решение
Мы не делаем еще один backup-tool. Мы доказываем, что восстановление реально работает.
Recovery Proof по кнопке или по расписанию исполняет полный сценарий test restore и показывает, что произойдет в реальном инциденте.
Изолированная restore-среда
Поднимаем отдельное окружение восстановления без вмешательства в production.
Latest restore или PITR
Проверяем либо последнюю точку восстановления, либо конкретный target timestamp.
Базовые и кастомные SQL-checks
Проверяем не только старт PostgreSQL, но и то, что важные инварианты действительно соблюдаются.
Фактический RTO
Измеряем, сколько времени занял конкретный сценарий, а не опираемся на ожидания команды.
Оценка RPO
Показываем потенциальную потерю данных по сценарию и качество доступной WAL-цепочки.
Понятный отчет
Отправляем итог в Slack или на email: прошло / не прошло, где проблема и что чинить.
Вместо "кажется, все должно сработать" вы получаете факт: прошло или не прошло, сколько заняло и в каком месте сценарий ломается.
Как это работает
Начинаем с одного критичного сценария, а не с длинного проекта внедрения
Вы выбираете одну критичную БД
Стартуем с самого важного сценария, где сбой действительно дорогой для бизнеса.
Устанавливаете runner в своем контуре
Runner получает доступ только к backup storage и restore-среде. Запись в production не нужна.
Запускается тестовое восстановление
Можно вручную или по расписанию. Временная restore-среда поднимается автоматически.
Получаете результат в понятном виде
Видите pass / fail, measured RTO, результат PITR, SQL-checks и место фактического сбоя.
Что получает клиент
Что вы получаете после каждого запуска
Фактический RTO, а не оценку на словах
Видно реальное время восстановления по конкретному сценарию и конкретному стеку.
Проверку, что PITR действительно работает
Не только backup завершился, но и восстановление дошло до нужной точки во времени.
Понятную причину сбоя
Не просто fail, а конкретное узкое место: WAL gap, restore bottleneck или SQL-check failure.
Снижение ручной нагрузки на DBA и SRE
Меньше ручных стендов, ад-хок проверки и импровизации в момент аварии.
Отчет для внутренней коммуникации
Покажете результат CTO, Platform-команде, ИБ, аудиту или руководителю без перевода логов.
Историю запусков
Видно динамику по сценариям и можно быстро понять, что изменилось после очередной правки стека.
Пример отчета
Что будет в отчете
Это не просто технический лог. Это доказательство того, что восстановление либо работает, либо нет.
Итог сценария
PASS
- Scenario: PITR до 2026-04-05 14:05 UTC
- Measured RTO: 18m 42s
- Estimated RPO: under 30s
Что видно сразу
- Прошло / не прошло
- Latest restore или restore до точки во времени
- Фактическое время восстановления по сценарию
Проверки после восстановления
- SQL-checks по критичным таблицам и данным
- Сигнал, дошло ли восстановление до нужной точки
- Ссылка на логи и историю запусков
Если сценарий не прошел
- Увидите конкретную причину сбоя, а не общий статус fail
- Поймете, связано ли это с WAL, длительностью restore или логикой SQL-checks
- Получите basis для gap report и списка того, что нужно исправить
Кому подходит
Подходит командам, где PostgreSQL критичен для бизнеса
Особенно полезно, если у вас:
- self-managed PostgreSQL
- Patroni + pgBackRest + S3-compatible storage
- одна или несколько критичных БД
- требования по RTO/RPO, SLA, аудиту или внутреннему контролю
- нет большой DBA-команды и не хватает времени на регулярные ручные проверки
Пока не лучший вариант, если:
- у вас только managed databases
- вы ищете замену всей backup-системе
- вам сразу нужна поддержка всех типов СУБД и сценариев
Если стек не совсем стандартный, оставьте заявку на проверку совместимости. Быстро скажем, подходит ли сценарий под пилот.
Пилот за 14 дней
Сможете ли вы реально восстановить одну критичную БД в нужное время?
Мы не предлагаем длинный проект. Начинаем с одного критичного кластера и одного понятного вопроса про восстановление.
Первый результат обычно появляется через 2–3 дня после старта.
Безопасность и внедрение
Безопасно для production
Runner работает в вашем контуре и не требует доступа на запись в production. Мы не меняем текущую backup-схему и не вмешиваемся в рабочую среду.
Runner в вашем контуре
Контроль доступа, сеть и restore-среда остаются на вашей стороне.
Без записи в production
Продукту не нужен write-access в рабочую БД, чтобы исполнять restore drill.
Используем уже существующие backup'ы
Проверяем реальную восстановляемость на вашем текущем backup-процессе.
Почему сейчас
Лучше узнать о проблеме на тесте, чем в аварии
Самая дорогая ошибка — это не "backup не сработал". Самая дорогая ошибка — это когда кажется, что backup есть и все в порядке, а во время сбоя выясняется обратное.
Не хватает WAL
Восстановление до нужной точки оказывается невозможным уже в момент инцидента.
Restore занимает слишком долго
Команда не выдерживает заявленный RTO, хотя формально backup-система была "зелёной".
Не проходит критичная проверка
База стартует, но целостность данных или ключевая бизнес-логика не проходят SQL-checks.
Процедура впервые выполняется в инциденте
Команда репетирует восстановление уже под давлением, а не в контролируемых условиях.
FAQ
Частые вопросы
Чем это отличается от мониторинга backup'ов?
Мониторинг показывает, что backup завершился. Recovery Proof показывает, что восстановление реально работает.
Зачем это, если у нас уже есть pgBackRest?
pgBackRest делает backup и restore. Мы регулярно исполняем полный сценарий test restore, проверяем результат и измеряем фактическое время.
Нужно ли давать доступ в production?
Нет. Runner не требует доступа на запись в production.
Что будет, если тест не пройдет?
Это и есть ценность продукта. Вы увидите проблему до инцидента и получите понятный список того, что нужно исправить.
Сколько занимает внедрение?
Пилотный сценарий обычно можно запустить за несколько дней.
Если у нас не совсем стандартный стек?
Оставьте заявку на проверку совместимости. Мы быстро скажем, подходит ли ваш стек под пилот.
Проверьте одну критичную БД до того, как ее придется восстанавливать по-настоящему
За короткий созвон поймем, подходит ли вам пилот. Если подходит — запустим первый сценарий и покажем реальный результат на вашей инфраструктуре.
Три CTA для проверки гипотезы спроса: пилот, пример отчета и совместимость стека.