Я потерял свою производственную базу данных на ночь - здесь инструмент, который я построил, так что вы не
25 июля 2025 г.Как только я уничтожил свой производственный DB со сонным обновлением и не имел свежих резервных копий. Потерял ~ 30% дохода, кучу нервов и слишком много часов. Эта боль заставила меня создать и открыть источник инструмента резервного копирования и мониторинга PostgreSQL, который я сейчас использую везде.
Таблица контента
- О проекте резервного копирования с открытым исходным кодом
- История о том, как я сломал БД и не смог полностью восстановиться
- Как я начал строить проект
- Дорожная карта и планы на будущее
- Правила безопасности DB, которые я сейчас применяю в каждом проекте
- Заворачивать
О проекте резервного копирования с открытым исходным кодом
Я открыл свой собственный инструмент для мониторинга и резервного копирования PostgreSQL. Я строил и использую его чуть более двух лет. Первоначально я разработал его для своей повседневной работы и нескольких домашних проектов.
Только недавно меня поразило, что проект действительно выглядит достаточно хорошо, чтобы показать публично, он уже помогает моим друзьям и может быть полезен для сообщества.
Куча:Go, Gin, Gorm, React, TypeScript, PostgreSQL - все обернуто в Docker. Самая первая версия была в Java, но я переписал ее, чтобы пройти время.
По сути, это обертка пользовательского интерфейса вокруг стандартаpg_dumpВ пользовательском формате, с кучей дополнительных, которые делают UX менее болезненным, и добавляют интеграцию с внешними службами хранения и уведомлений.
Что он может сделать:
- Расписание резервных копий (например, каждый день в 4 утра или каждое воскресенье в полночь) для PostgreSQL 13–17.
- Храните сжатые резервные копии локально на сервере, в S3 или Google Drive (NS -серверы и FTP находятся на дорожной карте).
- Отправьте вам сообщение после каждой резервной копии, что все в порядке ... или нет. Уведомления являются необязательными.
- Пинг вас в разногласий, электронной почте, телеграмме и Slack, если БД перестает отвечать. Это только предупреждает после
nНеудачные проверки (чтобы избежать ложных срабатываний из -за сетевых сбоев) и показывают график доступности.
Естественно, проект бесплатный, с открытым исходным кодом (MIT), самостоятельно и поставляется с гуманным веб-интерфейсом.
Сайт проекта:
GitHub:
П.с. Если проект выглядит полезным, и у вас есть учетная запись GitHub,Я очень признателен⭐. Первые звезды действительно труднее всего получить.
История о том, как я сломал БД и не смог полностью восстановиться
Еще в 2023 году у меня был Pet Project, который был оберткой Chatgpt (3.5). По сути, это было просто перепродажи API -доступ с помощью красивого пользовательского интерфейса и ярлыков. Проект вырос, затем начал падать, и я наконец продал его. БД поддерживался один раз в день с помощью инструмента консоли, какPgBackRestна другой сервер.
В тот момент, когда проект пассивно приносил около 1500 долларов и достигал своего пика доходов, случилось что -то плохое: произошло: что -то плохое:Я сломал данные в БДПолем
Это был вечер пятницы. Я устал, я мгновенно перешел от кодирования на ответные сообщения, совершенно не сфокусирован. Клиент попросил меня изменить электронное письмо для его учетной записи.
Через SSH иpsqlЯ прыгнул в производственный VPS и напечатал что -то вроде:
UPDATE users SET email = 'customer@email.com' WHERE email ILIKE '%%';
Затем я отвлекался, чтобы скопировать правильное письмо из чата и… нажмите Enter на «Автопилот». Следующее, что я увидел, было чем -то вродеAFFECTED ROWS: 10 000Полем
Это был единственный раз за многие, много лет, я буквально чувствовал холодный пот на спине.
Отказ от ответственности: Конечно, я знал, что должен был сделатьSELECTВо -первых, может установитьSAVEPOINTи т. Д. Но, как и в каждой истории ужасов, основные правила безопасности были проигнорированы, и все это превратилось в катастрофу.
Все пользовательские электронные письма были перезаписаны. И вот ключевая деталь: платежные системы имеют строгие правила - если пользователь не может получить доступ к оплачиваемой услуге, это огромное нарушение. Естественно, никто больше не мог войти в систему, и жалобы начали кататься.
Я побежал в резервные копии - и холодный пот стал еще хуже. Самая последняя резервная копия была около месяца 😐. Нет возможности восстановить из этого. С того времени появились новые платежи, подписки были отменены (то есть я не мог просто восстановить всех - некоторые люди уже ушли) и т. Д.
Каким -то образом, в течение остальной части ночи и утра мне удалось реконструировать около 65% БД с помощью сценариев с помощью идентификаторов пользователей. В остальном мне пришлось отменить подписки и вернуть людей. Это было болезненно, неприятно и дорого.
Урок был усвоен.
Как я начал строить проект
Время решения: я собираюсь создать себе резервный инструмент, который будет пинговать меня каждый день, что все в порядке! И восстановить в нескольких кликах! И блэкджек и микросервисы! И я тоже добавлю конечную точку проверки API!
Я сделал первую версию Postgresus примерно за месяц в Java. Начал использовать его. Позвольте нескольким друзьям попробовать это. Продолжал полировать это на основе моих потребностей и их обратной связи.
Оказался: это полезно. Несколько раз эти резервные копии спасли меня (и не только я). Название «Postgresus» появился только два месяца назад, прежде чем репо просто вызвано«PG-WEB-BACKUP»Полем
Прямо сейчас Postgresus решает эти проблемы для меня:
- Это главный инструмент резервного копированияЕсли проект маленький или живет на VPS вместо облачного сервиса DB.
- Это инструмент резервного резервного копированияЕсли проект большой и живет в DBAAS с собственными облачными резервными копиями.
Он подтверждает «на всякий случай» (если облако умирает, блокируется, БД случайно удаляется вместе с резервными копиями облаков из-за неплаты и т. Д.). Всегда лучше иметь повторяющуюся резервную копию, чем в конечном итоге в том, что не повезло на 0,01%, когда даже облако исчезает, и нет плана B.
Дорожная карта и планы на будущее я планирую продвигать проект в этих направлениях:
Добавьте больше специфического мониторинга нагрузки (PG_STAT_ACTICTION, PG_STAT_SYSTEM, PG_LOCKS) с дружественным пользовательским интерфейсом. Думайте об этом как о альтернативе Postgres_exporter + Grafana, но вылетел из коробки с резервными копиями.
Наблюдайте и предупреждайте о замедлении ключевых запросов.
В моем рабочем проекте есть таблицы и конкретные функции, которые слишком рано, чтобы оптимизировать (если гипотеза не удается, мы могли бы их бросить), но они могут расти и замедляться.
Например, если вставить в значения пользователей (...) (...) начинает принимать более 100 мс, пока растет поток новых пользователей - мы получим уведомление и перейдем к оптимизации.
Собирайте статистику запросов по времени и частоте выполнения процессора, чтобы увидеть, куда на самом деле идут ресурсы и что стоит улучшить.
Добавьте больше каналов для уведомлений и больше поставщиков хранения.
Правила безопасности DB, которые я сейчас применяю в каждом проекте
Позвольте мне напомнить вам о двух частях народной мудрости:
Системные администраторы делятся на две категории: те, кто еще не делает резервные копии, и те, кто уже это делает.
Не просто делайте резервные копии - регулярно проверяйте, что вы можете восстановить из них.
С тех пор, как я без исключения принял DB моего проекта, я принял эти правила:
- Раньше
UPDATE, всегда бегитеSELECTИ убедитесь, что вы касаетесь ровно 1-2 ряда. - Если изменение большое - установите
SAVEPOINTвручную. - Проведите «пожарные сигналы» с восстановлением не реже одного раза в 3 месяца: восстанавливайте из облачной копии и из локальной. Поэтому, когда это имеет значение, вы не обнаруживаете, что нет данных, резервные копии не работают или восстанавливаются вечно.
В последние два года было несколько случаев, когда нам нужно было восстановить из резервных копий - каждый раз, когда это работало, как в облаке, так и через Postgresus. Нет проблем, потому что процесс уже был сглажен во время тестов. Основные правила безопасности работают.
Заворачивать
Я надеюсь, что этот проект будет полезен для широкого набора разработчиков, DBAS и DevOps. Я планирую продолжать развивать его, чтобы сделать его еще более полезным в реальных сценариях. Я рад услышать какие -либо предложения и отзывы о улучшении.
Оригинал