Предисловие
Перефразируя древнюю мудрость: все люди делятся на 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
этот продукт представляет собой интерфейс к двум режимам создания РК с помощью встроенных в (поставляемых с) СУБД возможностей создания РК.-
старый (до версии 9.0 физические РК на горячую создавались только таким способом):
pg_backup_start ( label text [, fast boolean] )
&& <копирование файлов инстанса> &&pg_backup_stop
(до 14-й версии включительно:pg_start_backup
…pg_stop_backup
) -
новый (с версии 9.0):
pg_basebackup
-
Таблица сравнения
Параметры\инструмент |
|
|
|
|
---|---|---|---|---|
Документация |
хорошая |
хорошая |
удовлетворительная |
отвратная |
— |
— |
— |
— |
— |
Поддерживаемые СУБД |
PostgreSQL |
PostgreSQL PostgresPro Standart PostgresPro Enterprise |
PostgreSQL |
|
— |
— |
— |
— |
— |
ЯП |
Python >= 3.6 |
C |
C |
Go |
— |
— |
— |
— |
— |
Пакеты ОС |
Есть |
Есть |
Есть |
Нет |
— |
— |
— |
— |
— |
Конфигурирование |
конфиг + конфиги |
конфиги |
конфиг |
по-разному |
— |
— |
— |
— |
— |
Сжатие |
Есть |
Есть |
Есть |
Есть |
— |
— |
— |
— |
— |
Шифрование |
Есть(хуки) |
Есть |
Есть |
Есть |
— |
— |
— |
— |
— |
Параллельные РК/восстановление |
Есть(rsync) |
Есть |
Есть |
Неизвестно |
— |
— |
— |
— |
— |
РК нескольких инстансов |
Есть |
Есть |
Есть |
Есть |
— |
— |
— |
— |
— |
РК реплики |
Есть |
Есть |
Есть |
Неизвестно |
— |
— |
— |
— |
— |
Инкрементальные РК |
Есть(rsync) |
Есть(ptrack) |
Есть |
Есть(?) |
— |
— |
— |
— |
— |
Скачивание |
Есть |
Есть |
|
Есть |
— |
— |
— |
— |
— |
Восстановление по сети |
Есть |
Есть |
Есть |
Есть |
— |
— |
— |
— |
— |
Ротация РК |
Есть |
Есть |
Есть |
Вручную |
— |
— |
— |
— |
— |
Проверка РК |
Есть |
Есть |
Есть |
Есть |
— |
— |
— |
— |
— |
Частичное восстановление |
Нет |
Есть |
Есть |
Эксперимент |
— |
— |
— |
— |
— |
Табличные пространства |
Есть |
Есть |
Есть |
Неизвестно |
— |
— |
— |
— |
— |
Хуки |
Есть |
Нет |
Нет |
Нет |
— |
— |
— |
— |
— |
Поддерживаемые хранилища |
LocalFS AWS S3 Azure GCS Storage(REST API) |
LocalFS AWS S3 Azure GCS Storage(REST API) |
LocalFS |
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
требует либо создания соответствующего конфига, либо установки переменных окружения, либо указания параметров командной строки, что совсем не добавляет радости от использования, опять же с точки зрения централизованной автоматизации конфигурирования; -
РК реплики — восстановление РК, снятой с реплики — вопрос непраздный, поэтому в списке критериев присутствует, как дела обстоят у
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
, таки присутствует. Вы можете меня обвинить в том, что я плохо читал/изучал документацию по этому продукту. И такое обвинение будет справедливым. Наверное. НО!
-
это не я документацию не умею читать, а производители не умеют писать! У остальных рассматриваемых продуктов с документацией всё в порядке (см. соответствующую запись в таблице и расшифровку). Зачем я буду ломать себе голову, когда рядом есть более функциональные утилиты с намного более простой и понятной документацией?
-
отсутствие пакетов!
ссылка на оригинал статьи https://habr.com/ru/articles/820349/
Добавить комментарий