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

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

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

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

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

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

• pg_probackup - на уровне страниц умеет только при использовании ptrack (Что?! Пересобирать сам ПГ?!), без этого расширения - только на уровне файлов;

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

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

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

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

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

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

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