Неудобные вопросы про бэкап PostgreSQL: где заканчивается СУБД и начинается оркестрация

Как только очередной вендор обещает «убить нативные тулзы PostgreSQL», где-то устало вздыхает DBA. Попытка сделать бэкап PostgreSQL «лучше самого PostgreSQL» — это изначально неверная постановка задачи. Универсальный файловый агент не притворяется глубоко PostgreSQL-aware решением. Его задача в другом: взять нативные механизмы СУБД и превратить их в управляемый и наблюдаемый процесс на уровне всей инфраструктуры. Вокруг такого подхода обычно сразу возникают неприятные, но правильные вопросы. Кто отвечает за консистентность? Где на самом деле живет PITR? Что будет, если потеряется WAL-сегмент? Можно ли восстановить одну таблицу, а не весь инстанс? И зачем вообще нужен внешний слой поверх pg_probackup, если у PostgreSQL уже есть свои зрелые инструменты? Под катом — честный разговор о границах ответственности между PostgreSQL и внешней платформой. Кат

https://habr.com/ru/companies/hstx/articles/1015500/

#postgresql #резервное_копирование #бэкап #pitr #wal #dba #pg_probackup #срк #оркестрация #восстановление_данных

Мониторинг бэкапов PostgreSQL, сделанных в pg_probackup

Хочу поделиться с сообществом свой наработкой по мониторингу бэкапов PostgreSQL. Для того чтобы делать сами бэкапы, используется сторонний open source инструмент pg_probackup (разработка компании Postgres Professional). Этот инструмент умеет делать инкрементные бэкапы, а также автоматизирует сопутствующие процессы, такие как, сжатие данных, merge, удаление старых бэкапов и wal-файлов. Остается проблема мониторинга. Предположим, мы настроили pg_probackup и он трудится упорно, вызываемый регулярно через cron. Как мы узнаем, о том, что что-то сломалось? Для решения этой проблемы был написан небольшой экспортер метрик pg_probackup для Prometheus.

https://habr.com/ru/articles/899426/

#pg_probackup #мониторинг #postgresql

Что будет интересного в pg_probackup 3

pg_probackup 3 — не просто обновление, а полная перезагрузка системы резервного копирования PostgreSQL. Пока сообщество затаило дыхание в ожидании релиза, мы разберем по косточкам все ключевые изменения: от полностью переработанной архитектуры и нового репликационного протокола до революционной возможности восстановления отдельных баз данных и поддержки FUSE. Узнайте, как LibProbackup3 – полноценный SDK – открывает новые горизонты для интеграции в любую инфраструктуру, а улучшенная поддержка лент и S3, наконец, решает наболевшие проблемы.

https://habr.com/ru/companies/postgrespro/articles/884432/

#postgresql #probackup #резервное_копирование #базы_данных #postgres #pg_probackup #бекап_базы #восстановление_баз_данных

Обзор открытых свободных инструментов для создания резервных копий СУБД PostgreSQL

Перефразируя древнюю мудрость: все люди делятся на 10 типов: те, кто не знает, зачем нужны резервные копии, и те, кто делает резервные копии. В данном обзоре я попробую мал-мала расшифровать свою давнюю табличку (внеся в неё некоторое количество изменений): Обзор наиболее популярных средств для создания резервных копий PostgreSQL. Ибо не вижу я ни подобных обзоров в информационном поле, ни грамотного, с технической точки зрения, подхода к выбору инструмента вообще, и для создания резервных копий (РК) СУБД PostgreSQL в тех организациях, куда заносит профессиональная деятельность, в частности. Основной аргумент выбора: знания и умения текущего системного администратора. Доводилось встречаться со сменой инструмента по причине того, что новый администратор баз данных не знал и не умел уже использовавшийся продукт. Причём использовался вполне себе достойный, но... (конкретики не будет, по причинам, например, секретным, увы мне).

https://habr.com/ru/articles/820349/

#postgresql #barman #walg #pg_probackup #pgbackrest #резервное_копирование #администрирование_баз_данных #администрирование_бд