Вопрос: Как восстановить файл дампа PostgreSQL в базы данных Postgres? Восстановление базы postgresql из дампа

Дамп SQL | PostgreSQL

Идея, стоящая за методом дампа, заключается в генерации текстового файла с командами SQL, которые при выполнении на сервере, пересоздадут базу данных в том же самом состоянии, в котором она была на момент создания дампа. PostgreSQL предоставляет для этой цели програмнную утилиту pg_dump. Базовая подсказка использования этой команды выглядит так:

pg_dump имя_БД > файл_дампа

Как видите, pg_dump записывает результаты своей работы на стандартный вывод. Далее будет рассмотрено как из этого можно извлечь пользу.

pg_dump является для PostgreSQL обычным клиентским приложением (Хотя и особенно умным). Это означает, что вы можете выполнять процедуру резервного копирования с любого удалённого компьюетра, который имеет доступ к нужной базе данных. Но помните, что у pg_dump нет каких-то особых прав доступа. В частности, эта утилита должна иметь доступ на чтение всех таблиц, резервную копию которых вы хотите сделать, так что на практике её почти всегда нужно запускать с правами суперпользователя СУБД.

Чтобы указать, к какому серверу должен подключаться pg_dump, используйте опцию командной строки -h сервер и -p порт. По умолчанию, в качестве сервера выбирается localhost или тот сервер, что указан в переменной окружения PGHOST. Похожим образом, по умолчанию используется порт, указанный в переменной окружения PGPORT или, если переменная незаданна, то порт, указанный по умолчанию при компиляции. (Удобно, что сервер обычно имеет то же значение, скомпилированное по умолчанию.)

Как и любое другое клиентское приложение PostgreSQL, pg_dump по умолчанию будет подключаться к базе данных, под пользователем, имя которого совпадает с именем текущего пользователя в операционной системе. Чтобы перекрыть это, либо укажите опцию -U, либо установите переменную окружения PGUSER. Помните, что подключения, которые выполняет pg_dump, работают с учётом обычных механизмов авторизации (которые описываются в Chapter 19).

Важное преимущество pg_dump над другими методами резервного копирования, описывается позже и состоит в том, что вывод pg_dump может быть обычно перезагружен в более новые версии PostgreSQL, в то время как резервная копия на уровне файловой системы и непрерывное архивирование являются жёстко зависимыми от версии сервера. Также, только pg_dump является методом, который будет работать при переносе базы данных на другую машинную архитектуру, например, при переносе с 32-битной на 64-битную версию сервера.

Дампы, создаваемые pg_dump являются внутренне целостными, что означает, что дамп представляет собой снимок базы данных на момент начала запуска pg_dump. pg_dump не блокирует другие операции с базой данных во время своей работы. (Исключениями являются случаи, когда есть необходимость работы с эксклюзивной блокировкой, как у большинства форм команды ALTER TABLE.)

Important: Если ваша схема базы данных полагается на OID (например, как внешние ключи), вы должны сказать pg_dump, чтобы в дамп были также включены OID. Чтобы сделать это, используйте опцию командной строки -o.

Текстовые файлы, созданные pg_dump предназначаются для последующего чтения программой psql. Общий вид команды для восстановления дампа:

psql имя_БД < файл_дампа

где файл_дампа — это файл, содержащий вывод команды pg_dump. База данных, заданная параметром имя_БД не будет создана данной командой, так что вы должны создать её сами из базы template0 перед запуском psql (например, с помощью команды createdb -T template0 имя_БД). psql поддерживает опции для указания сервера, к которому осуществляется подключение и имени пользователя, похожие на pg_dump. Подробности см. на странице справочного руководства psql.

Перед восстановлением SQL дампа. все пользователи, которые владеют объектами или имеют права на объекты в базе данных, выгруженной в дамп, должны уже существовать. Если их нет, при восстановлении будут ошибки пересоздания объектов с оригинальными владельцами и/или правами. (Иногда, это и есть то, что вы хотите, но обычно нет).

По умолчанию, если произойдёт ошибка SQL, программа psql продолжит своё выполнение. Вы можете захотеть запустить psql с установленной переменной ON_ERROR_STOP, чтобы изменить такое поведение и заставить psql выйти с кодом выхода 3, в случае возникновения ошибки SQL:

psql --set ON_ERROR_STOP=on имя_БД < файл_дампа

В любом случае, у вас будет только частично восстановленная база данных. В качестве альтернативы, вы можете указать, что весь дамп должен быть восстановлен в одну транзацию, так что восстановление или будет полностью выполненно или полностью не выполнено. Данный режим может быть задан, с помощью опций командной строки -1 или --single-transaction для psql. Когда используется этот режим, будьте осторожны, даже маленькая ошибка может привести к откату процесса восстановления, который длится уже несколько часов. Однако, это может быть предпочтительней, чем ручная очистка сложной базы данных, после частично восстановленного дампа.

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

pg_dump -h сервер1 имя_БД | psql -h сервер2 имя_БД

Important: Дампы, которые делает pg_dump являются относительными template0. Это означает, что любые языки, процедуры и т.д. добавленные через template1, также попадут в дамп при выполнении pg_dump. В итоге, при восстановлении, если вы использовали специально изменённый template1, вы должны создать пустую базу данных из template0, как показано в примере выше.

После восстановления резервной копии, мудрым будет запустить ANALYZE на каждую базу данных, чтобы оптимизатор запросов получил нужную статистику; подробности см. в see Section 23.1.3 и в Section 23.1.5. Для того, чтобы узнать больше о том как эффективно загружать большие объёмы данных в PostgreSQL, см. Section 14.4.

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

pg_dumpall > файл_дампа

Результирующий дамп может быть восстановлен с помощью psql:

psql -f файл_дампа postgres

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

pg_dumpall получает и выдаёт команды для пересоздания ролей, табличных пространств и пустых баз данных, затем вызывает для каждой базы данных pg_dump. Это означает, что в то время как каждая база данных будет внутренне целостной, снимки других баз данных могут не быть точно синхронизированны.

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

Используйте сжатые дампы. Вы можете использовать вашу любимую программу сжатия, например gzip:

pg_dump имя_БД | gzip > имя_файла.gz

Загружая впоследствии сжатый дамп командой:

gunzip -c имя_файла.gz | psql имя_БД

или:

cat имя_файла.gz | gunzip | psql имя_БД

Используйте split. Команда split позволяет вам разбивать вывод на файлы меньшего размера, которые не попадают под ограничения на максимальный размер файла в файловой системе. Например, чтобы нарезать дамп на кусочки по 1 мегабайту:

pg_dump имя_БД | split -b 1m - имя_файла

Загружая впоследствии полученные файлы командой:

cat имя_файла* | psql имя_БД

Используйте специальный формат дампа в pg_dump. Если PostgreSQL была скомпилирована в системе с установленной библиотекой zlib, то специальный формат дампа будет сжимать данные, которые выдаются в файл вывода. Это приведёт к созданию файла дампа, который по размеру будет похож на дамп, сжатый gzip, но такой формат будет иметь преимущество, потому что позволяет выборочное восстановление таблиц. Следующая команда делает дамп базы данных, используя специальный формат дампа:

pg_dump -Fc имя_БД > имя_файла

Специальный формат дампа не является скриптом для psql и должен восстанавливаться с помощью команды pg_restore, например:

pg_restore -d имя_БД имя_файла

См. подробности на страницах справочного руководства pg_dump и pg_restore.

Для очень больших баз данных, вам может понадобиться сочетать split с одним из двух других методов.

postgresql.ru.net

Как восстановить файл дампа PostgreSQL в базы данных Postgres? Безопасный SQL

У меня есть файл дампа с расширением .SQL (на самом деле это текстовый файл SQL). Я хочу восстановить его в мои созданные базы данных. Я использую pgAdmin III , и когда я использую его «Мастер восстановления», он не выделяет кнопку «Восстановить». Вместо этого он ожидает расширение .backup .

Я попробовал использовать shell команды для восстановления дампа, но он все еще не работал.

Я новичок в этом. Если бы кто-нибудь мог мне помочь, я был бы обязан.

Я использовал следующую команду для панели SQL Shell PostGres, сидя в newTestDB.

Он по-прежнему выдавал ту же ошибку («Permission Denied»).

После повышения разрешений он просто показывает мне таблицы по умолчанию PostgreSQL:

Я не знаю, что делать для импорта / восстановления базы данных из файла SQL.

Вы не указали, как была сделана ваша резервная копия, поэтому общий ответ: Обычно с инструментом psql .

В зависимости от того, что pg_dump было дано для дампа, файл SQL может иметь разные наборы команд SQL. Например, если вы pg_dump для дампа базы данных с использованием --schema-only и --schema-only , вы не можете ожидать, что сможете восстановить базу данных из этого дампа, поскольку не будет никаких команд SQL для COPYING (или INSERTing if --inserts ) фактические данные в таблицах. Такой дамп будет содержать только команды DDL SQL и сможет воссоздать схему, но не фактические данные.

Типичный SQL-дамп восстанавливается с помощью psql :

psql (connection options here) database < yourbackup.sql

или, альтернативно, из сеанса psql ,

psql (connection options here) database database=# \i /path/to/yourbackup.sql

В случае резервных копий, сделанных с помощью pg_dump -Fc («пользовательский формат»), который не является простым файлом SQL, а сжатым файлом, вам нужно использовать инструмент pg_restore .

Если вы работаете над unix-подобным, попробуйте следующее:

man psql man pg_dump man pg_restore

в противном случае взгляните на html-документы . Удачи!

Проблема с вашей попыткой командной строки psql – это направление косых черт:

newTestDB-# /i E:\db-rbl-restore-20120511_Dump-20120514.sql # incorrect newTestDB-# \i E:/db-rbl-restore-20120511_Dump-20120514.sql # correct

Чтобы быть ясным, команды psql начинаются с обратного слэша, поэтому вместо этого вы должны поставить \i . То, что произошло в результате вашей опечатки, заключается в том, что psql игнорировал все, пока не обнаружил первый, за которым последовали db , а \db – команда psql для перечисления табличных пространств , поэтому выход был списком табличных пространств , Это был не список «таблиц по умолчанию PostgreSQL», как вы сказали.

Кроме того, кажется, что psql ожидает, что аргумент filepath разделит каталоги, используя прямую косую черту, независимо от ОС (таким образом, в Windows это будет интуитивно понятным).

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

Наконец, расширение файла дампа не имеет значения, на самом деле вам даже не требуется расширение. В самом деле, pgAdmin предлагает расширение .backup при выборе имени файла резервной копии, но вы действительно можете сделать все, что захотите, опять же, включая отсутствие расширения вообще. Проблема в том, что pgAdmin видимому, разрешает «восстановление» дампов «Пользовательский или tar» или «Directory» (по крайней мере, это относится к версии приложения MAC OS X), поэтому просто используйте команду psql \i как показано выше.

С помощью команды pg_restore вы можете восстановить базу данных postgres

Первый открытый тип терминала

sudo su postgres

Создать новую базу данных

createdb [имя базы данных] -O [владелец]

createdb test_db [-O openerp]

pg_restore -d [Имя базы данных] [путь к файлу дампа]

pg_restore -d test_db /home/sagar/Download/sample_dbump

Подождите завершения восстановления базы данных.

Помните, что файл дампа должен иметь чтение, запись, выполнение доступа, поэтому для этого вы можете применить команду chmod

1.Откройте терминал.

2.Нажмите свою базу данных следующей командой

ваш postgres bin – /opt/PostgreSQL/9.1/bin/

ваш исходный сервер базы данных – 192.168.1.111

местоположение и имя файла резервной копии – /home/dinesh/db/mydb.backup

имя источника db – mydatabase

/opt/PostgreSQL/9.1/bin/pg_dump –host '192.168.1.111' –порт 5432 – имя пользователя "postgres" –no-password –format custom –blobs -file "/ home / dinesh / db /mydb.backup "" mydatabase "

3. восстановить файл mydb.backup в пункт назначения.

ваш целевой сервер – localhost

имя вашей целевой базы данных – mydatabase

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

/opt/PostgreSQL/9.1/bin/psql -h 'localhost' -p 5432 -U postgres -c "CREATE DATABASE mydatabase"

восстановить резервную копию.

/opt/PostgreSQL/9.1/bin/pg_restore –host 'localhost' –port 5432 –username "postgres" –dbname "mydatabase" –no-password –clean "/ home / dinesh / db / mydb. резервное копирование"

Объединив совет от MartinP и user664833, я также смог заставить его работать. Caveat – это ввод psql из инструмента GUI pgAdmin с помощью выбора плагинов … Консоль PSQL устанавливает учетные данные и уровень разрешений для сеанса psql, поэтому у вас должны быть разрешения администратора или CRUD в таблице и, возможно, также администратор в базе данных (не точно знать об этом). Затем команда в консоли psql примет следующую форму:

postgres=# \i driveletter:/folder_path/backupfilename.backup

где postgres = # – это приглашение psql, а не часть команды.

Файл .backup будет включать команды, используемые для создания таблицы, поэтому вы можете также получить команды типа «ALTER TABLE …» в файле, который выполняется, но сообщается как ошибки. Я полагаю, вы всегда можете удалить эти команды перед запуском восстановления, но вы, вероятно, лучше безопасны, чем жаль, чтобы держать их там, так как это вряд ли приведет к сбою восстановления данных. Но всегда проверяйте, чтобы данные, которые вы хотели получить, действительно попали туда. (Извините, если это похоже на покровительствовать кому-либо, но это надзор, который может случиться с кем угодно, независимо от того, как долго они были на этом занятии – отвлечение внимания от коллеги, телефонный звонок и т. Д., И это легко забыл этот шаг. Я сделал это сам, используя другие базы данных ранее в моей карьере, и задался вопросом: «Да, почему я не вижу никаких данных из этого запроса?» Ответ был, что данные никогда не были восстановлены, и я просто потратил 2 часа на попытку выследить подозреваемые возможные ошибки, которых не было.)

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

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

Вот пример. В окне cmd:

C:\Program Files\PostgreSQL\9.2\bin>psql.exe -U postgres psql (9.2.4) Type "help" for help. postgres=# \ic:\temp\try1.sql c:: Permission denied postgres=# \ic:/temp/try1.sql CREATE TABLE postgres=#

Вы можете видеть, что это терпит неудачу, когда я использую «нормальные» косые черты окна в вызове \i . Однако оба стиля слэша работают, если вы передаете их как входные параметры psql.exe , например:

C:\Program Files\PostgreSQL\9.2\bin>psql.exe -U postgres -fc:\TEMP\try1.sql CREATE TABLE C:\Program Files\PostgreSQL\9.2\bin>psql.exe -U postgres -fc:/TEMP/try1.sql CREATE TABLE C:\Program Files\PostgreSQL\9.2\bin>

sql.fliplinux.com

Postgres дамп: инструменты pg_dump, pg_restore

PostgreSQL — реляционная система управления базами данных, в основе SQL и набор команд при работе с Postgres практически идентичен тому, что используется с MySQL. Для перемещения БД на другой сервер и создания бэкапов используется Postgres дамп.

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

В примерах ниже будет использоваться пользователь postgres

su — postgres

pg_dump DATABASE_NAME > dump.sql

Postgres дамп представляет собой .sql файл, который читабелен и может быть отредактирован после экспорта.

Флаги pg_dump, которые применяются чаще всего

-h — удаленный хост (ip адрес)

-p — пора на удаленном сервере, к которому нужно подключаться

-U — имя пользователя, имеющему достаточные права доступа для дампа базы данных

Команда с применением этих флагов будет выглядеть так:

pg_dump -h 123.123.123.123 -p 3434 -U dbadmin DATABASE_NAME > dump.sql

Восстановление из дампа можно выполнять за счет psql или pg_restore

В обоих случаях предварительно нужно убедиться в том, что база существует, при необходимости она создается так:

createdb -T template0 DATABASE_NAME

Восстановление из дампа

pg_restore -d DATABASE_NAME dump.sql

Если pg_restore передать ключ -C будет автоматически создана БД с указанным именем.

Другая команда для восстановления — psql

psql dbname < dumpfile

Бэкап Postgres

Утилита pg_dumpall позволяет быстро сделать дамп всех баз на сервере и сохранить их в один фйл

pg_dumpall > all.sql

Разворачивается такой дамп затем командой psql с ключем -f

psql -f all.sql postgres

Можно использовать перенаправления вывода и экспортировав дамп Postgres на одном сервере, загрузить его в базу на другом

pg_dump -h 123.123.123.123 DATABASE_NAME | psql -h 123.123.124.124 DATABASE_NAME

Читайте про создание дампов и их импорт для MySQL

server-gu.ru

Postgres Pro Standard : Документация: 9.6: 24.1. Выгрузка в SQL : Компания Postgres Professional

24.1. Выгрузка в SQL

Идея, стоящая за этим методом, заключается в генерации текстового файла с командами SQL, которые при выполнении на сервере пересоздадут базу данных в том же самом состоянии, в котором она была на момент выгрузки. Postgres Pro предоставляет для этой цели вспомогательную программу pg_dump. Простейшее применение этой программы выглядит так:

pg_dump имя_базы > файл_дампа

Как видите, pg_dump записывает результаты своей работы в устройство стандартного вывода. Далее будет рассмотрено, чем это может быть полезно. В то время как вышеупомянутая команда создаёт текстовый файл, pg_dump может создать файлы и в других форматах, которые допускают параллельную обработку и более гибкое управление восстановлением объектов.

Программа pg_dump является для Postgres Pro обычным клиентским приложением (хотя и весьма умным). Это означает, что вы можете выполнять процедуру резервного копирования с любого удалённого компьютера, если имеете доступ к нужной базе данных. Но помните, что pg_dump не использует для своей работы какие-то специальные привилегии. В частности, ей обычно требуется доступ на чтение всех таблиц, которые вы хотите выгрузить, так что для копирования всей базы данных практически всегда её нужно запускать с правами суперпользователя СУБД. (Если у вас нет достаточных прав для резервного копирования всей базы данных, вы, тем не менее, можете сделать резервную копию той части базы, доступ к которой у вас есть, используя такие параметры, как -n схема или -t таблица.)

Указать, к какому серверу должна подключаться программа pg_dump, можно с помощью аргументов командной строки -h сервер и -p порт. По умолчанию в качестве сервера выбирается localhost или значение, указанное в переменной окружения PGHOST. Подобным образом, по умолчанию используется порт, заданный в переменной окружения PGPORT, а если она не задана, то порт, указанный по умолчанию при компиляции. (Для удобства при компиляции сервера обычно устанавливается то же значение по умолчанию.)

Как и любое другое клиентское приложение Postgres Pro, pg_dump по умолчанию будет подключаться к базе данных с именем пользователя, совпадающим с именем текущего пользователя операционной системы. Чтобы переопределить имя, либо добавьте параметр -U, либо установите переменную окружения PGUSER. Помните, что pg_dump подключается к серверу через обычные механизмы проверки подлинности клиента (которые описываются в Главе 19).

Важное преимущество pg_dump в сравнении с другими методами резервного копирования, описанными далее, состоит в том, что вывод pg_dump обычно можно загрузить в более новые версии Postgres Pro, в то время как резервная копия на уровне файловой системы и непрерывное архивирование жёстко зависят от версии сервера. Также, только метод с применением pg_dump будет работать при переносе базы данных на другую машинную архитектуру, например, при переносе с 32-битной на 64-битную версию сервера.

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

24.1.1. Восстановление дампа

Текстовые файлы, созданные pg_dump, предназначаются для последующего чтения программой psql. Общий вид команды для восстановления дампа:

psql имя_базы < файл_дампа

где файл_дампа — это файл, содержащий вывод команды pg_dump. База данных, заданная параметром имя_базы, не будет создана данной командой, так что вы должны создать её сами из базы template0 перед запуском psql (например, с помощью команды createdb -T template0 имя_базы). Программа psql принимает параметры, указывающие сервер, к которому осуществляется подключение, и имя пользователя, подобно pg_dump. За дополнительными сведениями обратитесь к справке по psql. Дампы, выгруженные не в текстовом формате, восстанавливаются утилитой pg_restore.

Перед восстановлением SQL-дампа все пользователи, которые владели объектами или имели права на объекты в выгруженной базе данных, должны уже существовать. Если их нет, при восстановлении будут ошибки пересоздания объектов с изначальными владельцами и/или правами. (Иногда это желаемый результат, но обычно нет).

По умолчанию, если происходит ошибка SQL, программа psql продолжает выполнение. Если же запустить psql с установленной переменной ON_ERROR_STOP, это поведение поменяется и psql завершится с кодом 3 в случае возникновения ошибки SQL:

psql --set ON_ERROR_STOP=on имя_базы < файл_дампа

В любом случае, вы получите только частично восстановленную базу данных. В качестве альтернативы можно указать, что весь дамп должен быть восстановлен в одной транзакции, так что восстановление либо полностью выполнится, либо полностью отменится. Включить данный режим можно, передав psql аргумент -1 или --single-transaction. Выбирая этот режим, учтите, что даже незначительная ошибка может привести к откату восстановления, которое могло продолжаться несколько часов. Однако, это всё же может быть предпочтительней, чем вручную вычищать сложную базу данных после частично восстановленного дампа.

Благодаря способности pg_dump и psql писать и читать каналы ввода/вывода, можно скопировать базу данных непосредственно с одного сервера на другой, например:

pg_dump -h host1 имя_базы | psql -h host2 имя_базы

Важно

Дампы, которые выдаёт pg_dump, содержат определения относительно template0. Это означает, что любые языки, процедуры и т. п., добавленные в базу через template1, pg_dump также выгрузит в дамп. Как следствие, если при восстановлении вы используете модифицированный template1, вы должны создать пустую базу данных из template0, как показано в примере выше.

После восстановления резервной копии имеет смысл запустить ANALYZE для каждой базы данных, чтобы оптимизатор запросов получил полезную статистику; за подробностями обратитесь к Подразделу 23.1.3 и Подразделу 23.1.6. Другие советы по эффективной загрузке больших объёмов данных в Postgres Pro вы можете найти в Разделе 14.4.

24.1.2. Использование pg_dumpall

Программа pg_dump выгружает только одну базу данных в один момент времени и не включает в дамп информацию о ролях и табличных пространствах (так как это информация уровня кластера, а не самой базы данных). Для удобства создания дампа всего содержимого кластера баз данных предоставляется программа pg_dumpall, которая делает резервную копию всех баз данных кластера, а также сохраняет данные уровня кластера, такие как роли и определения табличных пространств. Простое использование этой команды:

pg_dumpall > файл_дампа

Полученную копию можно восстановить с помощью psql:

psql -f файл_дампа postgres

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

pg_dumpall выдаёт команды, которые заново создают роли, табличные пространства и пустые базы данных, а затем вызывает для каждой базы pg_dump. Таким образом, хотя каждая база данных будет внутренне согласованной, состояние разных баз не будет синхронным.

Только глобальные данные кластера можно выгрузить, передав pg_dumpall ключ --globals-only. Это необходимо, чтобы полностью скопировать кластер, когда pg_dump выполняется для отдельных баз данных.

24.1.3. Управление большими базами данных

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

Используйте сжатые дампы. Вы можете использовать предпочитаемую программу сжатия, например gzip:

pg_dump имя_базы | gzip > имя_файла.gz

Затем загрузить сжатый дамп можно командой:

gunzip -c имя_файла.gz | psql имя_базы

или:

cat имя_файла.gz | gunzip | psql имя_базы

Используйте split. Команда split может разбивать выводимые данные на небольшие файлы, размер которых удовлетворяет ограничению нижележащей файловой системы. Например, чтобы получить части по 1 мегабайту:

pg_dump имя_базы | split -b 1m - имя_файла

Восстановить их можно так:

cat имя_файла* | psql имя_базы

Используйте специальный формат дампа pg_dump. Если при сборке Postgres Pro была подключена библиотека zlib, дамп в специальном формате будет записываться в файл в сжатом виде. В таком формате размер файла дампа будет близок к размеру, полученному с применением gzip, но он лучше тем, что позволяет восстанавливать таблицы выборочно. Следующая команда выгружает базу данных в специальном формате:

pg_dump -Fc имя_базы > имя_файла

Дамп в специальном формате не является скриптом для psql и должен восстанавливаться с помощью команды pg_restore, например:

pg_restore -d имя_базы имя_файла

За подробностями обратитесь к справке по командам pg_dump и pg_restore.

Для очень больших баз данных может понадобиться сочетать split с одним из двух других методов.

Используйте возможность параллельной выгрузки в pg_dump. Чтобы ускорить выгрузку большой БД, вы можете использовать режим параллельной выгрузки в pg_dump. При этом одновременно будут выгружаться несколько таблиц. Управлять числом параллельных заданий позволяет параметр -j. Параллельная выгрузка поддерживается только для формата архива в каталоге.

pg_dump -j число -F d -f выходной_каталог имя_базы

Вы также можете восстановить копию в параллельном режиме с помощью pg_restore -j. Это поддерживается для любого архива в формате каталога или специальном формате, даже если архив создавался не командой pg_dump -j.

postgrespro.ru

Как восстановить файл дампа PostgreSQL в базы данных Postgres?

У меня есть файл дампа с .SQL расширение (на самом деле это текстовый файл SQL). Я хочу восстановить его в мои созданные базы данных. я использую pgAdmin III , и когда я использую его «Мастер восстановления», он не выделяет кнопку «Восстановить». Вместо этого он ожидает .backup расширение файла.

Я попробовал использовать shell команды для восстановления дампа, но он все еще не работал.

Я новичок в этом. Если бы кто-нибудь мог мне помочь, я был бы обязан.

редактировать

Я использовал следующую команду для панели SQL Shell PostGres, сидя в newTestDB.

newTestDB-# \i E:\db-rbl-restore-20120511_Dump-20120514.sql

Он по-прежнему выдавал ту же ошибку («Permission Denied»).

После повышения разрешений он просто показывает мне таблицы по умолчанию PostgreSQL:

Я не знаю, что делать для импорта / восстановления базы данных из файла SQL.

2018-05-25 20:39

источник

Ответы:

Вы не указали, как была сделана ваша резервная копия, поэтому общий ответ: Обычно с psql инструмент.

В зависимости от того, что pg_dump было дано дамп, файл SQL может иметь разные наборы команд SQL. Например, если вы проинструктируете pg_dump сбросить базу данных, используя --clean а также --schema-only, вы не можете ожидать, что сможете восстановить базу данных из этого дампа, так как для COPYing не будет команд SQL (или INSERTing if --inserts используется) фактические данные в таблицах. Такой дамп будет содержать только команды DDL SQL и сможет воссоздать схему, но не фактические данные.

Типичный SQL-дамп восстанавливается с помощью psql:

psql (connection options here) database < yourbackup.sql

или, альтернативно, из psql сессия,

psql (connection options here) database database=# \i /path/to/yourbackup.sql

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

Если вы работаете над unix-подобным, попробуйте следующее:

man psql man pg_dump man pg_restore

в противном случае взгляните на html-документы , Удачи!

2018-05-25 20:46

Проблема с вашей попыткой psql Командная строка - это направление косой черты:

newTestDB-# /i E:\db-rbl-restore-20120511_Dump-20120514.sql # incorrect newTestDB-# \i E:/db-rbl-restore-20120511_Dump-20120514.sql # correct

Чтобы быть ясным, psql команды начинаются с обратного слэша, поэтому вы должны \i вместо. Что произошло в результате вашей опечатки, так это то, что psql игнорировали все, пока не нашли первый \, за которым последовали db, а также \db оказывается, psql команда для распечатки табличные пространства , поэтому выход был Список табличных пространств , Это был не список «таблиц по умолчанию PostgreSQL», как вы сказали.

Кроме того, кажется, что psql ожидает filepath аргумент, чтобы разграничить каталоги с помощью косой черты, независимо от ОС (при этом в Windows это было бы интуитивно понятным).

Наконец, расширение файла дампа не имеет значения, на самом деле вам даже не требуется расширение. В самом деле, pgAdminпредлагает .backup при выборе имени файла резервной копии, но вы действительно можете сделать все, что захотите, опять же, включая отсутствие расширения вообще. Проблема в том, что pgAdmin похоже, разрешает «восстановление» дампов «Custom или tar» или «Directory» (по крайней мере, это относится к версии приложения MAC OS X), поэтому просто используйте psql \i как показано выше.

2018-05-10 18:23

Используя pg_restore команды вы можете восстановить базу данных postgres

Первый открытый тип терминала

sudo su postgres

Создать новую базу данных

createdb [имя базы данных] -O [владелец]

createdb test_db [-O openerp]

pg_restore -d [Имя базы данных] [путь к файлу дампа]

pg_restore -d test_db /home/sagar/Download/sample_dbump

Подождите завершения восстановления базы данных.

2017-11-18 12:35

1.Откройте терминал.

2.Нажмите свою базу данных следующей командой

ваш postgres bin - /opt/PostgreSQL/9.1/bin/

ваш исходный сервер базы данных - 192.168.1.111

местоположение и имя файла резервной копии - /home/dinesh/db/mydb.backup

имя источника db - mydatabase

/opt/PostgreSQL/9.1/bin/pg_dump --host '192.168.1.111' --порт 5432 - имя пользователя "postgres" --no-password --format custom --blobs -file "/ home / dinesh / db /mydb.backup "" mydatabase "

3. восстановить файл mydb.backup в пункт назначения.

ваш целевой сервер - localhost

имя вашей целевой базы данных - mydatabase

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

/opt/PostgreSQL/9.1/bin/psql -h 'localhost' -p 5432 -U postgres -c "CREATE DATABASE mydatabase"

восстановить резервную копию.

/opt/PostgreSQL/9.1/bin/pg_restore --host 'localhost' --port 5432 --username "postgres" --dbname "mydatabase" --no-password --clean "/ home / dinesh / db / mydb. резервное копирование"

2017-10-11 06:19

Объединив совет от MartinP и user664833, я также смог заставить его работать. Caveat - это ввод psql из инструмента GUI pgAdmin с помощью выбора плагинов ... Консоль PSQL устанавливает учетные данные и уровень разрешений для сеанса psql, поэтому у вас должны быть разрешения администратора или CRUD в таблице и, возможно, также администратор в базе данных (не точно знать об этом). Затем команда в консоли psql примет следующую форму:

postgres=# \i driveletter:/folder_path/backupfilename.backup

где Postgres = # это подсказка psql, а не часть команды.

Файл .backup будет включать команды, используемые для создания таблицы, поэтому вы можете также получить команды типа «ALTER TABLE ...» в файле, который выполняется, но сообщается как ошибки. Я полагаю, вы всегда можете удалить эти команды перед запуском восстановления, но вы, вероятно, лучше безопасны, чем жаль, чтобы держать их там, так как это вряд ли приведет к сбою восстановления данных. Но всегда проверяйте, чтобы данные, которые вы хотели получить, действительно попали туда. (Извините, если это похоже на покровительствовать кому-либо, но это надзор, который может случиться с кем угодно, независимо от того, как долго они были на этом занятии - отвлечение внимания от коллеги, телефонный звонок и т. Д., И это легко забыл этот шаг. Я сделал это сам, используя другие базы данных ранее в моей карьере, и задался вопросом: «Да, почему я не вижу никаких данных из этого запроса?» Ответ был, что данные никогда не были восстановлены, и я просто потратил 2 часа на попытку выследить подозреваемые возможные ошибки, которых не было.)

2018-03-10 15:53

2017-07-29 22:21

Вот пример. В окне cmd:

C:\Program Files\PostgreSQL\9.2\bin>psql.exe -U postgres psql (9.2.4) Type "help" for help. postgres=# \i c:\temp\try1.sql c:: Permission denied postgres=# \i c:/temp/try1.sql CREATE TABLE postgres=#

Вы можете видеть, что это терпит неудачу, когда я использую «нормальные» косые черты окна в \i вызов. Однако и то и другое стили слэша работают, если вы передаете их в качестве входных параметров для psql.exe, например:

C:\Program Files\PostgreSQL\9.2\bin>psql.exe -U postgres -f c:\TEMP\try1.sql CREATE TABLE C:\Program Files\PostgreSQL\9.2\bin>psql.exe -U postgres -f c:/TEMP/try1.sql CREATE TABLE C:\Program Files\PostgreSQL\9.2\bin>

2018-05-14 18:10

programmerz.ru

postgresql - Как восстановить одну таблицу из резервной копии .sql postgresql?

Не делайте резервных копий SQL, если вам нужно восстановление одной таблицы и т. Д. Используйте параметр -Fc pg_dump - «пользовательский» формат. Это можно восстановить с помощью pg_restore . Выборочное восстановление возможно, как и всевозможные другие удобные функции. pg_restore может преобразовать дамп пользовательского формата в дамп SQL позже, если вам это нужно.

Если вы застряли в существующем дампе, ваши единственные варианты:

Используйте текстовый редактор, чтобы извлечь данные целевой таблицы в отдельный файл и просто восстановить это; или
Восстановите дамп в базу данных с выбросом, а затем используйте pg_dump для pg_dump выборочного дампа, включая только эту таблицу. Так как это одноразово, вы можете использовать отдельный экземпляр Pg на какой-то незагруженной машине с быстрым, но небезопасным, где вы включаете все «быстро, но едите мои данные, если хотите», такие как fsync=off . Вы НИКОГДА не должны устанавливать это в процессе производства.

Вы можете использовать grep + sed в roder для получения данных таблицы:

Во-первых, вам нужно определить границы:

$ fgrep -Ehn '^(COPY |CREATE TABLE )' db.sql 49:CREATE TABLE test ( 60:CREATE TABLE test2 ( 71:CREATE TABLE test3 ( 82:COPY test (i) FROM stdin; 100090:COPY test2 (i) FROM stdin; 200098:COPY test3 (i) FROM stdin;

Чтобы извлечь данные для таблицы test2:

sed -n '100090,200097p' < db.sql | sed -e 's/^COPY test2/COPY new_table_name/' > new_table_name.sql

Обратите внимание, вам нужно вычесть один из второго числа (т. Е. Исключить следующую копию stmt)

Теперь вы можете загрузить new_table_name.sql и восстановить данные, которые вам нужны. Теперь вы можете загружать данные в новую таблицу

У меня pg_dumpall свалка pg_dumpall . И я хотел бы восстановить таблицу с именем users из базы данных с именем edc , так как вы, скорее всего, будете иметь одинаково названные таблицы в разных базах данных и даже схемах.

Для моего случая работает следующий sed oneliner:

sed -ne '/^\\connect edc/,/^\\connect/{/\susers$\s\|$$/,/;\|\\\./p}' pg92.dump

Что оно делает:

/^\\connect edc/,/^\\connect/ ограничивает поиск как область моей базы данных;
{…} будет выполнять все внутренние команды для диапазона;
/\susers$\s\|$$/ соответствует всем строкам с собственными пользователями, в том числе в конце с

code-examples.net

database - Невозможно восстановить базу данных PostgreSQL из дампа

Мой компьютер запускает Ubuntu 14.04 с postgreSQL 9.3

Я хотел бы восстановить большую базу данных PSQL с именем bigdb на моем компьютере из файла дампа (размер файла дампа = 2,3 ГБ).

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

Я создал пустую базу данных, называемую testdb, в которой я хотел бы "написать" bigdb

Я попробовал команду:

$pg_restore -C -d testdb dump.dmp

Это дало мне около 300 ошибок такого типа:

pg_restore: [archiver (db)] Ошибка записи TOC 15475; 0 25342 TABLE DATA tb_italmaj jturf pg_restore: [archiver (db)] не удалось выполнить запрос: ERROR: отношение "tb_italmaj" не существует. Команда была: COPY tb_italmaj (id_mvtmaj, имя_файла, file_dh, pgdone, pgdonedh, pgfonctrue, pgerrcode, pgerrmess, pgrowdata) FROM stdin;

В конце testdb все еще пуст. Кажется, что testdb должен иметь ту же "структуру" (таблицы,...), что и bigdb, но я думал, что параметр "-C" создаст базу данных.

Я также попытался извлечь дамп в файл txt txt txt. Я попытался восстановить его с помощью команды:

$psql -v ON_ERROR_STOP=1 testdb < dump.sql

Эта ошибка появилась сразу:

ERROR: отношения "id_tab_eed__texte_seq" не существует

Также кажется, что отношения с bigdb необходимо создать, прежде чем восстанавливать его, и я не могу этого сделать.

Единственной командой, которая выполнялась правильно, была:

$pg_restore -C dump.dmp

Но в этом случае база данных не была создана на моем компьютере.

Я боролся с этой проблемой в течение нескольких часов. Кто-нибудь может мне помочь?

Заранее спасибо.

PS: Это мой первый пост, и я не являюсь носителем английского языка, я надеюсь, что я был чист. Если нет, не стесняйтесь спрашивать дополнительную информацию.

qaru.site