Восстановление данных

Сведения

В текущей версии утилитаcopywala была переименована. При ручном вызове необходимо использовать новое имя исполняемого файла – pangolin-copywala.

• Восстановление данных из резервной копии
• Восстановление данных из дельта-копии
• Восстановление кластера БД при помощи драйвера fuse
• Поиск и восстановление данных из последней резервной копии
• Восстановление данных из резервной копии на момент времени (PITR)
• Гранулярное восстановление базы данных

Восстановление данных из резервной копии

подсказка

Исполнять сценарий необходимо от имени пользователя postgres.

Описание сценария

Инициирование пользователем восстановления данных из резервной копии.

В конфигурационном файле предусмотрено поле restore_data_path, которое определяет путь для восстановления из резервной копии (РК). Если в случае резервной копии Pangolin/PostgreSQL данное поле не заполнено, обратитесь к значению из поля restore_pgdata_path.

работа в режиме direct_io

Режим direct_io позволяет работать напрямую с памятью приложения, тем самым повышая производительность за счет исключения дополнительного этапа кеширования.

Параметр read_direct_io включает чтение данных из архива в режиме direct_io. Применяется только при восстановлении из локальной копии.

restore_policy:
  read_direct_io: false

Предусловие

Перед восстановлением данных из РК убедитесь, что агентское приложение зарегистрировано либо прошла успешная инициализация приложения.

Последовательность выполнения

Пользователь инициирует восстановление резервной копии через CLI компонента Copywala командой copywala restore <путь к файлу РК> [-d|–destination *директория, в которую необходимо производить восстановление*] [-t|--tablespace-mapping *соответствие между предыдущим и новым местоположением табличного пространства*][--allow-default-tablespaces *использовать пути табличных пространств, сохраненных во время создания РК*] [--dry-run *проверка возможности восстановления из заданной резервной копии*].

Флаг --dry-run

Флаг --dry-run осуществляет проверку корректности конфигурационного файла и возможность восстановления из заданной резервной копии:

$ copywala restore s2://srv-48-72:29509/test6_0199190e-d195-712e-8ae4-0b90ced58552/backups/2025-09-05-17-30_01991a49-7aad-7b70-90a5-ec790e0dfcf2_delta_00000008000000130000002C_from_000000050000001300000019.cwl -d /mnt/backup/testrestore/restore_latest_92894 s2://srv-48-72:29509 -t /tmp/tblspc123=/tmp/tblspc5 --dry-run
2025-09-08 10:14:09.144 INF copywala develop (06b496d) compiled at 2025-09-05_06:54:40
2025-09-08 10:14:10.147 WRN run command in dry run mode (without actually restoring data)
2025-09-08 10:14:10.376 INF restore source uri: s2://srv-48-72:29509/test6_0199190e-d195-712e-8ae4-0b90ced58552/backups/2025-09-05-17-30_01991a49-7aad-7b70-90a5-ec790e0dfcf2_delta_00000008000000130000002C_from_000000050000001300000019.cwl?ssl=true
2025-09-08 10:14:10.444 INF restore destination uri: local-fs:///mnt/backup/testrestore/restore_latest_92894
2025-09-08 10:14:10.647 INF inferring parent backup for given backup test6_0199190e-d195-712e-8ae4-0b90ced58552/backups/2025-09-05-17-30_01991a49-7aad-7b70-90a5-ec790e0dfcf2_delta_00000008000000130000002C_from_000000050000001300000019.cwl
2025-09-08 10:14:10.716 INF parent backup test6_0199190e-d195-712e-8ae4-0b90ced58552/backups/2025-09-05-12-05_0199191f-cfa2-7313-85b7-12fa85de248d_full_000000050000001300000019.cwl inferred
2025-09-08 10:14:10.844 INF restoring delta backup, with following restore chain: [test6_0199190e-d195-712e-8ae4-0b90ced58552/backups/2025-09-05-17-30_01991a49-7aad-7b70-90a5-ec790e0dfcf2_delta_00000008000000130000002C_from_000000050000001300000019.cwl test6_0199190e-d195-712e-8ae4-0b90ced58552/backups/2025-09-05-12-05_0199191f-cfa2-7313-85b7-12fa85de248d_full_000000050000001300000019.cwl]
2025-09-08 10:14:10.897 INF dry-run mode successfully completed

Если проверка прошла успешно, инициируйте восстановление через CLI компонента Copywala командой copywala restore <путь к архиву с РК>.

Исключительные сценарии:

• Не существует папка для указанного табличного пространства:

  $ copywala restore s2://srv-48-72:29509/test6_0199190e-d195-712e-8ae4-0b90ced58552/backups/2025-09-05-17-30_01991a49-7aad-7b70-90a5-ec790e0dfcf2_delta_00000008000000130000002C_from_000000050000001300000019.cwl -d /mnt/backup/testrestore/restore_latest_92894 s2://srv-48-72:29509 -t /tmp/tblspc123=/tmp/tblspc5 --dry-run
  2025-09-08 10:14:00.116 INF copywala develop (06b496d) compiled at 2025-09-05_06:54:40
  2025-09-08 10:14:00.144 WRN run command in dry run mode (without actually restoring data)
  2025-09-08 10:14:00.447 INF restore source uri: s2://srv-48-72:29509/test6_0199190e-d195-712e-8ae4-0b90ced58552/backups/2025-09-05-17-30_01991a49-7aad-7b70-90a5-ec790e0dfcf2_delta_00000008000000130000002C_from_000000050000001300000019.cwl?ssl=true
  2025-09-08 10:14:00.671 INF restore destination uri: local-fs:///mnt/backup/testrestore/restore_latest_92894
  2025-09-08 10:14:00.713 ERR failed to init restore components err="stat /tmp/tblspc5: no such file or directory"

• Папка, в которую производится восстановление, не пустая:

  $ copywala restore s2://srv-48-72:29509/test6_0199190e-d195-712e-8ae4-0b90ced58552/backups/2025-09-05-17-30_01991a49-7aad-7b70-90a5-ec790e0dfcf2_delta_00000008000000130000002C_from_000000050000001300000019.cwl -d /mnt/backup/testrestore/restore_latest_92894 s2://srv-48-72:29509 -t /tmp/tblspc123=/tmp/tblspc5 --dry-run
  2025-09-08 10:11:39.176 INF copywala develop (06b496d) compiled at 2025-09-05_06:54:40
  2025-09-08 10:11:39.344 WRN run command in dry run mode (without actually restoring data)
  2025-09-08 10:11:39.447 INF restore source uri: s2://srv-48-72:29509/test6_0199190e-d195-712e-8ae4-0b90ced58552/backups/2025-09-05-17-30_01991a49-7aad-7b70-90a5-ec790e0dfcf2_delta_00000008000000130000002C_from_000000050000001300000019.cwl?ssl=true
  2025-09-08 10:11:39.531 INF restore destination uri: local-fs:///mnt/backup/testrestore/restore_latest_32934
  2025-09-08 10:11:39.671 ERR failed to init restore components err="can't restore to non-empty directory /mnt/backup/testrestore/restore_latest_32934"

Флаг --allow-default-tablespaces

Флаг --allow-default-tablespaces разрешает использование путей табличных пространств, указанных при создании РК и имеет приоритет перед настройками, задаваемыми через флаг -t|--tablespace-mapping.

Результат

В результате выполнения команды будет выведен прогресс и результат выполнения восстановления данных из резервной копии в заданную директорию:

$ copywala restore backups/dbmain_019938e4-d1f8-7958-973a-0a90dc6bae88/backups/2025-09-17-12-18_019956f8-4544-75b2-8929-b62b27dc69b2_full_000000030000000200000069.cwl -d test-data -t /home/postgres/tbl1=restore-tbl1
2025-09-17 12:22:18.144 INF copywala develop (e09c970) compiled at 2025-09-11_08:54:11
2025-09-17 12:22:18.447 INF restore source uri: local-fs:///home/postgres/backups/dbmain_019938e4-d1f8-7958-973a-0a90dc6bae88/backups/2025-09-17-12-18_019956f8-4544-75b2-8929-b62b27dc69b2_full_000000030000000200000069.cwl
2025-09-17 12:22:18.576 INF restore destination uri: local-fs:///home/postgres/test-data
2025-09-17 12:22:18.644 INF number of parallel workers workers_no=4
2025-09-17 12:22:18.747 INF page checksums verification disabled package=cwl
2025-09-17 12:22:19.176 INF reading will be performed sequentially package=cwl
2025-09-17 12:22:19.244 INF restore progress processed_data_size=45534026 data_size=438489926 wal_size=16777216
2025-09-17 12:22:19.447 INF restore progress processed_data_size=99872282 data_size=438489926 wal_size=16777216
2025-09-17 12:22:19.576 INF restore progress processed_data_size=166456858 data_size=438489926 wal_size=16777216
2025-09-17 12:22:19.644 INF restore progress processed_data_size=233041434 data_size=438489926 wal_size=16777216
2025-09-17 12:22:19.647 INF restore progress processed_data_size=289607194 data_size=438489926 wal_size=16777216
2025-09-17 12:22:19.776 INF restore progress processed_data_size=366210586 data_size=438489926 wal_size=16777216
2025-09-17 12:22:19.844 INF restore progress processed_data_size=414289434 data_size=438489926 wal_size=16777216
2025-09-17 12:22:19.947 INF restore progress processed_data_size=468662057 data_size=438489926 wal_size=16777216
2025-09-17 12:22:19.976 INF finished reading parts package=cwl
2025-09-17 12:22:19.991 INF updating tablespace_map file package=cwl

Исключительные сценарии

Будет выведено соответствующее сообщение для случаев:

• У пользователя нет прав на запись данных в заданную директорию.
• У пользователя нет прав на чтение файла с РК.
• У пользователя недостаточно свободного места на диске для выполнения восстановления РК.

Восстановление данных из дельта-копии

Описание сценария

Инициирование пользователем восстановления данных из дельта-копии.

Последовательность выполнения

примечание

Сценарий восстановления подразумевает использование полной копии вместе с последними дельта-копиями, хранящимися в одной и той же директории.

Пользователь инициирует восстановление резервной копии через CLI компонента Copywala командой:

copywala restore \
  [-d | --destination <PGDATA>] \
  [-t | --tablespace-mapping <mapping>] \
  <путь к архиву РК>

• <PGDATA> – путь к папке PGDATA для восстановления файлов БД;
• <mapping> – соответствие между предыдущим и новым местоположением табличного пространства.

к сведению

Если указать флаг --allow-default-tablespaces, будет использован стандартный маппинг пространств таблиц, сохраненный в РК.

Если в конфигурационном файле указан параметр restore_pgdata_path (в основном разделе) и не задан параметр destination, то восстановление будет выполнено в папку, указанную в restore_pgdata_path.

Результат

Цепочка РК восстанавливается либо последовательно от полной копии (full) к целевой (delta), либо наоборот — от целевой к полной. Режим задается параметром:

restore_policy:
  reverse_restore: false # где false – это прямой порядок, true – обратный.

В результате выполнения команды будет выведен прогресс и результат выполнения восстановления данных из резервной копии в каталог базы данных PGDATA.

Исключительные сценарии

Будет выведено соответствующее сообщение для случаев:

• У пользователя нет прав на запись данных в каталог PGDATA.
• У пользователя нет прав на чтение файла с РК.
• У пользователя недостаточно свободного места на диске для выполнения восстановления РК.

Восстановление кластера БД при помощи драйвера fuse

подсказка

Исполнять сценарий необходимо от имени пользователя postgres.

Описание сценария

Решение, позволяющее восстанавливать кластер СУБД непосредственно из смонтированного каталога PGDATA (архив CWL), минуя полное восстановление (используя драйвер FUSE).

Подробнее про технологию FUSE

Чтобы восстановить экземпляр базы данных, используют команду copywala restore. Этот метод требует полной распаковки всего архива, что занимает значительное время и может оказаться крайне неудобным, особенно если необходимо быстро провести диагностику ошибок, возникающих при эксплуатации экземпляра.

Команда copywala fuse задействует механизм FUSE (Filesystem in Userspace, файловая система в пространстве пользователя), монтируя виртуальное представление каталога РК. Система воспринимает этот смонтированный каталог так же, как обычный каталог PGDATA, а все обращения к файловой системе перенаправляются в соответствующие файлы резервной копии. Поскольку изменения записываются лишь в промежуточный кеш, сама резервная копия остается неизменной. Операции осуществляются исключительно в режиме чтения.

Последовательность выполнения

1. Остановите текущий экземпляр базы данных:

   sudo su - postgres
   pg_ctl stop

2. Создайте каталог для последующего монтирования:

   mkdir /mnt/restore_dir
   chmod 700 /mnt/restore_dir
   chown postgres:postgres /mnt/restore_dir

3. Запустите команду для монтирования архива через CLI компонента Copywala:

   copywala fuse  <mount-directory> <archive-uri-or-path> [--cache-swap-size | размер кеша подкачки][--cache-dir | путь к директории с выгружаемым кешем ]

   Для стабильной работы файловой системы, смонтированной через FUSE, важно установить ряд ключевых параметров:

   Флаг cache-swap-size

   cache-swap-size – размер данных, выгружаемых из архива CWL и хранимых в оперативной памяти. При превышении указанного объема данные, находящиеся в памяти, выгружаются на диск в директорию, указанную в параметре cache-dir. По окончании работы временные данные автоматически удаляются (по умолчанию 256 МБ)

   Флаг cache-dir

   cache-dir – директория, в которую переносятся на диск данные из оперативной памяти при превышении значения cache-swap-size. Значение по умолчанию — /tmp.

   Пример запуска команды:

   $ copywala fuse /pgdata/06/data database_backup.cwl
   2025-09-22 12:56:24.313 INF start fuse mounting mount_path=/pgdata/06/data cache_swap_size=268435456 cache_dir=/tmp

4. Откройте новое окно терминала под пользователем postgres.

5. Запустите экземпляр базы данных, указывая смонтированную директорию

   pg_ctl start -D <mount-directory>

6. По завершении использования остановите экземпляр базы данных:

   pg_ctl stop -D <mountpath>

7. Вернитесь в терминал с командой copywala-fuse и завершите ее работу.

Результат

В результате выполнения команды будет обеспечено восстановление базы данных с использованием технологии FUSE.

Исключительные сценарии

• Не удалось установить подключение к смонтированному каталогу.
• Недостаточно оперативной памяти.
• Ошибка в назначении прав доступа к файлам.

Поиск и восстановление данных из последней резервной копии

подсказка

Исполнять сценарий необходимо от имени пользователя postgres.

Описание сценария

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

Последовательность выполнения

Инициируйте поиск и восстановление последней РК через CLI компонента Copywala командой copywala restore latest [-d|–destination *директория, в которую необходимо производить восстановление*] [-t|--tablespace-mapping *соответствие между предыдущим и новым местоположением табличного пространства*] [--allow-default-tablespaces *использовать пути табличных пространств, сохраненных при создании РК*] [--dry-run *проверка возможности восстановления из заданной резервной копии*].

Результат

В результате выполнения команды инициируется процесс восстановления, состоящий из двух этапов:

• определение последней доступной резервной копии, подходящей для восстановления;
• запуск процесса построения цепи восстановления, необходимой для приведения системы в рабочее состояние.

Если указанные этапы выполнены успешно, процесс восстановления завершится без ошибок:

finished reading parts

Исключительные сценарии

Будет выведено соответствующее сообщение для случаев:

• Отсутствует папка с РК:

  2025-09-15 17:00:47.132 ERR failed to select latest backup err="list local backups: read dir: open /home/postgres/backups/dbmain_019938e4-d1f8-7958-973a-0a90dc6bae88/backups: no such file or directory"

• Отсутствует одна из промежуточных дельта-копий в цепочке:

  2025-09-15 17:06:36.365 ERR failed to init restore components err="No parent delta backup with backup_id 01994daf-a516-72e2-a78e-c9a583ea306c for /home/postgres/backups/dbmain_019938e4-d1f8-7958-973a-0a90dc6bae88/backups/2025-09-15-17-03_01994daf-b8fb-706f-a893-509c4d8c3377_delta_000000030000000200000001_from_0000000300000001000000FF.cwl."

• Если не задан флаг --tablespace-mapping, то будет выведено:

  2025-09-15 17:05:09.243 ERR failed to init restore components err="tablespace mapping not provided for given tablespace /home/postgres/tbl1"

Восстановление данных из резервной копии на момент времени (PITR)

Описание сценария

Использование технологии Point-In-Time Recovery (PITR) позволяет вернуть базу данных к состоянию на определенный момент времени посредством полной резервной копии и журнала транзакций (WAL-файлов).

Общая схема процесса восстановления на момент времени:

1. Восстановите данные из резервной копии.
2. Настройте команду restore_command, предназначенную для восстановления сегментов WAL, а также установите необходимые параметры восстановления recovery_* в конфигурационном файле postgresql.conf.
3. Создайте файл recovery.signal для переключения в режим восстановления.
4. Запустите базу данных.

Рассмотрим ситуацию, когда необходимо восстановить базу данных на определенный номер журнала транзакций (LSN). Будем работать с двумя виртуальными машинами, на каждой из которых установлен Pangolin версии 6.5.2. На первой виртуальной машине создадим резервную копию, внесем ряд изменений и зафиксируем значение LSN. Затем на второй виртуальной машине восстановим базу данных из резервной копии и перед запуском сервера настроим параметры восстановления именно на указанный ранее LSN.

Подготовка первой виртуальной машины

1. Выполните установку компонента Copywala:

   SberLinux, РЕД ОС, CentOS

   sudo dnf install copywala-{version_component}-{OS}.x86_64.rpm

   Astra Linux

   sudo apt install copywala-{version_component}-{OS}.x86_64.deb

   Альт СП

   sudo apt-get install copywala-{version_component}-{OS}.x86_64.rpm

   Пример заполненной команды:

   sudo dnf install copywala-1.1.0-sberlinux9.x86_64.rpm

2. Инициализируйте экземпляр приложения для настройки уникального имени и присвоения идентификатора экземпляра БД (подробнее в сценарии):

   copywala init db1

3. Настройте хранилище для резервных копий в конфигурационном файле copywala.yaml:

   backup_destination_uri: /home/postgres/backups

4. Настройте хранилище для архивирования WAL-файлов в конфигурационном файле copywala.yaml:

   wal_destination_uri: /home/postgres/backups

5. Включите архивирование WAL-файлов в конфигурационном файле postgresql.conf и настройте команду архивирования и восстановления WAL-файлов:

   archive_mode = 'on'
   archive_command = 'copywala archive-wal %f %p'
   restore_command = 'copywala restore-wal %f %p'

   Опционально в команде архивирования можно включить вывод статистики:

   archive_command = 'copywala archive-wal %f %p --stat'

6. Перезагрузите сервер после изменения поля archive_mode:

   pg_ctl restart

7. Запустите процедуру резервного копирования:

   copywala create-backup

8. Для проверки корректности восстановления на определенную точку во времени после завершения резервного копирования выполните операции, изменяющие данные в базе, например, создание таблицы:

   CREATE TABLE test(id int);
   INSERT INTO test (id) VALUES (generate_series(1, 1000000));

9. Чтобы определить момент внесения изменений в базу данных, выполните команду для получения текущего значения номера журнала транзакций (LSN):

   SELECT pg_current_wal_lsn();

10. Для подтверждения корректности операции восстановления до нужного момента времени создайте дополнительную таблицу:

    CREATE TABLE wrong_test(id int);
    INSERT INTO wrong_test (id) VALUES (generate_series(1, 1000000));

11. Переключите текущий WAL-сегмент, чтобы гарантировать архивирование последних изменений:

    SELECT pg_switch_wal();

12. Проверьте, что WAL-файлы заархивированы успешно:

    ll /home/postgres/backups/<instance_name>/wals/

Последовательность действий

1. Выполните установку компонента Copywala:

   SberLinux, РЕД ОС, CentOS

   sudo dnf install copywala-{version_component}-{OS}.x86_64.rpm

   Astra Linux

   sudo apt install copywala-{version_component}-{OS}.x86_64.deb

   Альт СП

   sudo apt-get install copywala-{version_component}-{OS}.x86_64.rpm

   Пример заполненной команды:

   sudo dnf install copywala-1.1.0-sberlinux9.x86_64.rpm

2. Инициализируйте экземпляр приложения:

   copywala init db2

3. Настройте хранилище для резервных копий в конфигурационном файле copywala.yaml:

   backup_destination_uri: /home/postgres/backups

4. Настройте хранилище для архивирования WAL-файлов в конфигурационном файле copywala.yaml:

   wal_destination_uri: /home/postgres/backups

Шаги для восстановления данных из резервной копии на момент времени

1. Получите список доступных экземпляров базы данных из хранилища и выберите экземпляр (instance_name) из первой виртуальной машины (название начинается с db1):

   copywala storage instances

2. Для восстановления выбранного экземпляра БД настройте его наименование (instance_name) в конфигурационном файле copywala.yaml, выполнив команду:

   copywala config set --restore-instance-name=<instance_name>

3. Восстановите каталог PGDATA из последней резервной копии в заданную папку:

   copywala restore latest --destination=/pgdata/db-restored

   примечание

   Если в резервной копии содержатся табличные пространства, подготовьте необходимые директории (например, смонтируйте нужные разделы дисков) и укажите сопоставление старых путей новым опцией -t old=new для каждого табличного пространства.

4. Настройте в конфигурационном файле postgresql.conf целевую точку во времени, до которой требуется произвести восстановление.

   к сведению

   По умолчанию при восстановлении применяются все доступные WAL-файлы, данное поведение можно ограничить, задав один из параметров: recovery_target, recovery_target_lsn, recovery_target_name, recovery_target_time, recovery_target_xid. Подробнее про это читайте в документации Platform V Pangolin.

   Например, задайте контрольную точку во времени, используя параметр recovery_target_lsn. Установите его значение равным номеру журнала транзакций (LSN), полученному после завершения подготовки данных для таблицы test. Альтернативно можно задать точное время восстановления с помощью параметра recovery_target_time.

   Чтобы сервер запускался после завершения процесса восстановления, установите в конфигурационном файле опцию:

   recovery_target_action = 'promote'

   Это позволит автоматически перевести сервер из режима восстановления в обычный рабочий режим сразу после достижения целевой точки восстановления.

5. Создайте файл для переключения сервера в режим восстановления:

   touch /pgdata/db-restored/recovery.signal

6. Запустите сервер:

   pg_ctl start -D /pgdata/db-restored/

7. Проверьте наличие таблицы test с данными:

   SELECT COUNT(*) FROM test;
     count
   ---------
   1000000
   (1 row)

8. Проверьте отсутствие таблицы wrong_test:

   SELECT COUNT(*) FROM wrong_test;
   ERROR:  relation "wrong_test" does not exist

Результат

Сервер успешно запустился, и данные в таблице test совпадают с ожидаемыми результатами.

Исключительные сценарии

1. Ошибка запуска сервера. Проанализируйте содержимое лог-файлов.
2. Отсутствие нужных данных или тестовой таблицы. Удостоверьтесь в корректности выбранного момента времени (или LSN) и повторите операцию восстановления.

Гранулярное восстановление базы данных

Описание сценария

Процедура частичного восстановления объектов базы данных до согласованного состояния на заданный момент времени, осуществляемая без полной остановки рабочего экземпляра СУБД и не требующая восстановления всей совокупности данных. В сценарии рассматривается процесс восстановления отдельной таблицы из ранее сделанной резервной копии с помощью технологии copywala fuse и утилиты pg_dump.

Последовательность выполнения

1. Остановите текущий кластер:

   pg_ctl stop

2. Создайте директорию для монтирования CWL-архива:

   mkdir /path/to/cwl_archive_mount_point

3. Запустите сценарий:

   copywala fuse /path/to/cwl_archive_mount_point <archive uri or path>

   Где archive uri – это URI для доступа к архиву в облачных хранилищах типа S2/S3, path – путь к локальному файлу.

4. После запуска терминал заблокируется и в журнале появится запись:

   INF start fuse mounting mount_path=<mount-dir> cache_swap_size=268435456 cache_dir=/tmp

5. Откройте новый отдельный терминал и запустите экземпляр PostgreSQL на смонтированном каталоге:

   pg_ctl start -D <mount-dir>

6. Убедитесь, что сервер успешно запущен, проверяя доступ к данным через консоль psql, выполнив простой запрос к необходимой таблице.

7. Выйдите из сессии psql и создайте дамп выбранной таблицы:

   pg_dump -U <username> -d <database> -t <schema.table_name> > dump.sql

   к сведению

   Обратите внимание, что скорость работы pg_dump на файловом слое FUSE существенно ниже по сравнению с локальной системой хранения, так как данные считываются непосредственно из архива. Процесс займет значительное время, около 40 минут для таблицы размером примерно 9 ГБ.

8. Подключитесь к целевому экземпляру PostgreSQL, где планируется восстановление таблицы, и импортируйте сохраненный дамп:

   psql -U <username> <database> < dump.sql

9. Завершите работу с файлом системы FUSE:

   • Остановите запущенную копию PostgreSQL:

     pg_ctl stop -D <mount-dir>

   • Вернитесь к окну терминала, где была выполнена команда copywala fuse, и завершите ее выполнение.

Результат

В результате успешной операции будет создана полная копия структуры и всех данных указанной таблицы в файле dump.sql.

Исключительные сценарии

• Ошибка монтирования файловой системы FUSE: недостаточно прав на создание или монтирование каталога, неверно указан путь к директории, недостаточное количество оперативной памяти или места на диске.

  Решение: убедитесь, что путь к директории верный, вы работаете от имени суперпользователя или имеете достаточные привилегии. Освободите необходимое пространство или увеличьте лимит памяти.

• Ошибка размонтирования файловой системы FUSE:

  Решение: принудительно завершите приложение, использующее систему FUSE, и повторно примените команду размонтирования.