Альтернативная стратегия резервного копирования заключается в прямом копировании файлов, которые использует Tantor SE для хранения данных в базе данных; Раздел 18.2 объясняет, где находятся эти файлы. Вы можете использовать любой метод, который предпочитаете для создания резервных копий файловой системы; например:

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

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

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

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

Если одновременные снимки невозможны, один из вариантов - выключить сервер базы данных на достаточно долгое время для установки всех замороженных снимков. Другой вариант - выполнить непрерывное архивное базовое резервное копирование (Раздел 25.3.2), так как такие резервные копии устойчивы к изменениям файловой системы во время резервного копирования. Для этого необходимо включить непрерывное архивирование только во время процесса резервного копирования; восстановление выполняется с использованием непрерывного восстановления из архива (Раздел 25.3.4).

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

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