Restoredrill - Proves your Postgres backups restore
Show HN: Restoredrill – proves your Postgres backups restore
Restoredrill — это инструмент для проверки восстановления резервных копий PostgreSQL. Он автоматически загружает последнюю резервную копию, восстанавливает её в одноразовый контейнер, выполняет заданные проверки и формирует JSON-отчёт с временем восстановления. Инструмент предназначен для использования в CI/CD, поддерживает проверки целостности, RPO/RTO метрики и уведомления в Slack или Prometheus. Отчёт соответствует требованиям аудиторов (SOC 2, ISO 27001, AWS FTR) и легко интегрируется в существующие процессы. Restoredrill решает проблему «непроверенных резервных копий», делая проверку восстановления простой и регулярной.
Непроверенные резервные копии — это не резервные копии. Restoredrill доказывает, что ваши PostgreSQL-бэкапы действительно восстанавливаются, прежде чем вы обнаружите это на собственном горьком опыте.
- sebmellen
> В этой области есть и другие инструменты. Стоит прямо назвать их, а не делать вид, что их не существует.
Почему LLM любят такой стиль письма? Зачем нужно было "прямо" называть конкурентов, а не "экстравагантно" их называть?
Идея классная, но README чересчур не по делу.
- lbrito
Это отличная идея, и я с этим сталкивался, и мне приходилось реализовывать это вручную в прошлом.
Самый распространённый сценарий для меня был таким: я настраиваю бэкап, который выполняется ежедневным cron'ом через pg_dump. Это работало, и я двигался дальше, пока однажды мне не понадобилось восстановить данные, и бэкапы не сработали. Обычно в какой-то момент VM не могла выполнить команды для очистки временных файлов бэкапа, диск заполнялся, и новые бэкапы обрезались на середине.
psql довольно плохо справляется с определением этой проблемы, которая, должно быть, очень распространена. Вместо проверки заголовка, которая бы приводила к сообщению "Бэкап повреждён, прерывание" или чему-то подобному, он просто выполняет SQL-команды, пока не дойдёт до самой последней строки, которая будет обрезана на середине и, следовательно, будет невалидным SQL.
В любом случае, мне потребовалось время, чтобы разобраться, но позже я сделал в основном то же, что делает ваш инструмент, вероятно, проще: ещё один ежедневный cron, который скачивает файл и проверяет, заканчивается ли он правильной сигнатурой успешного pg_dump. Пока что это работает.
- csydas
Я видел ваш мёртвый комментарий о том, что никто из опрошенных вами не дал ответа... просто мне удивительно, что девопс-специалисты не находятся в организации, где есть софт для бэкапов, потому что такое тестирование — стандартная нагрузка для большинства программ резервного копирования, и они даже решают проблему пространства и изоляции с помощью различных функций мгновенного восстановления / публикации, где данные из бэкапа монтируются прямо на какой-то промежуточный сервер с установленным postgres или чем-то ещё в изолированной области.
Не пытаюсь критиковать идею — вы правы, что большинство людей не тестируют свои бэкапы, но немного странно, что никто из тех, с кем вы говорили, не использовал ни один из самых распространённых софтов для бэкапов.
Определённо я за бесплатные решения, так как область софта для бэкапов ужасна, как и многие корпоративные технологические области, но такие рабочие процессы существуют.