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

Утилита pg_basebackup позволяет создать базовую резервную копию работающего кластера PostgreSQL. Она создает резервные копии, не затрагивая других клиентов базы данных.

Утилита pg_basebackup создает точную копию файлов кластера, автоматически включая и отключая режим резервного копирования. Резервные копии создаются для всего кластера. Невозможно сделать копию отдельных баз данных или объектов базы данных. Для выборочного резервного копирования используйте утилиту pg_dump, как описано в статье SQL-дамп.

Утилита pg_basebackup создает резервные копии через стандартное соединение PostgreSQL, использующее протокол репликации. Соединение должно быть установлено от имени суперпользователя или пользователя с правами запускать репликацию, также pg_hba.conf должен разрешать подключения для репликации.

В следующем примере создается резервная копия сервера, находящегося на хосте 10.92.6.36, и сохраняется в локальном каталоге /usr/local/pgsql/data:

Код, приведенный ниже, создает резервную копию локального сервера с одним tar-файлом для каждого табличного пространства и сохраняет его в каталоге backup2022-12-22:

За дополнительной информацией о параметрах утилиты pg_basebackup обратитесь к статье pg_basebackup.

Вы можете создать архивный файл, используя утилиту tar:

Этот метод имеет два ограничения:

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

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

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