Резервное копирование
Использование pg_probackup
16
Авторские права
© Postgres Professional, 2023–2026
Авторы: Алексей Береснев, Илья Баштанов, Павел Толмачев, Игорь
Гнатюк
Фото: Олег Бартунов (монастырь Пху и пик Бхрикути, Непал)
Использование материалов курса
Некоммерческое использование материалов курса (презентации,
демонстрации) разрешается без ограничений. Коммерческое
использование возможно только с письменного разрешения компании
Postgres Professional. Запрещается внесение изменений в материалы
курса.
Обратная связь
Отзывы, замечания и предложения направляйте по адресу:
edu@postgrespro.ru
Отказ от ответственности
Компания Postgres Professional не несет никакой ответственности за
любые повреждения и убытки, включая потерю дохода, нанесенные
прямым или непрямым, специальным или случайным использованием
материалов курса. Компания Postgres Professional не предоставляет
каких-либо гарантий на материалы курса. Материалы курса
предоставляются на основе принципа «как есть» и компания Postgres
Professional не обязана предоставлять сопровождение, поддержку,
обновления, расширения и изменения.
2
Темы
Инкрементальные копии
Способы восстановления
Синхронизация
3
Инкрементальные копии
Разностное копирование (DELTA)
Копирование изменений (PTRACK)
Страничное копирование (PAGE)
Объединение копий
4
FULL
DELTA
Копирование DELTA
Полная и инкрементальные копии образуют цепочку
Разностное копирование — вариант инкрементального
Читаются все файлы данных, но в копию попадают только
измененные с последнего копирования страницы
pg_probackup backup -b DELTA
DELTA
измененная
страница
Инкрементальная копия включает в себя все изменения, произошедшие
после создания какой-либо другой копии.
Полная копия и набор последующих инкрементальных копий образуют
цепочку. При восстановлении кластера из инкрементальной копии
pg_probackup восстанавливает родительскую полную копию, а затем
применяет к ней последовательно инкрементальные копии,
останавливаясь после целевой.
Утилита pg_probackup поддерживает три режима инкрементального
резервного копирования: DELTA, PAGE и PTRACK.
Режим DELTA — разностное копирование. Страницы файлов в каталоге
данных сравниваются со страницами из последней резервной копии.
В новую резервную копию попадают только измененные с момента
последнего копирования страницы.
Достоинство режима DELTA — его простота: не требуется архив WAL
и не надо устанавливать дополнительные расширения. Однако есть и
недостаток: объем ввода-вывода может оказаться почти таким же, как
при полном резервном копировании.
5
Восстановление
Команда restore восстанавливает кластер из копии
По умолчанию выбирается последняя копия
Если указана инкрементальная копия, применяется цепочка
копий, начиная с полной
FULL
DELTA
pg_probackup restore
DELTA
Если команде restore утилиты указать инкрементальную копию,
pg_probackup восстановит родительскую полную копию и затем
последовательно применит нужные инкрементальные копии.
Если идентификатор копии не указан, выполняется восстановление из
самой последней имеющейся копии (включая копии из цепочки, если
последняя копия — инкрементальная).
7
Объединение копий
Команда merge объединяет родительскую полную копию
и дочерние инкрементальные копии в одну общую
Не нагружает сеть передачей данных
FULL
DELTA
pg_probackup merge
DELTA
FULL
Инкрементальная резервная копия строится быстрее полной и
занимает меньше места. Однако по мере роста цепочки занимаемый
объем и время восстановление будут увеличиваться.
Утилита pg_probackup позволяет объединить цепочку копий в одну
полную копию командой merge.
Передав команде merge идентификатор последней инкрементальной
копии в цепочке, мы получим единую полную копию, содержащую
данные родительской полной копии со всеми изменениями,
накопленными в цепочке инкрементальных. Все копии цепочки
удаляются и остается единственная объединенная полная копия.
Указав команде идентификатор родительской копии, мы получим
объединенную копию, включающую родительскую полную и первую
инкрементальную.
При объединении вся работа производится в каталоге резервных копий,
команда merge не передает данные по сети.
9
Копирование PTRACK
Механизм PTRACK отслеживает изменения страниц
В резервную копию помещаются лишь измененные
страницы, обнаруженные PTRACK
Требуется расширение ptrack
FULL
PTRACK
pg_probackup backup -b PTRACK
PTRACK
PTRACK
PTRACK — еще один режим инкрементального резервного копирования
экземпляра Postgres Pro. В копию попадают только изменившиеся
страницы, но, в отличие от DELTA, утилите не требуется сравнивать
данные с резервной копией: она получает список страниц с помощью
механизма PTRACK.
Механизм PTRACK встроен в ядро Postgres Pro Enterprise. Он
отслеживает и отмечает модификации страниц в специальной карте
и предоставляет API для получения списка файлов, измененных
с произвольного момента LSN, и битовых карт измененных в этих
файлах страниц.
Утилита pg_probackup получает список страниц, подлежащих
копированию, запрашивая изменения, произошедшие после создания
предыдущей резервной копии. Поскольку для этого не требуется читать
файлы данных и последнюю резервную копию, этот режим
инкрементального резервного копирования может оказаться самым
быстрым, особенно в сценариях, когда интенсивно изменяются одни
и те же страницы.
11
целевой сервер
сервер
резервного копирования
WAL
Копирование PAGE
В архиве должны быть все сегменты WAL, записанные
после предыдущей копии
FULL
PAGE
pg_probackup backup -b PAGE
PAGE
агент
информация
об измененных
страницах
При наличии архива WAL для создания инкрементальных копий можно
использовать еще один режим инкрементального резервного
копирования pg_probackup — страничное копирование (PAGE).
При копировании PAGE pg_probackup сканирует все записи WAL
в архиве, начиная с момента создания предыдущей полной или
инкрементальной копии, и определяет по ним список изменившихся
страниц. При этом необходимо, чтобы в архиве присутствовали все
файлы WAL, сгенерированные после предыдущей копии.
Режим PAGE особенно эффективен, когда в базах данных происходит
немного изменений. Если же объем журнальных файлов сравним
с общим объемом файлов базы данных, ускорение будет
незначительным, однако объем инкрементальной копии все равно
будет меньше, чем полной.
12
целевой сервер
сервер
резервного копирования
WAL
Восстановление
FULL
PAGE
pg_probackup restore
PAGE
агент
remote
archive
Удаленное восстановление с обменом данными по SSH
Архив WAL заполняется с целевого сервера командой pg_probackup
archive-push (указанной в конфигурационном параметре
archive_command) по SSH. И при восстановлении целевой сервер будет
читать необходимые сегменты журнала по SSH командой pg_probackup
archive-get (указанной в параметре restore_command).
Здесь мы имеем дело с удаленным восстановлением. Поэтому при
вызове pg_probackup restore требуется указать два набора параметров.
Remote-параметры указывают на целевой сервер с восстанавливаемым
экземпляром:
●
--remote-host — адрес целевого сервера;
●
--remote-user — владелец экземпляра (postgres);
●
--remote-port — порт SSH.
Archive-параметры указывают на сервер резервного копирования,
хранящий архив WAL:
●
--archive-host — адрес сервера резервного копирования;
●
--archive-user — владелец каталога резервных копий;
●
--archive-port — порт SSH.
Archive-параметры используются, чтобы сформировать на целевом
сервере значение параметра restore_command.
14
Способы восстановления
Восстановление PITR
Частичное восстановление
Восстановление страниц
Синхронизация
15
WAL
Восстановление PITR
При наличии архива WAL можно восстановить систему
на момент времени — point-in-time recovery
Требуется архив WAL от момента создания резервной копии
pg_probackup restore
целевая точка
восстановления
Если до выполнения резервного копирования уже был настроен архив
WAL, то с помощью pg_probackup можно выполнить восстановление на
момент времени в прошлом (Point-In-Time Recovery, PITR). Независимо
от того, является ли резервная копия автономной (включает
журнальные файлы) или нет, требуется наличие архива WAL как
минимум с момента создания резервной копии.
При восстановлении на момент времени не обязательно указывать
идентификатор копии. Утилита pg_probackup автоматически выберет
резервную копию, ближайшую к заданной целевой точке, и начнет
восстановление.
Указать точку восстановления можно параметрами:
●
--recovery-target-time — на заданное время в формате timestamp;
●
--recovery-target-xid — до заданной транзакции;
●
--recovery-target-lsn — до заданного LSN;
●
--recovery-target-name — до заранее созданной именованной точки;
●
--recovery-target='latest' — до последнего согласованного состояния;
●
--recovery-target='immediate' — до самого раннего согласованного
состояния.
17
Частичное восстановление
Восстановление только требуемых баз данных кластера
--db-include — база данных для восстановления
--db-exclude — база данных, которую не надо восстанавливать
pg_probackup restore
Частичное восстановление применяется в случаях, когда не требуется
восстанавливать все базы данных кластера.
Параметром --db-include можно задать имя базы данных для
восстановления. Базы template0 и template1 восстанавливаются всегда.
Можно указать несколько таких параметров, по одному для каждой
восстанавливаемой базы данных.
Используя параметр --db-exclude, можно попросить утилиту
восстановить все базы, кроме указанных.
Все файлы пропущенных баз данных все равно создаются утилитой, но
создаются пустыми. Это необходимо, поскольку при старте экземпляра
процесс startup проигрывает журнальные записи (как минимум для
восстановления согласованности) и ожидает обнаружить
соответствующие файлы данных. Затем ненужные базы данных можно
удалить.
19
Восстановление страниц
CHECKSUM
восстановление испорченных страниц и страниц,
отличающихся от резервной копии
pg_probackup restore -I режим
При инкрементальном восстановлении (восстановлении страниц)
каталог данных экземпляра не перезаписывается полностью,
а только обновляется теми страницами, состояние которых изменилось
по сравнению с резервной копией. Если каталог данных не сильно
отличается от копии, такое восстановление будет работать значительно
быстрее обычного.
Для инкрементального восстановления в командную строку
добавляется параметр -I, после которого указывается один из двух
режимов: CHECKSUM или LSN. Эти режимы определяют, как именно
будут выбираться страницы, требующие восстановления.
В режиме CHECKSUM восстанавливаются страницы с некорректной
контрольной суммой или с номером LSN, отличающимся от LSN
в резервной копии. Для этого утилита читает все файлы данных
экземпляра, получает их контрольные суммы и LSN, а затем
сравнивает эту информацию с содержимым резервной копии. Если
имеет место цепочка инкрементальных резервных копий, в более
ранних копиях ищутся только те страницы, которые не были найдены
в более поздних.
Экономия достигается за счет того, что только изменившиеся страницы
передаются по сети и записываются на диск целевого экземпляра.
20
Восстановление страниц
LSN
восстановление испорченных страниц и страниц,
измененных после точки сдвига
точка сдвига — наиболее поздняя копия из инкрементальной цепочки,
соответствующая прошлому состоянию каталога данных экземпляра
FULL
Δ
2
целевая
копия
точка
сдвига
линия времени 1
линия времени 2
страницы, измененные
в этом диапазоне LSN,
не отличаются от целевой копии
Δ
1
В режиме LSN утилита пытается найти в инкрементальной цепочке
целевой резервной копии наиболее позднюю копию, соответствующую
какому-либо состоянию каталога данных экземпляра в прошлом.
Момент завершения создания этой копии называется точкой сдвига
(Shift LSN) и принадлежит некоторой линии времени. Точка сдвига
важна тем, что страницы экземпляра с LSN ≤ Shift LSN заведомо
совпадают со страницами, которые можно восстановить из целевой
резервной копии, то есть при восстановлении такие страницы можно
просто игнорировать.
Если подходящей на роль точки сдвига копии нет, восстановление
в режиме LSN невозможно (режим CHECKSUM доступен всегда).
На слайде копия Δ
2
не может служить точкой сдвига, поскольку не
соответствует никакому прошлому состоянию экземпляра: она была
сделана в первой линии времени, а экземпляр в некоторый момент
переключился на вторую линию. А копия Δ
1
удовлетворяет условиям
и будет выбрана в качестве точки сдвига.
Режим LSN требует корректности файла pg_control, поскольку из него
считывается Redo LSN и линия времени экземпляра, и наличия
необходимых файлов истории в архиве WAL. Также должны быть
включены контрольный суммы.
Однако если режим доступен, он оказывается более эффективным, чем
CHECKSUM. Файлы каталога данных все равно читаются полностью, но
в режиме CHECKSUM по резервной копии проверяются все страницы, а
в LSN — только измененные позже точки сдвига.
22
Синхронизация
Копирование данных из одного экземпляра в другой
синхронизация отставшего ведомого сервера с ведущим
добавление нового ведомого сервера
pg_probackup catchup
Быстро клонировать экземпляр или синхронизировать отставшую
реплику позволяет команда catchup утилиты pg_probackup. Она не
использует каталог резервных копий, а берет данные непосредственно
из каталога данных копируемого экземпляра.
Ускорение относительно обычных средств может достигаться за счет:
●
многопоточной передачи данных;
●
инкрементального копирования (с дополнению к режиму FULL
доступны DELTA и PTRACK).
Использование команды catchup для синхронизации отставшей реплики
позволяет избежать сложных ручных процедур с использованием rsync
и подобных инструментов.
Команда catchup отличается от других операций, выполняемых
утилитой pg_probackup:
●
по умолчанию конфигурационные файлы целевого сервера
заменяются файлами исходного сервера;
●
возможна только потоковая доставка WAL (архив не используется);
●
не копируются внешние каталоги;
●
запрещено одновременное выполнение команд DDL, создающих
или удаляющих табличные пространства.
24
Итоги
Утилита pg_probackup поддерживает инкрементальное
копирование и инкрементальное восстановление
измененных страниц
При наличии архива WAL поддерживается восстановление
на момент в прошлом
Возможно восстановление части данных кластера
и эффективная синхронизация двух кластеров
25
Практика
1. Подготовьте экземпляр к работе с архивированием WAL,
создайте базу данных, выполните полное копирование
со сжатием.
2. Измените какие-либо данные в базе и выполните
инкрементальное страничное копирование со сжатием.
3. Убедитесь, что полученная цепочка копий пригодна для
восстановления экземпляра.
4. Имитируйте аварию сервера с физической порчей данных.
5. Восстановите испорченные данные, не затрагивая при этом
другие данные кластера.
4. Аварийно завершите основной процесс экземпляра. Измените файл
основного слоя таблицы средствами ОС, например:
dd if=/dev/urandom of=файл conv=fdatasync bs=8K count=10
5. Выполните инкрементальное восстановление в режиме CHECKSUM.
