Архитектурный подход к физическому резервному копированию
В экосистеме PostgreSQL существует два основных типа резервного копирования: логическое (с помощью утилиты pg_dump) и физическое. Утилита pg_basebackup является стандартным инструментом для создания физических копий. В отличие от логического бэкапа, который выгружает структуру и данные в виде SQL-команд или кастомных архивов, физическое копирование создает точный побитовый слепок файловой системы базы данных.
Этот метод обладает рядом преимуществ для высоконагруженных систем:
- Скорость восстановления: развертывание физической копии происходит значительно быстрее, так как серверу не нужно заново выполнять SQL-запросы для вставки данных и построения индексов.
- Консистентность: pg_basebackup гарантирует целостность данных на определенный момент времени без блокировки таблиц.
- Основа для репликации: именно этот инструмент используется для инициализации ведомых узлов (Standby) в кластерах с потоковой репликацией.
Конфигурация сервера для поддержки резервного копирования
Перед использованием pg_basebackup необходимо подготовить основной сервер (Primary). Основные настройки выполняются в файле postgresql.conf. Для работы утилиты требуется включение потоковой передачи журналов транзакций (WAL).
Код: Выделить всё
wal_level = replica
max_wal_senders = 10
max_replication_slots = 10
Далее необходимо настроить права доступа в файле pg_hba.conf. Утилита подключается к серверу по протоколу репликации, поэтому требуется соответствующая запись:
Код: Выделить всё
# TYPE DATABASE USER ADDRESS METHOD
host replication replicator 192.168.1.100/32 scram-sha-256
Код: Выделить всё
CREATE USER replicator WITH REPLICATION ENCRYPTED PASSWORD 'your_secure_password';
Утилита pg_basebackup инициирует процесс резервного копирования, подключаясь к СУБД как клиент. Процесс включает перевод БД в режим бэкапа, копирование файлов данных и получение необходимых WAL-файлов.
Типовой синтаксис команды для создания архива выглядит следующим образом:
Код: Выделить всё
pg_basebackup -h 192.168.1.10 -D /var/lib/postgresql/backups/base_1 -U replicator -P -v -Ft -z -X stream
- -D: путь к целевой директории, где будет сохранена копия.
- -Ft: формат вывода tar. Если используется -Fp (plain), создается структура директорий, идентичная оригиналу.
- -z: включение gzip-сжатия (актуально для формата tar).
- -X stream: один из важнейших параметров. Он заставляет утилиту открывать второе соединение для параллельного получения WAL-файлов во время копирования данных. Это гарантирует, что бэкап будет самодостаточным и консистентным.
- -P и -v: включают индикатор прогресса и подробный вывод логов.
- -R: автоматически создает файл standby.signal и настраивает параметры подключения в postgresql.auto.conf, что полезно для быстрой настройки реплики.
При создании больших бэкапов существует риск, что сегменты WAL на основном сервере будут перезаписаны до того, как pg_basebackup успеет их скачать. Чтобы этого избежать, следует использовать слоты репликации.
Команда с использованием временного слота:Слот репликации на стороне Primary гарантирует, что сервер не удалит старые WAL-файлы до тех пор, пока они не будут успешно переданы клиенту.
Код: Выделить всё
pg_basebackup -D /backup/dir -X stream --create-slot --slot=backup_slot --temporary
Интеграция с архивированием WAL (PITR)
Для обеспечения максимальной надежности в production-средах одного pg_basebackup недостаточно. Необходимо организовать непрерывное архивирование журналов транзакций. Это позволяет реализовать стратегию Point-In-Time Recovery (восстановление на любой момент времени в прошлом).
В postgresql.conf настраивается параметр archive_command, который копирует заполненные сегменты WAL в защищенное хранилище (например, S3 или выделенный NFS-сервер):
Код: Выделить всё
archive_mode = on
archive_command = 'test ! -f /mnt/nfs/archive/%f && cp %p /mnt/nfs/archive/%f'
Процедура восстановления из физической копии
Восстановление данных из копии, созданной pg_basebackup, требует выполнения строгого алгоритма действий.
- Полная остановка целевого экземпляра PostgreSQL.
- Очистка или перемещение содержимого текущей директории данных (PGDATA). Восстановление поверх существующих файлов невозможно.
- Распаковка архива или копирование файлов из бэкапа в директорию данных. Если использовался формат tar, основной архив распаковывается в корень, а таблицы (tablespaces), если они были, — в свои соответствующие пути.
- Установка корректных прав доступа на файлы (обычно владелец postgres и права 0700).
- Создание файла-маркера recovery.signal в корне PGDATA для запуска процесса восстановления (в PostgreSQL 12 и выше).
- Настройка параметров восстановления в postgresql.conf или postgresql.auto.conf (например, restore_command для получения WAL из архива).
Код: Выделить всё
restore_command = 'cp /mnt/nfs/archive/%f %p'
Рекомендации по эксплуатации
Для обеспечения отказоустойчивости технический архитектор должен учитывать следующие аспекты:
- Проверка бэкапов: периодически выполняйте тестовое восстановление на изолированном сервере. Бэкап считается существующим только тогда, когда из него успешно восстановились данные.
- Мониторинг: отслеживайте коды возврата pg_basebackup и объем свободного места в хранилище.
- Безопасность: используйте SSL-шифрование для передачи данных по сети, особенно если бэкап выполняется через публичные каналы связи.