Предисловие

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

Большинство обзоров, которые мне попадаются - это сравнение pg_dump/pgdumpall и pg_probackup. pg_basebackup, который является частью оригинального постгреса, упоминается реже, чем pg_probackup. Ни pg_dump/pgdumpall, ни pg_basebackup в обзоре не участвуют, по следующим причинам:

• pg_dump/pg_dumpall - одним из базовых критериев пригодности инструмента для создания РК является требование восстановимости РК. У указанных утилит с этим (восстановимостью) всё очень грустно, а именно, не факт, что созданный дамп восстановится. Ниже я приведу относительно безопасные ключи обеих утилит, но, помимо восстановимости, есть ещё и время восстановления, и прогнозирование этого времени. Так вот, дамп, созданный одной из этих двух утилит, восстанавливается за недетерминированное время. В отличие от бекапов, созданных pg_basebackup или какой-либо утилитой из обзора.

  Поэтому pg_dump/pg_dumpall для создания РК я не рассматриваю.
  Обещанный относительно (ОТНОСИТЕЛЬНО!) безопасный набор ключей (игры с другими приводят к печальным последствиям с очень высокой вероятностью):

  • --clean - добавить DROP DATABASE в дамп;

  • --create - добавить CREATE DATABASE в дамп (только для pg_dump);

  • --schema-only - сдампить только схему, без данных;

  • --no-tablespaces - не дампить информацию о табличных пространствах;

• pg_basebackup - возможности встроенного средства для создания РК даже по сравнению с barman-ом не впечатляют, не говоря уже об остальных продуктах для создания РК, поэтому в обзоре данного инструмента нет; хотя для простых случаев и относительно небольших инстансов этой утилиты вполне достаточно.

Помимо pg_dump/pgdumpall и pg_basebackup стоит объяснить, что же подразумевается под словосочетанием "грамотный выбор с технической точки зрения". Так вот, такой выбор включает в себя:

• определение главной цели, для которой проводится поиск, в данном конкретном случае - создание РК СУБД PostgreSQL;

• формирование списка свойств/критериев/требований, которым должны удовлетворять продукты, позволяющие достигнуть определённой в предыдущем пункте цели;

• формирование списка продуктов, позволяющих решить поставленную задачу, а именно - создание РК СУБД PostgreSQL и, при необходимости, восстановление из созданной РК;

• изучение документации на предмет того, насколько выбранные продукты удовлетворяют сформированныму списку свойств/критериев/требований и для оценки трудоёмкости и сложности инсталляции и сопровождения выбранных средств; уже на этом этапе некоторые продукты могут быть исключены из списка;

• тестирование продуктов из сформированного и отредактированного на предыдущем этапе списка имеющихся продуктов;

• окончательный выбор средства, максимально удовлетворяющего сформированному списку свойств/критериев/требований и решающему поставленную задачу;

• оформление выбора юридически, т.е. приказом/распоряжением по компании, причём в приказе/распоряжении должны отражаться все вышеперечисленные этапы; и этот пункт является самым важным, ибо, как я писал в самом начале, доводилось нередко сталкиваться с ситуациями, когда смена инструмента/ОС была обусловлена либо тем, что новый продукт умеет очередной очень "грамотный" системный администратор, либо такому системному администратору захотелось поиграться.

На этом вводную часть я заканчиваю, и приступаю собственно к обзору наиболее популярных открытых свободных инструментов для создания резервных копий СУБД PostgreSQL.

В обзоре, каковой представляет из себя ничто иное, как таблицу, участвуют четыре инструмента:

• barman этот продукт представляет собой интерфейс к двум режимам создания РК с помощью встроенных в (поставляемых с) СУБД возможностей создания РК.

  1. старый (до версии 9.0 физические РК на горячую создавались только таким способом): pg_backup_start ( label text [, fast boolean] ) && <копирование файлов инстанса> && pg_backup_stop (до 14-й версии включительно: pg_start_backup ... pg_stop_backup)

  2. новый (с версии 9.0): pg_basebackup

• pg_probackup ВНИМАНИЕ! в обзоре рассматривается только открытая свободная версия, доступная с гитхаба! Postgres Pro Backup Enterprise в обзоре не участвует.

• pgbackrest

• wal-g

Таблица сравнения

Расшифровка таблицы

• Документация - от качества документации очень сильно зависит требование к квалификации пользователя ПО, я очень надеюсь, что никто не будет возражать против этого утверждения; Собственно, расшифровка оценки документации каждого продукта:

  • документация по barnam-у и pg_probackup-у не вызывает никаких нареканий: все просто и понятно, изучаешь, ставишь продукт и используешь его;

  • документация по pgbackrest-у имеет один недостаток: нет описания конфигурационного файла, что не есть хорошо, например, для написания ансибловой роли пришлось искать примеры;

  • документация по wal-g... я одно скажу: просветление, как создать РК, меня так и не посетило. Хотя времени на изучение доки по этому продукту я затратил больше, чем на остальные вместе взятые;

• Поддерживаемые СУБД - если у вас используется ПгПро, то использование отличных от pg_probackup инструментов теоретически может привести к проблемам, ну не знают остальные про ПгПро!

• ЯП(язык программирования) - написан ли инструмент на интерпретируемом ЯП или компилируемом. Ибо интерпретатор, как правило, тащит за собой ещё гору всякого разного, а если этот интерпретатор ещё и экзотический какой-нибудь... Фантомные боли (пока писал эту статью, фантомные боли перестали быть фантомными, правда в другом ПО: https://github.com/cobbler/cobbler/issues/3692, никогда не было, и вот опять!) от изменения поведения интерпретатора при обновлении - они никуда не делись. Питон - это не экзотический интерпретатор, поэтому при обсуждении вот этих конкретных продуктов данный критерий носит больше информационный характер;

• Пакеты ОС - это очень важный критерий с точки зрения требований к квалификации сотрудников эксплуатации (ибо захламлять систему тупым копированием бинарников куда и как попало - это неправильно!). Мало того, исполняемый файл wal-g существует только для Ubuntu 20.04: https://github.com/wal-g/wal-g/releases/tag/v3.0.0 или у меня с глазами проблемы, но я вижу бинарники только для указанного дистрибутива и соответствующей версии; исполняемые файлы для всех остальных систем/версий Ubuntu собираете из исходников; если у вас другой дистрибутив, то wal-g в общем случае - не для вас;

• Конфигурирование - расшифровка:

  • barman - общие настройки живут в главном конфиге barman.conf, конфиги инстансов живут в каталоге barman.d (на самом деле наименование каталога зависит от дистрибутива) в одноимённых с наименованием инстанса и суффиксом .conf файлах; возможность хранить конфигурацию в одном файле ПОКА есть, но уже объявлена устаревшей;

  • pg_probackup - для каждого инстанса параметры могут быть заданы в конфиге после создания; НО! задаются параметры не редактированием конфигурационного файла (дока вот что говорит: It is not recommended to edit pg_probackup.conf manually.), а с помощью команды set-config утилиты pg_probackup; в общем случае используются ключи командной строки, что не очень удобно с точки зрения автоматизации конфигурирования;

  • pgbackrest - один конфиг на всё, по рассматриваемому критерию - вне конкуренции, особенно с точки зрения автоматизации (один шаблон, один конфиг);

  • wal-g - либо переменные окружения; либо конфиг; либо ключи командной строки: выбирай на вкус!

• Сжатие - сжатие архивов, очень важный критерий, т.к. экономия места - это довольно-таки критичное требование; но у всех рассматриваемых продуктов с этим всё в порядке;

• Шифрование - шифрование архивов; данный критерий вполне себе может быть выдвинут СБ/ИБ, barman шифрует через куки, остальные - флагами команд и/или соответствующими параметрами конфигурации;

• Параллельные РК/восстановление - создание РК в несколько потоков, и/или восстановление инстанса в таком режиме позволяет ну очень существенно экономить время; barman умеет так только в rsync-режиме; pg_probackup, pgbackrest и wal-g умеют;

• РК нескольких инстансов - ситуация, когда для каждого инстанса/кластера ПГ надо свой сервер РК, не очень хорошая, я думаю, поэтому в списке критериев присутствует. При этом необходимо понимать, что barman просто читает соответствующие конфиги; pg_probackup и pgbackrest требуют инициализации соответствующих структур, первый - instance, второй - stanza; wal-g требует либо создания соответствующего конфига, либо установки переменных окружения, либо указания параметров командной строки, что совсем не добавляет радости от использования, опять же с точки зрения централизованной автоматизации конфигурирования;

• РК реплики - восстановление РК, снятой с реплики - вопрос непраздный, поэтому в списке критериев присутствует, судя по имеющейся информации, у всех рассматриваемых продуктов эта функциональность есть;

• Инкрементальные РК - экономия места необходима, соответственно, инкрементальные РК - это суровая жизненная необходимость, а не прихоть; (на уровне файлов - это копируются изменённые файлы БД целиком)

  • barnam - умеет только на уровне файлов и в режиме rsync; ждём 17-ю версию постгреса, там обещают встроенные в pg_basebackup инкрементальные РК;

  • pg_probackup - слово Егору Рогову и спасибо ему за уточнение:

    Можно и без ptrack, в режимах page или delta;

  • pgbackrest начиная с версии 2.46 умеет в инкрементальные РК на уровне блоков;

  • wal-g - уважаемые читатели информируют, что на уровне блоков;

• Скачивание WAL-ов - pgbackrest умеет только в archive_command, остальные могут забирать WAL-ы, инициируя соединение с сервера РК; этот и следующий пункты имеют под собой требования безопасности, а именно: с сервера БД не должно быть доступа к РК, чтобы при компрометации этого сервера нарушитель не смог получить доступ и к РК (когда используется archive_command данное требование не выполняется);

• Восстановление по сети - все по через SSH могут;

• Ротация РК - wal-g - вручную, с помощью команды delete garbage, остальные выполняют ротацию в процессе создания резервных копий согласно настроек; поясняю:

  • barman, подпункт "Retention policies";

  • pg_probackup;

  • pg_backrest;

• Проверка РК - непроверенный бекап тождественно равен отсутствию бекапа. Не я придумал, и опротестовывать не буду; и хотя производители всех инструментов декларируют возможность проверки целостности бекапа, процедура проверки восстановления должна быть регламентной и регулярной; бережёного Бог бережёт!

• Частичное восстановление - а именно, восстановление только указанных БД; на самом деле, возможность довольно-таки сомнительная, с учётом самой процедуры восстановления. Ибо при восстановлении надо проиграть все WAL-ы, которые были созданы после запуска создания бекапа; а в тех WAL-ах наверняка есть изменённые данные и из других БД, так что... Восстановить весь инстанс, а затем грохнуть ненужные БД - это существенно проще (но может быть сильно затратнее по времени);

• Табличные пространства - умеют ли рассматриваемые инструменты перемещать табличные пространства в отличное от исходника место? Умеют, кроме wal-g (ну или я опять же невнимательно изучал документацию); поясню ссылками на документацию:

  • barman, пункт называется "Tablespace remapping";

  • pg_probackup, описание ключика --tablespace-mapping;

  • pg_backrest;

Выводы? Это обзор, какие выводы?! Я только показал наиболее популярные инструменты для создания резервных копий СУБД PostgreSQL.
Хотя аутсайдер, который не хочется использовать, а именно - wal-g, таки присутствует. Вы можете меня обвинить в том, что я плохо читал/изучал документацию по этому продукту. И такое обвинение будет справедливым. Наверное. НО!

• это не я документацию не умею читать, а производители не умеют писать! У остальных рассматриваемых продуктов с документацией всё в порядке (см. соответствующую запись в таблице и расшифровку). Зачем я буду ломать себе голову, когда рядом есть более функциональные утилиты с намного более простой и понятной документацией?

• отсутствие пакетов!

UPD01. Уважаемые коллеги, прошу прощения, но карма не позволяет мне отвечать на комментарии чаще, чем раз в час. Увы мне.
UPD02. Внёс уточнения по пунктам "Параллельные РК/восстановление", "РК реплики" и "Инкрементальные РК" для wal-g.
UPD03. По причине усталости перепутал поддерживаемые хранилища между pg_probackup и pgbackrest, исправил, за указание на этот недостаток спасибо коллегам с предыдущих мест трудовой деятельности, а также за некоторое количество интересных интересностей по поводу Postgres Pro Backup Enterprise (уточнил в самом начале, что рассматривается только свободная и открытая версия pg_probackup); Егор Рогов, спасибо ему огромное, уточнил, что pg_probackup таки умеет в инкрементальные РК без ptrack; ну и расшифровал ротацию бекапов и перемещение табличных пространств в момент восстановления СУБД из РК;
UPD04. В информацию о хранилищах закрались неточности, поправил, спасибо коллегам;