Postgres Pro Enterprise 13
Резервное копирование — 1
13
Авторские права
© Postgres Professional, 2023 год.
Авторы: Алексей Береснев, Илья Баштанов, Павел Толмачев
Использование материалов курса
Некоммерческое использование материалов курса (презентации,
демонстрации) разрешается без ограничений. Коммерческое
использование возможно только с письменного разрешения компании
Postgres Professional. Запрещается внесение изменений в материалы
курса.
Обратная связь
Отзывы, замечания и предложения направляйте по адресу:
Отказ от ответственности
Компания Postgres Professional не несет никакой ответственности за
любые повреждения и убытки, включая потерю дохода, нанесенные
прямым или непрямым, специальным или случайным использованием
материалов курса. Компания Postgres Professional не предоставляет
каких-либо гарантий на материалы курса. Материалы курса
предоставляются на основе принципа «как есть» и компания Postgres
Professional не обязана предоставлять сопровождение, поддержку,
обновления, расширения и изменения.
2
Темы
Резервное копирование
Локальная работа pg_probackup
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
Централизованный каталог копий и политики хранения
Резервирование на локальный или удаленный сервер
Постраничное инкрементальное копирование
Архивирование WAL
Восстановление выбранных баз данных
Параллельное резервирование и восстановление
Сжатие данных и поддержка CFS
Резервирование файлов вне каталога данных
Поддержка облачных хранилищ S3
Утилита pg_probackup — система резервного копирования и
восстановления корпоративного уровня, разработанная компанией
Postgres Professional.
Утилита работает с централизованным каталогом копий и
поддерживает инкрементальное копирование и восстановление.
При локальной работе каталог резервных копий размещается на том же
сервере, что и копируемые экземпляры. Для удаленного доступа к
каталогу резервных копий используется SSH.
Наличие хранилища копий позволяет выполнять сложные операции,
такие как слияние копий, и реализовывать политики их хранения. Имея
каталог копий, можно проверить целостность данных и возможность
восстановления на заданный момент времени (PITR, Point In Time
Recovery), не выполняя само восстановление.
Утилита поддерживает параллельное резервирование и
восстановление, может выполнять роль архиватора журнала
предзаписи.
Другие важные возможности pg_probackup: восстановление из копии
только заданных баз данных, поддержка сжатия данных и файловой
системы CFS (Compressed File System), резервирование с физической
реплики и резервирование файлов, находящихся вне PGDATA
(например, файлов конфигурации), поддержка хранилищ S3.
9
Локальная работа
Локальная работа
Полная копия
Разностное копирование
Копирование изменений
10
Локальная работа
Базы данных и каталог резервных копий на одном сервере
Простая подготовка
инициализация каталога резервных копий
добавление экземпляра СУБД для копирования
назначение прав роли для копирования
экземпляры PostgreSQL
каталог копий
При локальной работе каталог резервных копий размещается на том же
сервере, что и копируемые экземпляры. В каталоге копий хранятся
резервные копии и данные о них (метаинформация).
Утилита pg_probackup выполняет только горячее резервирование.
В самой простой стратегии резервного копирования в локальном
каталоге резервных копий формируется базовая копия без журнала
предзаписи. Если включено архивирование WAL, сегменты журнала
также копируются в каталог.
Пользователь, запускающий pg_probackup, должен иметь полный
доступ к каталогу копий. Каталог может содержать резервные копии
разных кластеров баз данных; перед первым копированием кластера
в каталог нужно выполнить команду pg_probackup add-instance для
инициализации подкаталогов и метаданных.
Пользователь должен также иметь доступ на чтение к каталогам
данных этих кластеров. Подробнее:
12
Полная копия
Полная резервная копия содержит все данные экземпляра
Потоковый способ доставки → автономная копия
pg_probackup backup -b FULL --stream
WAL
Команда pg_probackup backup -b FULL формирует резервную копию,
состоящую из базовой копии кластера и сегментов журнала
предзаписи.
Сегменты журнала по умолчанию доставляются файловым способом —
подразумевается ключ --archive, при этом требуется настройка
архивации (о ней поговорим в следующей теме).
Потоковая доставка журнала задается ключом --stream. В этом случае
резервная копия является самодостаточной, поэтому ее называют
автономной — копия включает в себя все сегменты журнала
предзаписи, необходимые для восстановления согласованности из
базовой копии на момент начала копирования.
13
Сжатие
Сжимаются файлы данных и файлы сегментов WAL
--compress-algorithm=zlib
--compress-level=1
pg_probackup backup --compress
Работа pg_probackup может быть существенно оптимизирована
посредством сжатия файлов данных и сегментов WAL. Во-первых,
экономится место хранения резервных копий, а во-вторых, потоки
данных меньше загружают подсистему ввода-вывода. Взамен
требуются ресурсы процессора для выполнения операций сжатия.
Сжатие включается ключом --compress, в котором можно указать
алгоритм и уровень сжатия. Для команды backup поддерживаются
алгоритмы zlib, lz4, zstd и pglz, если соответствующие библиотеки
установлены в системе.
15
FULL
DELTA
Разностное копирование
Разностное копирование — вариант инкрементального
Читаются все файлы данных, но в копию попадают только
измененные с последнего копирования страницы
Полная и инкрементальные копии образуют цепочку
pg_probackup backup -b DELTA
DELTA
измененная
страница
При восстановлении кластера из инкрементальной копии pg_probackup
восстанавливает родительскую полную копию, а затем применяет к ней
последовательно инкрементальные копии, останавливаясь после
целевой.
Утилита pg_probackup поддерживает три режима инкрементального
резервного копирования: DELTA, PAGE и PTRACK.
Инкрементальное копирование DELTA — разностное резервное
копирование. При этом страницы файлов в каталоге данных
сравниваются со страницами из последней резервной копии. В новую
резервную копию попадают только измененные с момента последнего
копирования страницы.
Достоинством режима DELTA является простота: не требуется архив
WAL и не надо устанавливать дополнительные расширения.
Однако есть и недостаток: в этом случае объем ввода-вывода может
быть близок к объему при полном резервном копировании.
16
Восстановление
Команда restore восстанавливает кластер из копии
По умолчанию выбирается последняя копия
Если указана инкрементальная копия, применяется цепочка
копий, начиная с полной
FULL
DELTA
pg_probackup restore
DELTA
Восстановление запускается командой restore утилиты pg_probackup.
Если для восстановления указана инкрементальная копия,
pg_probackup автоматически восстанавливает родительскую полную
копию и затем последовательно применяет нужные инкрементальные
копии.
Если идентификатор копии не указан, выполняется восстановление из
самой последней имеющейся копии (включая копии из цепочки, если
последней является инкрементальная копия).
18
Копирование изменений
Механизм PTRACK отслеживает изменения страниц
В резервную копию помещаются лишь измененные
страницы, обнаруженные PTRACK
Требуется подключение расширения ptrack
FULL
PTRACK
pg_probackup backup -b PTRACK
PTRACK
PTRACK
PTRACK — еще один режим инкрементального резервного копирования
базы Postgres Pro на уровне страниц, для которого используется
механизм PTRACK, предоставляемый ядром Postgres Pro Enterprise
и одноименным расширением. Механизм PTRACK отслеживает
изменения страниц в специальной карте. Утилита pg_probackup
использует API этого механизма для получения информации
о страницах, измененных с определенного момента.
Отличие от режима DELTA состоит в том, что для получения списка
страниц, подлежащих копированию, не требуется читать файлы данных
и последнюю резервную копию.
Этот режим инкрементального резервного копирования может
оказаться самым быстрым, особенно в сценариях, когда интенсивно
изменяются одни и те же страницы.
20
Итоги
Штатные средства резервного копирования
и восстановления не всегда достаточны
Утилита pg_probackup предоставляет все необходимые
возможности
Поддерживается полное и инкрементальное резервное
копирование, сжатие, параллельное резервирование
и восстановление
21
Практика
1. Подготовьте каталог резервных копий и зарегистрируйте
в нем копируемый экземпляр.
2. Зарегистрируйте роль backup и создайте базу данных backup.
3. Выполните полное резервное копирование.
4. Внесите какие-нибудь изменения в данные кластера
и получите разностную копию.
5. Восстановите экземпляр.
1. Создайте каталог /var/probackup, инициализируйте его с помощью
pg_probackup init, а затем добавьте в каталог экземпляр командой
pg_probackup add-instance так же, как в демонстрации.
2. Зарегистрировав роль backup, создайте одноименную базу данных
и по аналогии с демонстрацией назначьте командой GRANT
требуемые права.
3. Команда pg_probackup backup, помимо указания каталога копий для
полного резервного копирования, должна в этом случае также
включать параметр --stream.
4. При получении разностной копии не забудьте параметры -b DELTA
и --stream.
5. Перед восстановлением остановите работающий экземпляр СУБД,
удалите все содержимое его каталога данных, а затем проведите
восстановление командой pg_probackup restore.
