1. Сервер базы данных должен быть остановлен для получения корректной резервной копии. Полумеры, такие как запрет всех новых подключений, не будут эффективны (отчасти потому, что утилита tar и аналогичные инструменты не создают атомарный снимок состояния файловой системы, а также по причине внутреннего буферирования данных на стороне сервера). Информация об остановке сервера приведена в Раздел 3.3.5. Разумеется, перед восстановлением данных также необходимо завершить работу сервера.

2. Если вы подробно изучили структуру файловой системы базы данных, может возникнуть соблазн попытаться выполнить резервное копирование или восстановление только отдельных таблиц или баз данных из их соответствующих файлов или каталогов. Это не не сработает, так как информация в этих файлах бесполезна без файлов журналов фиксации транзакций pg_xact/*, которые содержат сведения о статусе завершения всех транзакций. Файл таблицы может быть использован только при наличии данной информации. Разумеется, также невозможно восстановить отдельно взятую таблицу и связанные с ней pg_xact данные, поскольку это приведет к невозможности использования всех остальных таблиц в кластере баз данных. Таким образом, резервное копирование на уровне файловой системы применимо только для полного резервного копирования и восстановления всего кластера баз данных.

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

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

В случае невозможности создания одновременных снимков одним из вариантов является остановка сервера базы данных на период, достаточный для фиксации всех мгновенных снимков. Альтернативным вариантом является создание базовой резервной копии в режиме непрерывного архивирования (Раздел 3.10.3.2) поскольку такие резервные копии устойчивы к изменениям файловой системы в процессе копирования. Для этого требуется активация функции непрерывное архивирование только на период резервного копирования; восстановление же осуществляется через восстановление из архива (Раздел 3.10.3.5).

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

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