Резервное копирование на уровне файловой системы

примечание

Эта страница переведена при помощи нейросети GigaChat.

Альтернативная стратегия резервного копирования заключается в непосредственном копировании файлов, которые PostgreSQL использует для хранения данных в базе данных (раздел «Создание кластера баз данных» объясняет, где находятся эти файлы) Для выполнения резервного копирования файловой системы можно использовать любой метод, который нравится, например:

tar -cf backup.tar /usr/local/pgsql/data

Однако есть два ограничения, которые делают этот метод непрактичным или, по крайней мере, уступающим методу pg_dump:

1. Для получения работоспособной резервной копии необходимо завершить работу сервера баз данных. Полумеры, такие как запрет всех подключений, не будут работать (в частности потому, что tar и аналогичные инструменты не создают атомарный снимок состояния файловой системы, но также из-за внутренней буферизации внутри сервера). Информация о завершении работы сервера можно найти в разделе «Завершение работы сервера». Так же нужно будет остановить сервер перед восстановлением данных.
2. При углублении в детали структуры файловой системы базы данных может возникнуть соблазн создать резервную копию или восстановить только отдельные таблицы или базы данных из соответствующих файлов или каталогов. Однако такой подход не сработает, поскольку данные в этих файлах непригодны для использования без файлов журнала фиксации pg_xact/*, содержащих статус транзакций. Файл таблицы становится пригодным только при наличии этой информации. Восстановление отдельной таблицы и связанных с ней данных pg_xact невозможно, так как это сделает остальные таблицы в кластере баз данных бесполезными. Таким образом, резервное копирование на уровне файловой системы поддерживает только полное резервное копирование и восстановление всего кластера баз данных.

Альтернативный подход к резервному копированию файловой системы заключается в создании «согласованного снимка» каталога данных, если файловая система поддерживает эту функциональность (и есть готовность доверять тому, что она реализована правильно). Типичная процедура состоит в том, чтобы сделать «замороженный снимок» тома, содержащего базу данных, затем скопировать весь каталог данных (не только части, см. выше) из снимка на устройство резервного копирования, а затем освободить замороженный снимок. Это будет работать даже при работающем сервере баз данных. Однако резервная копия, созданная таким образом, сохраняет файлы базы данных в состоянии, как будто сервер базы данных не был корректно выключен. Поэтому, когда будет запущен сервер базы данных с резервной копией данных, он подумает, что предыдущий экземпляр сервера аварийно завершил работу и воспроизведет журнал WAL. В этом нет ничего страшного, просто имейте это в виду (и убедитесь, что включили файлы WAL в свою резервную копию). Можно выполнить CHECKPOINT перед созданием снимка для сокращения времени восстановления.

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

Если одновременные снимки невозможны, одним из вариантов является остановка сервера баз данных на достаточно длительное время для создания всех замороженных снимков. Другой вариант – выполнить непрерывное архивирование базовой резервной копии (см. раздел «Создание базовой резервной копии»), поскольку такие резервные копии защищены от изменений файловой системы во время резервного копирования. Это требует включения непрерывного архивирования только во время процесса резервного копирования; восстановление выполняется с использованием восстановления непрерывного архива (см. раздел «Восстановление с помощью непрерывной резервной копии архива»).

Другой вариант – использовать rsync для выполнения резервного копирования файловой системы. Для этого сначала запускается rsync при работающем сервере баз данных, затем сервер баз данных останавливается на достаточно долгое время для выполнения rsync --checksum (ключ --checksum необходим, потому что rsync имеет гранулярность изменения времени файла всего одну секунду). Второе выполнение rsync будет быстрее первого, так как ему нужно передать относительно немного данных, и конечный результат будет согласованным, потому что сервер был остановлен. Этот метод позволяет выполнять резервное копирование файловой системы с минимальным временем простоя.

Обратите внимание, что резервная копия файловой системы обычно будет больше, чем дамп SQL (например, pg_dump не нуждается в выгрузке содержимого индексов, а лишь команд для их воссоздания). Однако создание резервной копии файловой системы может быть выполнено быстрее.