Comments 34
Что делает бизнес, чтобы не обнаружить, что восстанавливать продовую БД нужно из месячной давности бэкапа? Нанимает админа до.
Что делает разработчик-стартапер, когда обнаруживает месячный бэкап? Пишет свою вебморду для pg_dump после :)
Ничего не могу сказать, достойный подход.
Что именно вы понимаете под "бизнес"?
У меня был мелкий проект, где денег хватало на сервер, доступ к API и немного на маркетинг. Это не тот проект, где имеет смысл нанимать сис. админа. Собственно, проект для таких же
Но, как я и написал — ошибка глупая, моя личная, сам виноват. Причина не в инструменте, а в человеческом факторе :). Нужно было проверять, что бекапы делаются, аккуратнее писать запрос и проблемы не было бы
А Postgresus не для решения проблемы "бекапов" в целом, а просто маленькое улучшение UX. Чтобы на одном экране удобно добавить базы за 30 секунд без CLI, выбрать расписание и быть спокойным
Под бизнесом я имею в виду группу людей с некой идеей и желанием на ней заработать. Хорошо, когда они нанимают профессиональных управленцев, которые знают большую часть проблематичных мест, одно из которых в айти, как раз - начинать проект без предварительной подготовки инфраструктуры под него.
Для мелкого проекта админ в штате не нужен, тут с вами соглашусь - достаточно купить несколько часов опытного фрилансера.
Я так мониторинг (https://my.okerr.com) делал. После нескольких этапов апгрейда себя. (каждый может прочитать и поставить себе метку ">>> вы сейчас здесь <<<" на соответствующем пункте)
Не делаем бэкапы (бэкапы для трусов!). Сервер падает. Бэкапов нет. Ура, мы получили ценный жизненный опыт!
Делаем бэкапы. Падает. Ищем... о, а последний бэкап мы делали полгода назад.... Ура, левел-ап!
Делаем бэкапы скриптом. Падаем. Смотрим... а их нету. Оказалось, скрипт перестал работать полгода назад. (Например - перенесли что-то в другой каталог, а скрипт исполнительно бэкапил прежний каталог). Левел-ап!
Делаем бэкап в два скрипта. Бэкапный скрипт бэкапит. Контролирующий скрипт каждый день шлет назойливые сообщения "ну все окей, мы и сегодня успешно забекапили файл такой-то". Они раздражают, бесят. В инбоксе и так десятки писем. Потом они пропадают (потому что у нас помер и бэкапный скрипт и контролирующий), но в рабочей суете даже и не замечаешь, что они пропали. Потом падает сервер. Левел-ап!
Пробуем "инвертировать" логику контрольного скрипта. Теперь если все ОК - он молчит. А если не ОК (если новых бэкапов не создано) - шлет тревожное письмо. Но.... сами понимаете, как нас это защитить от ситуации, когда сам контрольный скрипт почему-то помер?
Так и дошел до понимания, что единственный надежный контроль за бекапами должен быть:
По принципу watchdog - пока каждый день есть новые бэкапы - он спит, но если сутки прошли, и бэкапов нет (или есть, но почему-то его не оповестили) - поднимает тревогу
Он должен быть внешним. Не зависящим от тех же проблем, которые влияют на вашу систему. В идеале - вообще в другом дата-центре в другой стране.
Он должен ловить простые аномалии (например, если вдруг бэкап стал на 10% меньше чем был вчера - странненько!)
Сейчас он мониторит все - температуру процессоров, load average, протухание SSL сертификатов, то что нужные URLы дают 200, а другие нужные - 403, а третьи - имеют тот же текст, что и раньше (и тревога, если что-то поменялось), итд. Что не умеет мониторить нативно - то можно сделать простым шелл-скриптом (ну или на любом другом языке программирования, просто сделать проверку и print() в нужном формате), но делалось - именно как надежный контроль бэкапов для параноиков.
Кайф, то есть в какой-то момент вы повторили Заббикс с userparameter в шаблононах :)
Не знаю, про "заббикс с userparamter в шаблонах", мне он показался излишне сложным и "для другого" (то что в окерре изкоробки, там можно накрутить при должном терпении, но зачем?). Но я в несколько кликов за меньше чем минуту делаю мониторинг нужного доменного имени или сертификата или страницы. А чтобы в каталоге бэкапов он автоматотом начал отслеживать, скажем, бекапы вида serverX-20250714.tar.gz достаточно просто один раз их туда кинуть и больше ничего не делать - автоматически создастся индикатор для serverX и если не будет нового файла сутки - он запаникует, пошлет алерты на почту и в телегу.
Упор не на мониторинг в значении "программа нарисовала график, а ты сиди и смотри в него" (как в графане), а в значении "мониторинг сам мониторит, если что-то не так - получишь алерт". Алерты к каждому индикатору по-умолчанию приделаны (это чтобы их отключить надо пару раз кликнуть, а чтобы включить - ничего кликать не надо, совсем).
Сейчас работаем по принципу, что каждая новая неожиданная проблема может случиться только один раз. А после этого - для нее пишется простая проверка (внутренняя, изнутри сервера, или внешняя). Предсказуемые проблемы (типа протухания сертификатов, кончания места на диске) - предсказываются, непредсказуемые - обнаруживаются и часто фиксятся еще до того, как клиенты позвонят.
Единственное - винду изнутри не может никак мониторить (ну или может - клиентская часть на пайтоне), но не пробовал и упора на это никакого нет. Писалось для своих нужд в первую очередь (небольшая компания с linux, а не гигантские, для которых пишутся большинство зрелых мониторингов), а раз у нас винды нет - то и пофиг на нее :-). Ну и графики там - "так себе" (есть, но упор не на них), для красоты у нас графана есть :-).
Limit 1 нервно курит в сторонке.
Спасибо за пост. А через код можно настроить postgresus ?
А зачем именно через код?
Вообще... нет. Я наоборот старался, чтобы не нужно было ничего делать в коде \ конфигах \ .env файлах. Чтобы всё было в UI и максимально тривиально без CLI
А зачем именно через код?
потому что это удобно. зачем часами настраивать вручную везде одно и то же если можно поправить пару переменных в ansible inventory и задеплоить одной командой, зачем бекапить конфиги если можно их восстановить из iac одной командой, зачем кричать через весь офис "какой мудак это сделал" если можно посмотреть в истории гитовых коммитов кто и когда это сделал..
IaC это лучшее что изобрело человечество!
P.S.: это не отменяет настройку через UI. хороший софт обычно является универсальным, чтобы можно было нужные настройки и в конфиге прописать, и через env передать, и в вебморде мышкой натыкать. а идеальный софт ещё имеет возможность оставить только один из способов выключив остальные.
конкретно в этом софте я бы иаку предпочел бы апиху. под иак скорее оператора придется писать, а их как бы уже есть на рынке и поддерживаемых целыми командами.
а вот апиху сюда бы можно было, да. конфигурить действительно есть что, когда баз не 2-3. тем более, что под капотом, судя по коду, вполне себе backend <> frontend с контроллерами и методами.
«Люди делятся на две категории: кто еще не делает бэкапы, и кто их уже делает»
А как так вышло, что поле “email” не было ключом/только уникальным ?
Делать коробки все в одном, имхо, для опенсорса это странное решение. Разумеется если это для кровавого ынтерпрайза, да еще если это проприетарь за бешеные доллары - тогда это база.
Совеременные IT продукты довольно сложные, в них и без того много сущностей, источников разных событий, метрик, алертов и т.д. Если вы будете для метрик, алертинга, рисования графиков использовать свои велоспеды, то вы будете сильно увеличивать сложность вашего продукта.
Каноническим инструментов мониторинга и алертинга в современном IT является prometheus, отправщиком вебхуков - alertmanager, рисователем графиков - grafana. Почему бы не использовать их? Сколько времени можно съэкономить на отсутствии необходимости их разрабатывать и вникать в кустомные велосипеды при эксплуатации. А уж вопросы интеграции даже обсуждать нечего.
Сам типичный инстанс postgresql бекаплю 2мя независимыми путями (все деплоится и параметризуется через ansible (включая helm), все в контейнерах, частично в кубере):
PITR: wal-g для wal + shell обертка вокруг wal-g генерирующая prometheus метрики/статус для basebackup'ов + скрипт python генерирующий prometheus метрики о состоянии бекапов в хранилище (например о пропущеном сегменте или отсутствии изменений в течении периода) из вывода wal-g (да, используя exeс) + cronjob python восстанавливатеть бекапов с прогоном стандартных тестов (встроенный тест целостности и
pg_dump > /dev/null) и пушатель результата в prometheus pushgw.Архив: shell обертка вокруг restic: получение списка баз, последовательный бекап каждой базы (
pg_dump | restic backup --stdin, т.е. без сохранения промежуточного состояния на диск) в отдельный репозиторий, экспорт prometheus метрик для каждой базы. Хочу когда-нибудь прикрутить восстновление и сюда. Но беда в том что для дампов нарушается прозрачность процесса восстановления. При восстановлении нужно чтобы были созданы например роли присутствующие в дампе. Не придумал красивого решения, как это не сопровождать и чтобы оно не ломалось.
Когда соберусь менять место работы попрошу разрешения работодателя заопенсорсить (больше для самого себя, использовать в будущем, не повторять эту работу). Сейчас увы нет времени и мотивации причесывать до такого состояния чтобы было не стыдно выкладывать в паблик.
Исходя из вашего комментария, чтобы бекапить \ мониторить БД простому бекенд разработчику уровня junior-middle нужно:
поставить где-то экспортер данных из БД;
разобраться в Prometheus, развернуть и настроить;
разобраться в Grafana, развернуть и настроить;
разобраться в alertmanager и настроить, исходя из событий Prometheus;
написать скрипты для бекапов;
Имхо, для человека, который не DevOps \ админ \ отвечает за инфру \ Senior'a - явный перебор. Каждый раз, когда я всё это разворачиваю - у меня уходит день-два + болит голова, а всё ли актуально \ не отвалится ли чего.
Ну и нужно не забывать про поддержку этого, когда разработчики в команде меняются.
А проект, который я делаю:
развернуть скриптом за 2 минуты;
добавить БД за 1 минуту;
подрубить ТГ бота за (если разобраться) 5 минут.
И готово!
Разумеется, это не подходит для серьёзного мониторинга, больших проектов и т.д. Для основного моего рабочего проекта у меня всё и настроено +- как вы описали (+ ещё метрики из облака тащу скриптами в Prometheus).
Но для большинства маленьких-средних проектов, которым достаточно мониторить БД - Postegusus'a будет с головой. А главное быстро и удобно. Но это точно не серебрянная пуля.
Затем отвлёкся, чтобы посмотреть нужную почту в чате и... на автомате нажал Enter. После чего увидел что-то в духе AFFECTED ROWS: 10 000.
Я вот когда-то давно много работал с Interbase через его утилиту Windows ISQL, и меня бы такое сообщение не привело бы в отчаяние. А всё потому, что Interbase использовал многоверсионную схему хранения, и старые записи никужа не девались. А утилита транзакцию автоматически не закрывала - нужно было руками закрыть, через интерфейс.Так что, увидев нечто неожиданное (бывало и такое), я просто откатил бы транзакцию, и всё.
Это я к тому, что PostgreSQL тоже, говорят, поддерживает многоверсионную схему хранения, и если бы разрабочики утилиты для выполнения SQL задумались о том, чтобы не закрывать автоматом транзакции, вам было бы в тот момент легче.
А вообще, править данные в боевой базе через SQL - это плохая практика, примерно столь же плохая, как и не делать резервные копии.
PS А админы всё же делятся на тех, кто делает бэкап и тех, кто ещё не терял данные.
Из предыдущей статьи автора:
Ну я и полез в базу, чтобы обновить SQL-скриптом одну почту. Написал сначала скрипт WHERE, чтобы проверить выбор только одной почты. Затем для такого же WHERE написал уже UPDATE скрипт. И, по всей видимости, где-то не закрыл скобку. Запустил. Через секунду все ~25 000 почт стали NULL. В момент у меня пошёл холодный пот по спине и я подвис на две минуты. Но бекапы были на месте, я восстановился и пошёл менять футболку на сухую. Оказалось, дропнуть базу на проде действительно можно.
Как будто бы та же история, а как будто и не понятно где правда.
Спасибо, не обратил внимание
В прошлый раз я сократил путь про это восстановление, чтобы не растягивать без того долгую статью и... немного не перепроверил данные, написал "примерно" по памяти (всё-таки не самый важный момент)
Для этой статьи я полез в сообщения того дня и нашёл конкретные цифры и +- точную хронологию. 25к было в момент закрытия проекта, 10к в момент дропа базы - поправил цифру в старой статье
Именно поэтому я все подобные скрипты сначала оборачиваю в транзакцию, которую явно откатываю в конце (для "боевого" выполнения надо раскоментить строчку с коммитом транзакции).
Да и то бывают нюансы - зачастую есть возможность выполнить выделенный скрипт... И UPDATE-SET часть скрипта - вполне валидный скрипт, даже без выделения WHERE-части... Благо, что на "боевых" базах не попадался на подобный прикол...
Да, но... pg_dump это не то чтобы про бэкапы, это скорее экспорт в sql statements, который в случае маленьких баз может служить в качестве бэкапов. Как только ваша база становится сколь-нибудь ощутимого размера и у вас появляются сколь-нибудь жёсткие требования ко времени восстановления - ну привет, бинарный бэкап и wal.
Насколько это актуально при использовании https://github.com/cloudnative-pg/cloudnative-pg ?
Не могу ответить, не пользовался
Да почти не актуально. Там свое есть, правда сразу кластером, а не отдельной базой. А что бы отдельно и манифестами - я свое пилил - https://github.com/vasyakrg/pgdump-s3
Кстати, с заландой у меня вышло так же - родной бекап там та еще кака.
Как я пришёл в open source в 2025-м (с утилитой для бекапа PostgreSQL), чуть не потеряв проект на ~$1500\мес в 2023-м