Как организовать резервное копирование PostgreSQL: подходы, инструменты и требования к инфраструктуре

5 часов назад

© Сгенерировано ИИ

В крупных организациях резервное копирование PostgreSQL приходится организовывать для тысяч и десятков тысяч баз данных, при этом объем баз может начинаться с 1–10 ТБ. При таких масштабах необходимо контролировать создание копий, их состояние и место хранения, проверять целостность данных, учитывать время восстановления и разграничивать доступ.

На IT Elements 2026 эксперт команды Pangolin Павел Селезнев разобрал подходы к резервному копированию PostgreSQL — от физических копий и снимков файловой системы до работы с репликами и централизованного каталога резервных копий. На основе его выступления RUБЕЖ подготовил обзор решений и подходов к организации резервного копирования PostgreSQL.

Инструменты для резервного копирования PostgreSQL

Для резервного копирования PostgreSQL используются системы резервного копирования и специализированные инструменты для работы с СУБД.

К первой группе относятся «Береста», «Кибер Бэкап», RuBackup и NetBackup. Среди инструментов для PostgreSQL — basebackup, pgBackRest, pg_probackup, WAL-G и Barman. Отдельный вариант — каталог резервных копий, реализованный, например, в CopyWala/Pangolin. Barman предусматривает использование центрального сервера, WAL-G имеет открытый исходный код. Проект pg_probackup существует с 2017 года.

До настройки резервного копирования необходимо проверить параметры самой СУБД. fsync должен иметь значение on, synchronous_commit — как минимум on, wal_sender — replica или logical. Дополнительно можно использовать кластер вместо отдельной СУБД, выделить отдельный сетевой канал для резервного копирования и отдельные защищенные соединения с базой данных.

Физическая копия через общую директорию

Один из вариантов — создание физических копий в общей директории. Несколько баз данных передают копии в общую NFS-папку, откуда они поступают в систему резервного копирования.

Такая схема требует промежуточного хранилища и сопровождения скриптов. Кроме того, необходимо отдельно отслеживать, какие копии создаются, каков их статус и какие операции запланированы. Данные при этом копируются дважды: сначала в общую директорию, затем в систему резервного копирования.

Еще один вопрос — прозрачность процесса для владельца базы. Ему необходимо иметь информацию о количестве созданных копий, времени их создания и текущем состоянии.

Снимок файловой системы или виртуальной машины

Другой способ — создание снимка файловой системы или виртуальной машины. Консистентность можно обеспечить с помощью pg_backup_start и pg_backup_stop. Если ограничить файловую систему каталогом <PGDATA>, можно уменьшить размер снимка.

Сам снимок создается быстро, поскольку для этого не требуется копировать весь объем данных. Однако на несколько секунд файловая система становится недоступной. Также потребуется механизм передачи снимка в систему хранения, а восстановление предполагает ручные действия. Необходимо контролировать глубину снимков и резервировать для них дисковое пространство.

Резервная копия с реплики

Создание резервной копии с реплики позволяет снизить нагрузку на master-сервер. Если на копировании с реплики строится надежная система резервного копирования, реплика должна быть синхронной. При несинхронной репликации существует риск потери данных.

При failover потребуются ручные действия — реплику необходимо перевести в роль master.

Общие сложности этих способов — сопровождение скриптов, промежуточное хранение, контроль состояния копий и организация безопасного доступа к данным.

Каталог резервных копий

Централизовать управление позволяет каталог резервных копий. В такой архитектуре управляющий сервер содержит задачи и их статусы, секреты, ролевую модель, мониторинг и собственную базу данных. На сервере СУБД работает агент.

Резервные копии могут передаваться непосредственно в S3, на ленту, в файловую систему, на сетевой диск или в хранилище системы резервного копирования.

Через каталог пользователь видит список своих резервных копий, актуальное расписание и выполняемые задачи. Для восстановления можно использовать последнюю успешную резервную копию, которую определяет сама система.

Централизованный каталог позволяет сократить количество организационных действий при восстановлении. Если эксплуатация и система резервного копирования находятся в зоне ответственности разных подразделений, сначала может потребоваться получить список существующих копий, затем запросить нужную и согласовать ее получение. Эти действия увеличивают RTO — допустимое время восстановления.

Проверка резервных копий

Наличие резервной копии само по себе не гарантирует возможность восстановления данных. При создании базы должны быть включены контрольные суммы страниц, а при передаче блоков на удаленное хранилище необходимо проверять корректность записи.

Отдельная часть процесса — проверка восстановления. Регламент должен содержать алгоритм действий при разных типах отказов и предусматривать учения, вплоть до сценариев отключения центров обработки данных.

При организации резервного копирования учитывается и RPO — Recovery Point Objective, то есть объем данных, который организация готова потерять.

Защита данных при резервном копировании

В резервные копии могут попадать персональные данные, чертежи, показания датчиков и другая чувствительная информация. Поэтому доступ к базе и доступ к ее резервным копиям необходимо разграничивать.

При работе с чувствительными данными к агенту предъявляется требование ФСТЭК-сертификации. Секреты могут храниться во внешних системах Vault, «ОдинКлюч» и Secman, чтобы не размещать пароли в открытом виде. Агент должен быть последней точкой, в которой чувствительные данные находятся в открытом виде: при дальнейшей передаче используется шифрование. Права доступа к СУБД и резервным копиям разделяются.

Сотрудникам подразделения, обслуживающего систему резервного копирования, не требуется доступ к содержимому баз данных. Для ограничения поверхности атаки на чувствительные данные используется защитное преобразование. Для агента можно установить ограничения по памяти, чтобы уменьшить его влияние на работающую систему.

Работа с WAL-файлами

Вместе с файлами базы необходимо сохранять WAL-файлы. Сделать это можно несколькими способами.

В первом варианте WAL-файлы группируются при отправке: каталог за один запуск выгружает все накопившиеся файлы. Во втором используется слот репликации. Такой способ позволяет вести аудит операций с базой, не требует доступа к <PGDATA> и позволяет запускать процесс от другого пользователя. Ограничение — однопоточность слота репликации. Состояние самих слотов необходимо контролировать средствами мониторинга.

В CopyWala для хранения WAL используется формат CWL. Он содержит метаданные о доступных точках во времени — LSN — и предусматривает сжатие.

В качестве примера приводится информационная система, которая генерирует 1 ТБ WAL-файлов в час. При таком объеме команда ls <путь> для хранилища выполняется долго, а системе резервного копирования удобнее работать с одним файлом.

Инкрементальные копии

Количество инкрементальных копий ограничено доступным дисковым пространством, поэтому накопленные дельты необходимо периодически объединять.

Для определения измененных страниц могут использоваться разные механизмы. ptrack формирует карту измененных страниц, но создает дополнительные накладные расходы и требует доработки для поддержки больших баз. Для PostgreSQL 16 и более ранних версий предусмотрено чтение файлов во время резервного копирования с определением LSN и выбором необходимых страниц. Для PostgreSQL 17 и выше указан функционал WalSummary.

Работа с дельтой требуется и при восстановлении отставшей реплики. В этом случае необходимо получить разницу между LSN сервера и LSN последней резервной копии и передать недостающие данные на реплику.

Многопоточное копирование больших баз

Стандартный basebackup работает в один поток. При этом серверное оборудование, сеть и системы хранения могут обрабатывать данные параллельно.

В CopyWala реализовано многопоточное копирование. Размер блока составляет 32 МБ. Алгоритм включает чтение блока, проверку контрольной суммы, передачу по сети и повторную сверку контрольной суммы.

Для сервера с 80 CPU и 770 ГБ оперативной памяти и базы объемом 9,7 ТБ приведено сравнение: basebackup в один поток — 2 часа 28 минут, CopyWala/Pangolin в восемь потоков — 46 минут. Эти значения получены командой разработчиков. Отдельно приведен результат клиента, полученный на оборудовании Сбербанка специалистами Сбербанка, — 20 ТБ в час.

После снятия однопоточного ограничения PostgreSQL скорость копирования начинает зависеть от производительности дисков, сети и других компонентов инфраструктуры.

Приведенные показатели получены в конкретных конфигурациях и не означают такую же производительность в другой инфраструктуре.

Восстановление отдельной таблицы без восстановления всей базы

Если база продолжает работать, но повреждена отдельная таблица или данные были испорчены неудачным SQL-запросом, полное восстановление большой базы потребует остановки информационной системы на время восстановления. Для получения отдельных данных можно использовать FUSE — Filesystem in Userspace.

Резервная копия монтируется как файловая система, после чего на временном сервере запускается экземпляр PostgreSQL без предварительной полной распаковки архива и копирования всех файлов.

Например, если требуется восстановить таблицу A, PostgreSQL обращается только к необходимым для нее блокам резервной копии. Таблицу можно выгрузить с помощью pg_dump, после чего вернуть данные в основную систему.

Если требуется восстановить всю базу, такой способ не дает преимущества — проще восстановить резервную копию полностью.

Регламент резервного копирования

Регламент резервного копирования должен включать:

- описание инфраструктуры — серверов и объемов данных;

- описание ролевой модели — пользователей и их прав;

- описание данных, в том числе чувствительных;

- пошаговые сценарии;

- создание резервной копии;

- восстановление;

- disaster recovery plan;

- периодические автоматизированные проверки;

- учения.

Проверки должны охватывать не только создание резервной копии, но и возможность восстановления данных. Для крупных инфраструктур регламент может предусматривать и учения по отключению центров обработки данных.

Читайте также: Алексей Морозков: «Как оценить реальную защищенность бизнеса и правильно расставить приоритеты в ИБ»