Backup postgresql restore: Backup and restore a PostgreSQL database on PgAdmin 4 using the program’s graphical interface

Содержание

PostgreSQL: Документация: 15: 26.2. Резервное копирование на уровне файловой системы

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

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

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

Сервер базы данных должен быть остановлен , чтобы получить пригодную для использования резервную копию. Половинчатые меры, такие как запрет всех подключений , а не , будут работать (отчасти потому, что tar и подобные инструменты не делают атомарный снимок состояния файловой системы, а также из-за внутренней буферизации на сервере). Информацию об остановке сервера можно найти в разделе 19. 5. Излишне говорить, что вам также необходимо выключить сервер перед восстановлением данных.
Если вы подробно изучили структуру файловой системы базы данных, у вас может возникнуть соблазн попытаться создать резервную копию или восстановить только определенные отдельные таблицы или базы данных из соответствующих файлов или каталогов. Это будет работать , а не , потому что информация, содержащаяся в этих файлах, не может использоваться без файлов журнала фиксации, pg_xact/* , которые содержат статус фиксации всех транзакций. Табличный файл можно использовать только с этой информацией. Конечно, также невозможно восстановить только таблицу и связанные с ней pg_xact data, потому что это сделало бы все остальные таблицы в кластере базы данных бесполезными. Таким образом, резервное копирование файловой системы работает только для полного резервного копирования и восстановления всего кластера базы данных.

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

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

Если одновременные моментальные снимки невозможны, одним из вариантов является выключение сервера базы данных на время, достаточное для создания всех замороженных моментальных снимков. Другим вариантом является выполнение непрерывного архивирования базовой резервной копии (раздел 26.3.2), поскольку такие резервные копии невосприимчивы к изменениям файловой системы во время резервного копирования. Это требует включения непрерывного архивирования только во время процесса резервного копирования; восстановление выполняется с помощью непрерывного восстановления архива (раздел 26. 3.4).

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

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

postgresql — Как восстановить базу данных postgres из дампа пользовательского формата?

Задавать вопрос

спросил
3 года, 2 месяца назад

Изменено
1 год, 3 месяца назад

Просмотрено
6к раз

У меня проблема с восстановлением базы данных с помощью pg_restore. У меня установлен Postgres 12.2 на моем Mac с High Sierra (10.13.6). Он был установлен вместе с Brew.

Я создал простую базу данных «foo» с таблицей «foo», чтобы проверить это:

 Nates-MacBook-Pro:k8s natereed$ psql -d foo
psql (12.2, сервер 12.1)
Введите "помощь" для помощи.
foo=# ВЫБРАТЬ table_schema,table_name
ИЗ information_schema.tables
ГДЕ table_schema='public' ORDER BY table_schema,table_name;
таблица_схема | имя_таблицы
--------------+------------
общественный | фу
(1 ряд)

Создать дамп:

 pg_dump -Fc foo -f foo.backup

При попытке восстановления ничего не происходит. pg_restore просто зависает:

 pg_restore -h localhost -p 5432 -U postgres -v -Fc -f foo.backup

Пробовал разные варианты этой команды, но каждый раз просто зависает. В Activity Monitor я вижу процесс, но он не использует процессор.

postgresql
пг-восстановление

Онлайн-справка говорит:

 pg_restore восстанавливает базу данных PostgreSQL из архива, созданного pg_dump. 
Использование:
  pg_restore [ВАРИАНТ]... [ФАЙЛ]
Общие настройки:
  -d, --dbname=ИМЯ подключиться к имени базы данных
  -f, --file=FILENAME имя выходного файла
  -F, --format=c|d|t формат файла резервной копии (должен быть автоматическим)
  -l, --list вывести краткое оглавление архива
  -v, --verbose подробный режим
  -V, --version вывести информацию о версии, затем выйти
  -?, --help показать эту справку, затем выйти

Для pg_restore -f параметр для выходного файла: это не входной файл. Удалите -f в вашем примере:

 pg_restore -h localhost -p 5432 -U postgres -v -Fc foo.backup

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя электронную почту и пароль

Опубликовать как гость

Электронная почта

Требуется, но никогда не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

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