Резервное копирование
Основы pg_probackup
16
Авторские права
© Postgres Professional, 2023–2026
Авторы: Алексей Береснев, Илья Баштанов, Павел Толмачев, Игорь
Гнатюк
Фото: Олег Бартунов (монастырь Пху и пик Бхрикути, Непал)
Использование материалов курса
Некоммерческое использование материалов курса (презентации,
демонстрации) разрешается без ограничений. Коммерческое
использование возможно только с письменного разрешения компании
Postgres Professional. Запрещается внесение изменений в материалы
курса.
Обратная связь
Отзывы, замечания и предложения направляйте по адресу:
edu@postgrespro.ru
Отказ от ответственности
Компания Postgres Professional не несет никакой ответственности за
любые повреждения и убытки, включая потерю дохода, нанесенные
прямым или непрямым, специальным или случайным использованием
материалов курса. Компания Postgres Professional не предоставляет
каких-либо гарантий на материалы курса. Материалы курса
предоставляются на основе принципа «как есть» и компания Postgres
Professional не обязана предоставлять сопровождение, поддержку,
обновления, расширения и изменения.
2
Темы
Резервное копирование
Полное копирование
3
Резервное копирование
Риски и требования
Характеристики
Общая классификация
Инструменты PostgreSQL
Возможности pg_probackup
4
Риски и требования
Резервное копирование снижает риски потери данных
отказ оборудования и сбои программного обеспечения
порча данных вследствие человеческих ошибок
негативное воздействие окружающей среды
криминальная активность
другие причины
Обычные требования к резервному копированию
небольшое время копирования
минимизация места для хранения копий
быстрое восстановление из резервной копии
Любая реальная система рано или поздно столкнется с отказом,
связанным с исчезновением или повреждением данных. Резервное
копирование позволяет снизить риск потери данных.
Основные причины, приводящие к возможной потере данных:
●
природные и антропогенные катастрофы;
●
отказы и сбои оборудования;
●
ошибки в программном обеспечении;
●
намеренная порча или кража оборудования;
●
взлом или компрометация компьютерных систем;
●
человеческие ошибки.
В зависимости от ценности защищаемой информации должна быть
построена более или менее сложная система, выполняющая резервное
копирование по некоторому расписанию. Чтобы обеспечить
максимальную защиту данных, мероприятия, связанные с резервным
копированием должны включать:
●
расписание резервного копирования;
●
процедуры проверки целостности и исправности копий;
●
систему хранения резервных копий в надлежащих условиях;
●
план восстановления системы с помощью резервных копий;
●
средства защиты системы резервного копирования и самих копий.
Желательно обеспечить минимальное время копирования и
восстановления и ограничить пространство для хранения копий.
5
Характеристики
инцидент
Идеальные характеристики
отношение времени работы системы к общему времени → 100 %
RTO — целевое время восстановления → 0
RPO — целевая точка восстановления → 0
последняя копия
RPO RTO
восстановление
Идеальная система никогда не простаивает, и отношение времени
продуктивной работы системы к общему времени ее эксплуатации
равно 100%.
Однако в реальных системах инциденты, требующие восстановления
данных из резервных копий, рано или поздно происходят.
Оценка максимального периода времени, за который данные могут
быть потеряны вследствие инцидента, связана с периодичностью
и способами выполнения резервного копирования. Такая оценка
выражается показателем Recovery Point Objective (RPO).
После обнаружения инцидента требуется время для восстановления
системы. Показатель Recovery Time Objective (RTO) указывает целевое
время, по истечении которого система восстанавливается для
обслуживания клиентов.
В сложных системах процесс восстановления системы проходит через
несколько промежуточных стадий, что, например, может быть вызвано
восстановлением из резервных копий нескольких различных
экземпляров БД.
6
Общая классификация
По вовлеченности администратора
неконтролируемое (unattended)
контролируемое (attended)
По плановости
незапланированное (non-scheduled)
календарное (scheduled)
По полноте резервирования данных
полное (full)
инкрементальное (incremental)
Принятая в системах резервного копирования классификация
подразделяет резервное копирование по следующим критериям:
●
по степени вовлеченности администратора в процесс резервного
копирования на требующее контроля и автоматическое
неконтролируемое копирование;
●
является ли резервное копирование незапланированным, или же оно
выполняется в соответствии с календарным расписанием;
●
копируются ли все данные (возможно, в сжатом виде) или лишь
часть, измененная с момента предыдущего резервного копирования.
Незапланированное резервное копирование осуществляется
с помощью команды администратора (attended non-scheduled backup).
Однако чаще всего заранее создается календарный план резервного
копирования, в котором фиксируется периодичность автоматического
выполнения полного (full) или инкрементального (incremental)
резервного копирования. Другое название инкрементальных копий —
разностные копии (в конкретных системах резервного копирования
понятия инкрементальных и разностных копий могут отличаться).
Инкрементальные копии содержат данные, измененные с момента
последнего резервного копирования, поэтому размер такой копии
меньше, чем у полной.
СУБД имеют свою специфику: резервные копии могут включать или не
включать журналы, содержать данные всего экземпляра или отдельных
баз данных и т. п.
7
Инструменты PostgreSQL
COPY, pg_dump, pg_dumpall
высокое RPO
pg_basebackup
нет каталога и хранилища резервных копий
нет политик хранения и удержания копий
нет инкрементального копирования
невозможна параллельная работа
Собственные инструменты PostgreSQL позволяют выполнять как
логическое копирование всего кластера или отдельных объектов,
так и физическое копирование кластера. Эти инструменты подробно
рассмотрены в курсе DBA3.
Однако имеющиеся в PostgreSQL инструменты неудобны для
промышленного использования.
Средства логического резервирования не удовлетворяют поставленным
требованиям из-за крайне высокого RPO.
Средства физического резервирования не предоставляют возможности
ведения каталога резервных копий, который содержал бы информацию
о копиях (метаданные). Например, в каталоге резервных копий можно
было бы хранить тип резервной копии (полная или инкрементальная),
время и способ ее создания. Такой каталог позволяет выполнять
проверку исправности резервных копий, а также упрощает и ускоряет
восстановление данных.
Другой недостаток штатных инструментов — отсутствие политик,
определяющих правила хранения копий и их последующего удаления.
Кроме того, производительность штатной утилиты pg_basebackup из-за
ее однопоточности явно недостаточна для резервирования больших
объемов данных.
8
Возможности pg_probackup
Централизованный каталог копий и политики хранения
Локальное или удаленное копирование, поддержка S3
Постраничное инкрементальное копирование
Восстановление выбранных баз данных
Параллельное резервирование и восстановление
Сжатие данных и поддержка CFS
Резервирование файлов вне каталога данных
Утилита pg_probackup — система резервного копирования и
восстановления корпоративного уровня, разработанная компанией
Postgres Professional.
Утилита работает с централизованным каталогом копий и
поддерживает инкрементальное копирование и восстановление.
При локальной работе каталог резервных копий размещается на том же
сервере, что и копируемые экземпляры. Для удаленного доступа
к каталогу резервных копий используется SSH.
Хранилище копий позволяет выполнять сложные операции, такие как
слияние копий, и реализовывать политики их хранения. Имея каталог
копий, можно проверять целостность данных и возможность
восстановления на заданный момент времени (PITR, Point In Time
Recovery), не выполняя само восстановление.
Утилита также поддерживает работу в параллельном режиме и может
выполнять роль архиватора журнала предзаписи.
Другие важные возможности pg_probackup: восстановление из копии
отдельных баз данных, поддержка сжатия данных и файловой системы
CFS (Compressed File System), резервирование с физической реплики и
резервирование файлов, находящихся вне PGDATA (например, файлов
конфигурации), поддержка хранилищ S3, возможность ограничивать
скорость записи данных на диск (для снижения нагрузки на систему
ввода-вывода).
9
Полное копирование
Локальная работа
Полная копия
Сжатие
Удаленная работа
Архивирование WAL
10
Локальная работа
Базы данных и каталог резервных копий на одном сервере
Простота
каталог резервных копий на локальной машине
архива WAL нет
используется потоковый режим
экземпляры PostgreSQL
каталог копий
При локальной работе каталог резервных копий размещается на том же
сервере, что и копируемые экземпляры. В каталоге копий хранятся
резервные копии и данные о них (метаинформация).
Утилита pg_probackup выполняет только горячее резервирование.
При самой простой стратегии резервного копирования в локальном
каталоге резервных копий формируется базовая копия без журнала
предзаписи. Если включено архивирование WAL, сегменты журнала
также копируются в каталог.
Пользователь, запускающий pg_probackup, должен иметь полный
доступ к каталогу копий. Каталог может содержать резервные копии
разных кластеров баз данных; перед первым копированием кластера
в каталог нужно выполнить команду pg_probackup add-instance для
инициализации подкаталогов и метаданных.
Пользователь должен также иметь доступ на чтение к каталогам
данных копируемых кластеров. Подробнее:
12
Полная копия
Полная резервная копия содержит все данные экземпляра
Потоковый способ доставки → автономная копия
pg_probackup backup -b FULL --stream
WAL
Команда pg_probackup backup -b FULL формирует резервную копию,
состоящую из базовой копии кластера и сегментов журнала
предзаписи.
Чтобы полная резервная копия была автономной, то есть
самодостаточной, она должна включать в себя все записи WAL,
необходимые для восстановления согласованности из базовой копии
на момент начала копирования.
Если указать параметр --stream, записи журнала передаются потоковым
способом. Если параметр не указать, утилита журнальные записи не
получает; предполагается, что для экземпляра СУБД настроена
файловая непрерывная архивация.
Оба варианта передачи WAL рассматриваются в курсе DBA3
«Резервное копирование и репликация».
13
Сжатие
Сжимаются файлы данных и файлы сегментов WAL
--compress-algorithm=zstd
--compress-level=1
pg_probackup backup --compress
Работа pg_probackup может быть существенно оптимизирована
посредством сжатия файлов данных и сегментов WAL. Во-первых,
экономится место хранения резервных копий, а во-вторых, потоки
данных меньше загружают подсистему ввода-вывода. Взамен
требуются ресурсы процессора для выполнения операций сжатия.
Сжатие настраивается с помощью параметров --compress-algorithm и --
compress-level, в которых можно указать алгоритм и уровень сжатия.
Поддерживаются алгоритмы zstd, lz4, zlib и pglz, если соответствующие
библиотеки установлены в системе, а значение возможных уровней
сжатия зависит от алгоритма.
Параметр --compress задает алгоритм сжатия по умолчанию и
устанавливает его уровень в единицу, то есть переопределяет
параметры --compress-algorithm и --compress-level и не может быть
использован одновременно с ними.
15
сервер резервного
копирования
целевой серверцелевой сервер
Удаленная работа
Утилита запускается на сервере резервного копирования
Подключение к целевым серверам по SSH
Удаленная работа на целевом сервере выполняется агентами
SSH
pg_probackup
SSH
агенты
pg_probackup
агенты
pg_probackup
remote
remote
В удаленном режиме утилиту pg_probackup запускают на сервере
резервного копирования (на котором расположен каталог копий); она
подключается к целевому серверу по протоколу SSH (Secure Shell),
запускает на нем процессы-агенты и с их помощью может выполнять
резервное копирование, восстановление и архивирование WAL.
Количество запускаемых агентов определяется параметром --threads.
При ошибке любого агента аварийно завершаются остальные агенты
экземпляра и породившая их команда pg_probackup.
На всех серверах должна быть установлена одна и та же версия
pg_probackup.
При подключении по SSH аутентификация выполняется без ввода
пароля, по ключу.
Параметры SSH-соединения:
●
--remote-host — целевой сервер для копирования и восстановления;
●
--remote-user — пользователь ОС, от имени которого работает агент
на целевом сервере (владелец экземпляра Postgres);
●
--remote-port — TCP-порт для подключения по SSH к целевому
серверу.
17
сервер
с копируемым
экземпляром
сервер
резервного копирования
= целевой сервер
WAL
Архивирование WAL
Архив WAL сохраняется в каталог резервных копий
SSH
archive_command
= 'pg_probackup
archive-push'
remote
Для инкрементального резервного копирования в режиме PAGE
необходим архив журнала предзаписи, который дает возможность
восстановления на момент в прошлом (PITR, Point-In-Time Recovery).
При создании резервной копии pg_probackup предполагает, что на
копируемом экземпляре настроен механизм пополнения архива —
обычно файловым способом. Команда архивирования должна
корректно работать в случае сбоев, гарантировать сохранение файлов
на диске и быть достаточно производительной. Чтобы не настраивать
такую команду самостоятельно, удобно задать в параметре
archive_command команду pg_probackup archive-push.
В данном случае утилиту pg_probackup вызывает СУБД, поэтому при
работе через SSH целевым сервером, который указывается
в параметрах --remote-*, будет сервер резервного копирования
с каталогом резервных копий.
Утилиту можно использовать для архивации и при локальной работе.
Тогда она будет запускаться от имени владельца файлов кластера
данных (обычно postgres), и каталог копий в таком случае также должен
принадлежать postgres. Это особенность текущей версии pg_probackup.
19
Итоги
Штатные средства резервного копирования
и восстановления не всегда достаточны, pg_probackup
предоставляет дополнительные возможности
Утилита pg_probackup поддерживает каталог резервных
копий, который может находиться на отдельном сервере
Для WAL возможно файловое архивирование и потоковая
передача
Поддерживается полное и инкрементальное резервное
копирование, сжатие, параллельное резервирование
и восстановление
20
Практика
1. Подготовьте каталог резервных копий и зарегистрируйте
в нем копируемый экземпляр для работы в удаленном
режиме.
2. Настройте экземпляр на работу в режиме архивирования
WAL, зарегистрируйте роль backup и создайте базу данных.
3. Выполните полное резервное копирование.
4. Измените какие-либо данные в базе и переключите сегмент
WAL. Убедитесь, что сегмент попал в архив.
5. Удалите каталог данных кластера и восстановите его из
резервной копии. Проверьте, восстановились ли последние
изменения.
2. Создайте базу данных из шаблона templateprobackup.
3. Убедиться, что сегмент попал в архив, можно разными способами:
средствами PostgreSQL, средствами ОС или с помощью pg_probackup.
21
Практика PPEM
1. Создайте локальное хранилище резервных копий для
экземпляра ent-16. Назовите его ent-16_local, а каталог
данных разместите в /var/lib/pgpro/pg_probackup.
2. Сделайте автономную резервную копию основного
экземпляра в созданное в п. 1 хранилище. Копия должна быть
максимально сжата алгоритмом lz4 и включать журнал
сообщений сервера.
3. Сделайте еще одну копию экземпляра, но уже без сжатия.
Сравните размер полученной копии с полученной в п. 2
и оцените выигрыш от сжатия.
4. Создайте новый экземпляр ent-16-restored из резервной копии
п. 3 в каталоге /var/lib/pgpro/ent-16-restored и запустите его.
2. Выбор алгоритма будет доступен после установки уровня сжатия
копии.
