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

Предисловие

Перефразируя древнюю мудрость: все люди делятся на 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

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

Параметры\инструмент	barman	pg_probackup	pgbackrest	wal-g
Документация	хорошая	хорошая	удовлетворительная	отвратная
Поддерживаемые СУБД	PostgreSQL	PostgreSQL PostgresPro Standart PostgresPro Enterprise	PostgreSQL
ЯП	Python >= 3.6	C	C	Go
Пакеты ОС	Есть	Есть	Есть	Нет
Конфигурирование	конфиг + конфиги	конфиги	конфиг	по-разному
Сжатие	Есть	Есть	Есть	Есть
Шифрование	Есть(хуки)	Есть	Есть	Есть
Параллельные РК/восстановление	Есть(rsync)	Есть	Есть	Есть
РК нескольких инстансов	Есть	Есть	Есть	Есть
РК реплики	Есть	Есть	Есть	Есть
Инкрементальные РК	Есть(rsync)	Есть(ptrack)	Есть	Есть
Скачивание WAL-ов	Есть	Есть	archive_command	Есть
Восстановление по сети	Есть	Есть	Есть	Есть
Ротация РК	Есть	Есть	Есть	Вручную
Проверка РК	Есть	Есть	Есть	Есть
Частичное восстановление	Нет	Есть	Есть	Эксперимент
Табличные пространства	Есть	Есть	Есть	Неизвестно
Хуки	Есть	Нет	Нет	Нет
Поддерживаемые хранилища	LocalFS AWS S3 Azure GCS	LocalFS	LocalFS AWS S3 Azure GCS	LocalFS AWS S3 Azure GCS Swift SSH

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

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

  • документация по 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. В информацию о хранилищах закрались неточности, поправил, спасибо коллегам;