| Документация по PostgreSQL 9.1.1 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 24. Резервное копирование и восстановление | Fast Forward | Next |
Альтернативной стратегией резервного копирования является прямое копирование файлов, которые PostgreSQL использует для хранения данных в базе данных; Section 17.2 объясняет, где находятся эти файлы. Вы можете использовать любой предпочитаемый вами способ выполнения резервной копии файловой системы, например:
tar -cf backup.tar /usr/local/pgsql/data
Однако, существует два ограничения, которые делают этот метод непрактичным или как минимум менее предпочтительным по сравнению с использованием pg_dump:
Чтобы получить пригодную к работе резервную копию, сервер баз данных должен быть остановлен. Такая полумера, как запрещение всех подключений к серверу работать не будет (в частности потому что tar и похожие инструменты не выполняют мгновенный снимок состояния файловой системы, а также потому что внутри сервера существует внутренняя буферизация). Информация о том как остановить сервер можно найти в Section 17.5. Необходимо сказать, что вам также необходимо остановить сервер и перед восстановлением данных.
Если вы не понимаете деталей хранения базы данных на файловой системе, то вы можете попытаться сделать резервную копию или восстановить только определённые отдельные таблицы или базы данных из соответствующих файлов или каталогов. Это не будет работать, потому что информация, содержащаяся в этих файлах не является корректной без файлов журналов транзакций, pg_clog/*, которые содержат состояние всех транзакций. Файлы таблиц будут пригодными к использованию только с этой информацией. Разумеется также невозможно восстановить только одну таблицу и ассоциирванные данные pg_clog, потому что это сделает все другие таблицы в кластере баз данных непригодными к использованию. Таким образом, резервные копии файловой системы работают только в случае полной резервной копии и восстановления кластера баз данных полностью.
Альтернативным подходом к резервному копированию файловой системы является создание "целостного снимка" каталога с данными, если файловая система поддерживает такую фукциональность (и если вы готовы доверять корректности реализации этой функциональности). Типичная процедура состоит в создании "замороженного снимка" тома, содержащего базу данных, а затем копирования всего каталога с данными (а не только его частей, см. выше) из этого снимка на устройство резервного копирования, затем освобождение замороженного снимка. Это будет работать даже если сервер баз данных будет запущен в это время. Однако, резервная копия, созданная таким способом, сохраняет файлы базы данных в состоянии, как если бы сервер баз данных не был остановлен должным образом; таким образом когда вы запускаете сервер баз данных на сохраннёной резервной копии, он будет думать, что предыдущий запуск сервера закончился крахом и будет накатывать журнал WAL. Это не является проблемой; просто будьте осторожны с этим (и убедитесь, что включили файлы WAL в вашу резервную копию). Для уменьшения времени восстановления, перед созданием снимка, вы можете выполнить команду CHECKPOINT.
Если ваша база данных размещена на нескольких файловых системах, может не существовать никаких способов получения точно-одновременных замороженных снимков всех томов. Например, если ваши файлы с данными и журналы WAL находятся на разных дисках или если табличные пространства расположены на других файловых системах, может оказаться невозможным использовать резервную копию с помощью снимков, потому что эти снимки должны быть одновременными. В этой ситуации, тщательно прочтите документацию по вашей файловой системе перед тем как довериться технологии целостности снимков.
Если одновременные снимки невозможны, их можно получить только остановкой сервера баз данных на время достаточное, для получения всех замороженных снимков. Другим решением может стать выполнение резервного копирования непрерывным архивированием (Section 24.3.2), потому что такие резервные копии защищены от изменений файловой системы во время выполнения резервного копирования. Это требует включения непрерывного архивирования только во время процесса резервного копирования; восстановление выполняется с помощью восстановления из непрерывного архивирования (Section 24.3.3).
Другое решение состоит в использовании rsync для выполнения резервной копии файловой системы. Оно выполняется путём запуска вначале rsync во время работы сервера баз данных, затем остановки сервера только на время достаточное для второго запуска rsync. Второй запуск rsync отработает намного быстрее, чем первый, потому что он обрабатывеает относительно мало данных и окончательный результат получится целостным, потому что сервер был остановлен. Данный метод позволяет выполнять резервное копирование файловой системы с минимальным временем простоя.
Обратите внимание, что резервная копия файловой системы обычно будет иметь больший размер, чем SQL дамп. (Программе pg_dump не нужно, например, делать дамп индексов, только команды для пересоздания их). Однако, выполнение резервного копирования файловой системы может происходить быстрее.