Однажды я столкнулся с проблемой, когда почти потерял коммерчески успешный пет-проект из-за устаревших резервных копий БД (ещё до того, как он стал коммерчески неуспешным). При этом, даже после частичного восстановления, все-таки потерял ~30% прибыли от проекта, много нервов и времени.
Это подтолкнуло меня на разработку своего открытого инструмента для бекапа PostgreSQL. С разными хранилищами, уведомлениями при сбоях и health check'ом. Собственно, о том, как я потерял деньги и затем разработал проект — хочу рассказать в статье ниже.
Про open source проект для резервных копий PostgreSQL
История, как я испортил базу и не смог до конца восстановиться
Как начал разрабатывать проект
Дальнейшие планы
Правила по работе с БД, которые я теперь внедряю во все рабочие проекты
Заключение
Про open source проект для резервных копий PostgreSQL
Я выложил в open source свой проект для мониторинга и бекапов PostgreSQL. Проект разрабатываю и использую уже более 2-х лет. Разрабатывал с ориентиром на потребности своего рабочего и "пет" проектов.
И только недавно осознал, что проект, в общем-то, помогает знакомым, имеет публично-презентабельный вид и может быть полезен для сообщества.
Стек проекта: Go, gin, gorm, React, TypeScript, PostgreSQL и всё в Docker + Docker Compose. Изначально проект был на Java, но со временем был переписан на Go.
Фактически, это UI обвязка над стандартным pg_dump. С дополнительными функциями, которые улучшают UX стандартной утилиты и добавляют интеграции с внешними сервисами для хранения бекапов и уведомлений.
Делать резервные копии по расписанию (например, каждый день в 4 утра или каждое воскресенье в 12 ночи) для PostgreSQL с 13-й до 17-й версии.
Бекапы хранятся в сжатом виде локально на сервере, в S3 или Google Drive. В планах добавить Яндекс Диск, NS сервера и FTP.
После каждого бекапа вам отправляется уведомление, что всё хорошо (или наоборот — плохо). Уведомления об успешных бекапах опциональны.
Уведомлять в Telegram, на почту и в Slack, если БД не отвечает.
Причём уведомляет только через n неудачных попыток (чтобы нивелировать ложные срабатывания из-за сети) и показывает график доступности.
В планах добавить Discord, Mattermost и другие каналы связи.
Разумеется, проект бесплатный, открытый (под MIT лицензией), self hosted и с человеческим веб-интерфейсом.
P.S. если проект кажется полезным и если у вас есть аккаунт на GitHub, пожалуйста, поставьте звёздочку ⭐️. Первые звёзды тяжело собирать. Буду крайне признателен за поддержку!
История, как я испортил базу и не смог до конца восстановиться
В 2023-м году у меня был пет-проект, который давал доступ к ChatGPT (ещё к 3.5) в РФ без зарубежной карты и номера телефона. Обычная перепродажа доступа через API с наценкой. Проект рос, потом пошёл на спад и я его продал. БД проекта бекапилась консольной утилитой по типу PgBackRest раз в сутки на другой сервер.
В момент, когда проект приносил ~$1 500 на пассиве и был в пике доходности, произошло плохое: я испортил данные в базе.
Это была пятничная ночь, я был уставший, фоново отвечал на сообщения и был максимально расфокусирован. В этот момент клиент попросил поменять почту для доступа к аккаунту.
Через SSH и psql я полез в продовую базу, ввёл запрос в духе:
UPDATE users SET email = 'customer@email.com' WHERE email ILIKE '%%'
Затем отвлёкся, чтобы посмотреть нужную почту в чате и... на автомате нажал Enter. После чего увидел что-то в духе "AFFECTED ROWS: 10 000".
Это был единственный раз за много-много лет, когда у меня пробил холодный пот на спине. Буквально.
Дисклеймер: Разумеется, я знал, что неплохо бы сначала делать SELECT, сделать SAVEPOINT и т.д. Но, как во всех таких историях, базовые правила техники безопасности были проигнорированы, что привело к фатальным последствиям.
Все пользовательские почты были затерты. И тут важное уточнение: по правилам платёжных систем, если пользователь не может получить доступ к оплаченной услуге — это грубейшее нарушение. Разумеется, больше никто не мог войти в аккаунт и уже начали сыпаться жалобы.
Я полез в бекапы — и холодный пот пробил ещё раз. Последний бекап был примерно месяц назад 😐. Восстановиться из него уже нельзя. Всё это время платежи добавлялись, подписки отменялись (а значит нельзя было восстанавливать тех, кто уже не хочет платить) и т.д.
Кое-как за оставшуюся ночь и утро я смог скриптами восстановить ~65% базы по IDшникам пользователей. Остальным пришлось отменять подписки и возвращать деньги. Было больно, неприятно и дорого.
Урок был очень сильно усвоен...
Как начал разрабатывать проект
Было принято решение: разработаю себе такой инструмент для бекапов, который будет каждый день присылать уведомления, что все хорошо! И восстанавливать всё в пару кликов! И блек джек с микросервисами! И API метод для проверки жизнеспособности утилиты сделаю!
Первую версию Postgrusus'a разработал буквально за месяц на Java. Начал использовать. Иногда давать пользоваться знакомым. Дорабатывал по мере своих потребностей и по мере поступления обратной связи.
Оказалось, что удобно. Несколько раз резервные копии спасали и меня, и не только лишь меня. Название у проекта появилось только два месяца назад, до этого репозиторий назывался "pg-web-backup".
Конкретно сейчас Postgresus решает для меня следующие задачи:
Выступает резервным инструментом для бекапов, если проект большой, живёт в облаке с DBaaS и с облачными резервными копиями.
Бекапит базы на "всякий случай" (если вдруг облако умрёт, заблокируется, база случайно удалится вместе с резервными копиями из-за неуплаты и т.д.). Всяко лучше иметь дубль бекапов, чем попасть в тот неудачный 0.01%, когда даже облако накрылось и нет плана Б.
Дальнейшие планы
Сейчас в планах дорабатывать проект в следующих направлениях:
Добавить больше PostgreSQL-специфичного мониторинга нагрузки (pg_stat_activity, pg_system_stat, pg_locks), но с удобным UI.
Эдакая альтернатива postgres_exporter + Grafana, но из коробки вместе с резервными копиями.
Наблюдение и алертинг в случае замедления ключевых запросов.
У меня в рабочем проекте есть таблицы и специфические функции, которые ещё рано оптимизировать (если гипотеза провалиться — можем удалить). Но потенциально могут вырасти по данными и упасть в скорости.
Условно, если запрос INSERT INTO users (...) VALUES (...) начал занимать больше 100мс, а у нас поток новых пользователей только растёт — нам прилетит уведомление и мы пойдем оптимизировать.
Собирать статистику запросов по CPU time и частоте выполнения, чтобы видеть, куда уходят основные ресурсы и что стоит оптимизировать.
Добавлять больше источников для уведомлений и хранения данных.
Правила по работе с БД, которые я теперь внедряю во все рабочие проекты
Напомню две народные мудрости:
Системные администраторы делятся на тех, кто ещё не делает резервные копии и тех, кто уже делает резервные копии.
Не только делай резервные копии, а ещё и регулярно проверяй, что из них получается восстановиться.
С тех пор как я испортил БД своего проекта, я категорически без исключений принял на вооружение следующие правила:
перед любым UPDATE всегда делать SELECT и проверять, что выбирается всего 1-2 строки;
если изменение большое — ставить руками SAVEPOINT;
проводить "учения" по восстановлению минимум раз в 3 месяца. Причём как из облачной копии, так и из локальной. Чтобы в ответственный момент не оказалось, что данных нет, резервные копии не работают или восстанавливаются слишком долго.
За прошедшие 2 года были прецеденты, когда требовалось восстановление из бекапов — всегда получалось и в облаке, и из Postgresus'a. Проблем не было, потому что всё было отлажено на этапе тестов. Базовые правила техники безопасности работают.
Заключение
Надеюсь, мой проект окажется полезен для широкого круга разработчиков, DBA и DevOps'ов. Планирую развивать его дальше, повышая его полезность в боевых задачах. Буду рад любым предложениям и комментариям по улучшению.
Ну и, как полагается, у меня есть Telegram-канал, в котором я рассказываю про разработку, развитие SaaS-сервисов и управление IT проектами. В том числе о проблемах, которые возникают. Там же я выкладываю ссылки на новые статьи.
Вы делаете резервные копии БД?
