Обзор открытых свободных инструментов для создания резервных копий СУБД PostgreSQL10.06.2024 03:00

Предисловие

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

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

• РК реплики — восстановление РК, снятой с реплики — вопрос непраздный, поэтому в списке критериев присутствует, как дела обстоят у 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 (ну или я опять же невнимательно изучал документацию);

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

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

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

© Habrahabr.ru