Резервное копирование PostgreSQL по-взрослому

[Maxim_Q]

Если выполнить такую комманду какой размер архива будет и время архивации? Можете протестировать и сказать?

time pg_dump -Ft demo | gzip -9 > backup.sql.gz 

[net0pyr]

pg_dump -Ft demo  0.87s user 1.35s system 2% cpu 1:45.34 total
gzip -9 > backup.sql.gz  98.86s user 0.33s system 94% cpu 1:45.34 total

-rw-r--r-- 1 net0pyr net0pyr 229M May  6 19:56 backup.sql.gz

Время вышло 1 минута 45 секунд
Размер 229M

Спасибо за хороший вариант)

[rPman]

Что бы поиграть со своей базой, ее можно развернуть в виртуальной машине, поддерживающей снапшоты (не только с дисками но и полное состояние, включая оперативную память). Но бакэнд или интерфейс к этой базе данных так же необходимо размещать в этом снапшоте.

В этом случае, создаешь моментальный снапшот, проводишь эксперимент, откатываешь состояние сервера назад, повторяешь. Такие эксперименты будут моментальными, не затрагивающие базу данных.

[rPman]

Интересно, кому это не понравилось и дождусь ли я каких-то аргументов?

Я так автоматизированные тесты организовывал для базы данных, многоуровневые снапшоты (создать объект, запустить тест, откатить, модифицировать, протестировать, откатить дважды... - перед каждым тестом свой снапшот), никакими другими способами не ускорить такие тесты, особенно если база данных занимает не мегабайт а гигабайт

[mmMike]

не знаю кто поставил минус.. Вопрос как вопрос. Другое дело что вопрос вообще не имеет отношения к бэкапам именно PG и имено как БД.
Очень частный случай для каких то не больших тестов или "поиграться".

[rPman]

автор начал с того что хотел поиграть с AI, правда написано непонятно

И как бы сильно я ни любил использовать БД, я просто ненавижу писать SQL-запросы. Поэтому однажды задался вопросом, кто мог бы делать это за меня, при этом несильно теряя в качестве. И, конечно же, на ум пришёл мой AI-друг. Тогда остаётся одна проблема, как скормить ему мою БД.

причем тут 'скормить БД искусственному интеллекту' и 'резервное копирование' сразу не понятно, но так как я уже пробовал играть с ИИ и sql причем по хардкору, хотелось понять, на сколько оно способно на живую работать с базой, а не быть просто stackowerflow на стероидах, а что бы каждый эксперимент не ломал базу, ее можно откатывать назад, я подумал что автор примерно эту задачу пытался решить, а в посте просто неправильно выразился

[mmMike]

Да статья IMHO вообще -отстой-. точнее немного поверхностная. "отстой" - не правильное слово.
Слишком много букв по поводу стандартных утилит PG и, например, ни слова про WAL (журнал PG) и методы реплицирования через него и более глубокие способы/подходы к репликации БД.

Но, впрочем, бурчать по поводу "статья отстой" можно почти многим статья в habre написанных ради "вот мой телеграм канал" и "блок компании".

Но кто то же столько + то наставил статье. Значит кому то это базовая информация по стандартным утилитам PG зашла..
Ну и автор все же птратил веремя на эксперименты и выложил результаты а не просто абстактное blabla

[mvv-rus]

Но кто то же столько + то наставил статье. Значит кому то это базовая информация по стандартным утилитам PG зашла..

Обратите внимание, что статья была опубликована в корпблоге, да ещё и находящемся на первом месте - и вы поймете, что число '+' статье и полезность информации в ней для сторонних читателей не обязательно связаны.

[vitaliy0000]

Таким образом мы можем восстановиться из дампа только с утилитой tar.

Ну, не совсем… Нужна ещё psql. «Восстановиться только с утилитой tar» можно восстанавливаться только после архивирования pg_basebackup-ом. 😉

[santjagocorkez]

Резервное копирование по-взрослому — это реплика инстанс, у которого в момент начала бэкапа рвется канал репликации (других клиентских подключений быть не должно, либо они должны закрываться принудительно перед разрывом реплики), после чего база бэкапится, после чего канал репликации восстанавливается, а база «догоняет» мастер.

[brownfox]

Взрослее всего это устроено у Оракла :)

[rPman]

не нужно рвать 'канал репликации', есть команды для ее приостановки

[Blumfontein]

Pg_dump разве и так не блокнет репликацию?

[morijndael]

Для постгреса не совсем понятно зачем поднимать целую реплику, т.к. можно просто открыть транзакцию на чтение, и для этой транзакции сохранится версия данных на её начало (а параллельно другие транзакции будут спокойно писать новые данные)

Но вообще, для бекапа по протоколу репликации есть встроенная утилита

[mvv-rus]

Есть другой вариант копирования "по-взрослому": для базы, размещенной на СХД создается теневая копия и делается резервная копия данных с этой теневой копии. Желательно, чтобы теневая копия была клоном, а не снимком, чтобы у копии и исходной базы не было общих блоков данных. А ещё желательно, чтобы СУБД умела отрабатывать команду создания теневой копии, оставляя на момент создания базу в согласованном (application-consistent) состоянии. Всё это - технологии нулевых годов, я с ними работал тогда на CLARiiON CX3 и Windows Server 2K и 2K3 (но CLARiiON поддерживал аналогичную функциональность и под Solaris), а БД были MS SQL и MS Exchange 2К3. Кстати на Windows Server что-то такое можно было делать и без СХД (правда, там без СХД в наличии были только снимки, клонов не было).
Жалко, что в PostgreSQL на Linux такие технологии до сих пор AFAIK не завезли, раз такие вот статьи пишутся.

PS Ну, а если таки завезли, я только порадуюсь.

[infene000n]

Как то не по взрослому :-( а ведь это реально проблема т. к. и pg_probackup не решает всех проблем.

[zhogar]

можно ещё выкатить: Репликация в PostgreSQL по-взрослому.. всегда с этим проблемы были.. спасибо

[nitro80]

А чем можно делать (желательно с GUI и расписанием) резервные копии баз 1с на сервере 1С с postgresql?
Использую Обновлятор1С, но у него часто сыпятся ошибки и приходится вручную перезапускать создание резервных копий, иногда по 2-3-4 раза, прежде, чем копия будет создана.
Т.о. нельзя быть совсем уверенным вообще в их наличии.

[tadaima]

Как-то не по-взрослому называть дамп бэкапом...

[morijndael]

От статьи с таким названием я ждала как минимум описания pg_basebackup, но не очередную водичку про дампы которая просто везде :/

[Hemml]

Резервное копирование по-взрослому, это:

1. Включение архивации журнала

2. Периодическое pg_basebackup, например, раз в неделю

3. Инкрементальный бэкап всего сохраненного куда-то вовне, скажем, раз в сутки, а также полный бэкап каждый раз после pg_basebackup. Рекомендую duplicity для этого.

4. Непрерывная синхронизация журналов тоже куда-то вовне.

5. Периодически проверять, что:

   1. Бэкап действительно происходит

   2. Данные можно восстановить

6. Иметь где-то на внешней машине готовые скрипты для восстановления:

   1. Последней копии, подтягивание в том числе "живой синхронизации" на момент сбоя

   2. Восстановления на нужный момент времени, с созданием отдельной БД, на случай, если что-то произошло с базой и нужно достать неиспорченные данные.

Не спрашивайте, как я пришел к такой схеме :(

[outlingo]

Не спрашивайте, как я пришел к такой схеме :(

Не знаю о чем вы, но тогда вам убили сервер БД полностью вместе с дисками, в том числе теми куда клались дампы. Очевидно же.

[outlingo]

В конечном итоге, дамп вы нашли (причем веротно достаточно свежий) - но вот проблема в том, что между моментом снятия дампа и моментом аварии прошло достаточно много времени, и все транзакции за это время были успешно потеряны.

[gsl23]

Как выше написали, какой pgdump, вы о чем ? Название не соотвествует сути.
Серьезное копирование должно включать wal-archiving, соотвественно как следствие, уметь PITR, плюс incremental backup (желетально с block change tracking), если у вас хоть сколь-нибудь серьезные объемы.
Был barman на там нормального инкрмента нет, но все это есть в pg_probackup. Рекомендую. Берите пока дают, cледующий major уже не будет open (