Как сделать резервную копию баз данных PostgreSQL на Ubuntu? Восстановление базы postgresql

Восстановление базы данных Postgresql | Информационный портал К2®

Автор: Рудюк С . А.https://corp2.netE-Mail: [email protected]

Любая база данных выходит из строя… Пользователи забывают делать бекапы и как результат, программистам приходится возиться с восстановлением данных.Ранее, я не однократно описывал восстановление баз данных Firebird (Interbase), но уже давно работаю с другими базами данных, поэтому, сталкиваюсь с «новыми задачами» по восстановлению информации.

Сегодня, ко мне обратился один старый клиент, у которого много лет работает база данных на Postgresql со вчерашнего дня у них стали выдаваться ошибки Page Error при входе в систему. Как результат — не возможность работы.Зашел в PgAdmin, попробывал сделать бекап — вывались ошибки. Начал «передвигаться» по списку баз данных — вываливается огромное количество ошибок Page Error. Решили восстановить из бекапа. Как оказалось, последний бекап — за декабрь 2013 года. Пол-года пропало!И тут меня осенило! Решил попробывать выполнить select. Проходит успешно, данные показывает без ошибки.Ура! Подумал я себе.

Итак, как мне удалось восстановить базу без потери информации:1. Создаю новую базу данных (с другим названием) из найденного бекапа (в данном случае, декабрь 2013г.). Проверяю входить в систему — всё отлично.2. Сохраняю данные из каждой интересующей меня таблицы, подобными запросами:copy (select * from zrp_zakaz ) to ‘d:\tmp\zrp_zakaz’;3. Удаляю данные из необходимых таблиц в базе данных, которую восстановили. Например:delete from zrp_zakaz;4. Закачиваю данные из сохраненного файла в другой базе данных. Например:copy zrp_zakaz from ‘d:\tmp\zrp_zakaz’;

Как результат — база восстановилась полностью, без потери данных.Клиент счастлив, чего и следовало добиться…

Автор: Рудюк С . А. https://corp2.net

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)

corp2.info

Как создать дамп и выполнить восстановление в службе "База данных Azure для PostgreSQL"

09/22/2018
Время чтения: 6 мин
Соавторы

Можно извлечь базу данных PostgreSQL в файл дампа с помощью pg_dump и с помощью pg_restore восстановить базу данных PostgreSQL из файла архива, созданного pg_dump.You can use pg_dump to extract a PostgreSQL database into a dump file and pg_restore to restore the PostgreSQL database from an archive file created by pg_dump.

Предварительные требованияPrerequisites

Прежде чем приступить к выполнению этого руководства, необходимы следующие компоненты:To step through this how-to guide, you need:

Выполните указанные ниже действия, чтобы создать дамп базы данных PostgreSQL и восстановить ее.Follow these steps to dump and restore your PostgreSQL database:

Создание файла дампа, содержащего загружаемые данные, с помощью pg_dumpCreate a dump file using pg_dump that contains the data to be loaded

Чтобы создать резервную копию базы данных PostgreSQL локально или на виртуальной машине, выполните следующую команду:To back up an existing PostgreSQL database on-premises or in a VM, run the following command:

pg_dump -Fc -v --host=<host> --username=<name> --dbname=<database name> > <database>.dump

Например, если имеется локальный сервер с базой данных testdb.For example, if you have a local server and a database called testdb in it

pg_dump -Fc -v --host=localhost --username=masterlogin --dbname=testdb > testdb.dump

Восстановление данных в целевую базу данных Azure для PostrgeSQL с помощью pg_restoreRestore the data into the target Azure Database for PostrgeSQL using pg_restore

После создания целевой базы данных можно воспользоваться командой pg_restore с параметром -d, --dbname, чтобы восстановить данные в целевую базу данных из файла дампа.After you've created the target database, you can use the pg_restore command and the -d, --dbname parameter to restore the data into the target database from the dump file.

pg_restore -v --no-owner –-host=<server name> --port=<port> --username=<user@servername> --dbname=<target database name> <database>.dump

Если включить параметр --no-owner, все объекты, созданные во время восстановления, будут присвоены пользователю --username.Including the --no-owner parameter causes all objects created during the restore to be owned by the user specified with --username. Дополнительные сведения см. в официальной документации PostgreSQL по pg_restore.For more information, see the official PostgreSQL documentation on pg_restore.

Примечание

Если серверу PostgreSQL требуются SSL-подключения (используется по умолчанию на серверах службы "База данных Azure для PostgreSQL"), задайте переменную среды PGSSLMODE=require, чтобы средство pg_restore подключалось через протокол SSL.If your PostgreSQL server requires SSL connections (on by default in Azure Database for PostgreSQL servers), set an environment variable PGSSLMODE=require so that the pg_restore tool connects with SSL. Без протокола SSL может отобразиться такая ошибка: FATAL: SSL connection is required. Please specify SSL options and retry.Without SSL, the error may read FATAL: SSL connection is required. Please specify SSL options and retry.

В командной строке Windows выполните команду SET PGSSLMODE=require перед выполнением команды pg_restore.In the Windows command line, run the command SET PGSSLMODE=require before running the pg_restore command. В Linux или Bash выполните команду export PGSSLMODE=require перед выполнением команды pg_restore.In Linux or Bash run the command export PGSSLMODE=require before running the pg_restore command.

В этом примере восстановите данные из файла дампа testdb.dump в базу данных mypgsqldb на целевом сервере mydemoserver.postgres.database.azure.com.In this example, restore the data from the dump file testdb.dump into the database mypgsqldb on target server mydemoserver.postgres.database.azure.com.

pg_restore -v --no-owner --host=mydemoserver.postgres.database.azure.com --port=5432 --username=mylogin@mydemoserver --dbname=mypgsqldb testdb.dump

Оптимизация процесса миграцииOptimizing the migration process

Один из способов миграции существующей базы данных PostgreSQL в службу "База данных Azure для PostgreSQL" — это резервное копирование базы данных в источнике и ее восстановление в Azure.One way to migrate your existing PostgreSQL database to Azure Database for PostgreSQL service is to back up the database on the source and restore it in Azure. Чтобы свести к минимуму время, необходимое для завершения миграции, можно использовать следующие параметры с командами резервного копирования и восстановления.To minimize the time required to complete the migration, consider using the following parameters with the backup and restore commands.

Примечание

Подробные сведения о синтаксисе см. в статьях о pg_dump и pg_restore.For detailed syntax information, see the articles pg_dump and pg_restore.

Для резервного копированияFor the backup

Создайте резервную копию с использованием параметра -Fc, чтобы вы могли выполнять восстановление параллельно, что позволит ускорить его.Take the backup with the -Fc switch so that you can perform the restore in parallel to speed it up. Например: For example:
pg_dump -h MySourceServerName -U MySourceUserName -Fc -d MySourceDatabaseName > Z:\Data\Backups\MyDatabaseBackup.dump

Для восстановленияFor the restore

Мы предлагаем переместить файл резервной копии на виртуальную машину Azure в том же регионе, где находится сервер Базы данных Azure для PostgreSQL, на который перемещается база данных, и выполнить команду pg_restore с этой виртуальной машины, чтобы уменьшить задержку сети.We suggest that you move the backup file to an Azure VM in the same region as the Azure Database for PostgreSQL server you are migrating to, and do the pg_restore from that VM to reduce network latency. Мы также рекомендуем, чтобы виртуальная машина была создана с функцией ускорения работы в сети.We also recommend that the VM is created with accelerated networking enabled.

Это должно происходить по умолчанию, но откройте файл дампа, чтобы проверить, что инструкции создания индекса находятся после вставленных данных.It should be already done by default, but open the dump file to verify that the create index statements are after the insert of the data. Если это не так, переместите инструкции создания индекса после вставленных данных.If it isn't the case, move the create index statements after the data is inserted.
Выполните восстановление с параметрами -Fc и -j # для параллельной операции.Restore with the switches -Fc and -j # to parallelize the restore. # — это количество ядер на целевом сервере.# is the number of cores on the target server. Вы также можете попробовать установить вдвое большее количество ядер целевого сервера, используя #, чтобы оценить влияние.You can also try with # set to twice the number of cores of the target server to see the impact. Например: For example:

pg_restore -h MyTargetServer.postgres.database.azure.com -U MyAzurePostgreSQLUserName -Fc -j 4 -d MyTargetDatabase Z:\Data\Backups\MyDatabaseBackup.dump
Можно также изменить файл дампа, добавив команду set synchronous_commit = off; в начале и команду set synchronous_commit = on; в конце.You can also edit the dump file by adding the command set synchronous_commit = off; at the beginning and the command set synchronous_commit = on; at the end. Если не включить ее в конце, прежде чем приложения изменят данные, это может привести к последующей потере данных.Not turning it on at the end, before the apps change the data, may result in subsequent loss of data.

Не забудьте проверить и протестировать эти команды в тестовой среде, прежде чем использовать их в рабочей среде.Remember to test and validate these commands in a test environment before you use them in production.

Дополнительная информацияNext steps

docs.microsoft.com

Как сделать резервную копию баз данных PostgreSQL на Ubuntu?

Все админы делятся на 2 категории

— те которые уже делают бэкап

и те которые ещё не делают.

Что такое PostgreSQL?

PostgreSQL является современной системой управления базами данных, часто используемая для хранения и обработки информации, связанной с веб-сайтами или сторонними приложениями. У любой базы данных, важно вовремя реализовать резервное копирование, чтобы избежать возможную потерю данных.

В этом посте я постараюсь рассказать о некоторых способах, которыми вы можете сделать резервную копию PostgreSQL. Для тестов будем использовать Ubuntu 12,04 VPS с PostgreSQL 9.1. Для большинства современных дистрибутивов и последних версии PostgreSQL мои советы будут актуальны.

Создание резервной копии PostgreSQL при помощи pg_dump

PostgreSQL включает в себя утилиту под названием «pg_dump», которая позволяет сделать дамп базы данных в файл. Утилита консольная, синтаксис достаточно простой:

pg_dump name_of_database > name_of_backup_file

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

Как вариант мы можем войти через sudo под пользователем «рostgres» и выполнить команду:

sudo su - postgres pg_dump postgres > postgres_db.bak

«pg_dump» — это «полноценный» клиент PostgreSQL, т.е. при необходимости её можно запустить с удаленной машины, если имеются соответствующие разрешения к базе данных.

Расширенный синтаксис выглядит следующим образом:

pg_dump -h remote_host -p remote_port name_of_database > name_of_backup_file pg_dump -U user_name -h remote_host -p remote_port name_of_database > name_of_backup_file

Как восстановить дампы pg_dump в PostgreSQL

Чтобы восстановить резервную копию, созданную pg_dump, необходимо перенаправить файл с дампом в стандартный ввод psql:

psql empty_database < backup_file

Эта операция не создает новую базу данных. Об этом необходимо позаботиться заранее.

Для примера, создадим новую базу данных под названием «restored_database», а затем развернем дамп под названием «database.bak»:

createdb -T template0 restored_database psql restored_database < database.bak

Пустая база данных должна быть создана при помощи шаблона «template0«. Так же нам необходимо убедиться в наличии пользователя с необходимыми правами на создаваемую базу, в противном случае нам придется создать нового:

createuser test_user psql restored_database < database.bak

Возможные ошибки

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

psql --set ON_ERROR_STOP=on restored_database < backup_file

С данной опцией мы получим частично восстановленную базу данных.

Можно попробовать восстановить весь дамп в одну транзацию, т.е. бекап будет или полностью восстановлен или не восстановлен совсем. Данный режим может быть задан, с помощью опций -1 или —single-transaction для psql.

psql -1 restored_database < backup_file

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

Резервное копирование и восстановление всех баз данных в PostgreSQL

Чтобы сэкономить время, можно сделать резервную копию всех баз данных в вашей системе, при помощи утилиты «pg_dumpall»:

pg_dumpall > backup_file

Похожим способом можно восстановить базы данных:

psql -f backup_file postgres

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

В качестве дополнения скрипт, который создает резервную копию с меткой времени и сохраняет последние 14 резервных копий:

ls -t *.sql | sed -e '1,13d' | xargs -d '\n' rm echo Done at `date +\%Y-\%m-\%d_\%T` pg_dump dbname --username=dbuser > `date +\%Y-\%m-\%d_\%T`.sql

Вы можете оставить комментарий ниже.

shurshun.ru

Восстановление базы Postgres, без дампа

Не так давно я пересел с линукса (Debian) на Microsoft (Windows 7), не спрашивайте зачем, так уж получилось на чу-чуть, потом пересяду обратно, вот, и там мне надо было установить БД PostgreSQL 8.3. Как положено скачал, установил, создал и начал работать, но в один прекрасный утренний день включаю ПК, а там фатал эррор и на те черный экран, ну, я думаю понятное дело windows :) Включаю открываю свой любимый IDE начинаю компилировать - connection refused... Что за дела думаю, может сервер не завелся захожу в службы включаю Posgres server.. НЕТ, и я тут буквально вскипел, проект горит, дампа нету, ничего, не смертельно захожу в каталог вижу папку data, все ОК)

Ну и-с начнем, по умолчанию инсталяционный пакет базы устанавливается в каталог C:\Program Files\PostgreSQL 8.3 , если заглянем внутрь увидим для нас ценную папку data . Что там находиться, перечислю основные папки и файлы:1. папка base - в нем базы хранятся в зашифрованном виде, если откроем его то увидим папки с числовыми названиями как, 50034, 11510, 1, и т.д. их не надо трогать, а то небось попортите.2. папка global - тут уже интереснее, в нем мы можем открыть файл pg_database, что он из себя представляет:

"template1" 1 1663 379"template0" 11510 1663 379"postgres" 11511 1663 379"test1" 16384 1663 379"test2" 20319 1663 379

первый блок название базы, второй блог его OID (он соответствует с названиями папок в каталоге base ), третий блок шаблон не знаю (возможно id owner) и т.д, не суть важно, главное второй блок.Файл pg_auth - тут хранятся пароли для доступа с md5 шифрованием.

И самое главное при переносе папок в другой каталог PostgreSQL разных версии надо учитывать права доступа папок, при установке базы в ОС windows он создает учетную запись с название postgres, и права доступа папок устанавливает под именем postgres.

P.S Если после все операции служба не запускается попробуйте следующее:Найдите в списке служб PostgreSQL 8.3 (версии могут отличатся, у меня 8.3 версия)Свойство->Вход в Систему->С системной учетной записью, для начало пользователя postgres надо добавить в группу Администраторы, быстрее это делается через команду lusrmgr.msc (Run -> lusrmgr.msc), перезагрузка системы и должно получиться (надеюсь).

Совет: Делайте почаще резервные копии базы, или создайте автобэкап!

snavruzov.blogspot.com

Иллюстрированный самоучитель по PostgreSQL › Управление базами данных › Восстановление базы данных [страница - 225] | Самоучители по программированию

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

Существует два способа восстановления базы данных из архива. Если архив представляет собой простой текстовый файл, его можно передать psql в качестве вход ного файла. Если же был выбран другой формат архива (.tar или.tar.gz), следует использовать приложение pg_restore.

При восстановлении данные либо заносятся в пустую базу данных, либо баз данных специально создается. Выбор зависит в основном от способа архивации (то есть от того, содержит ли архив только данные или же в него были включен! команды создания базы данных).

Использование psql при восстановлении простых текстовых архивов

Простой текстовый файл, созданный приложением pg_dump, можно передать psc в качестве входного файла. При этом будут последовательно выполнены все инструкции SQL, хранящиеся в архиве. В зависимости от режима архивации существует несколько вариантов вызова psql.

Если архив создавался с ключом – С, команда SQL для создания базы данных присутствует в файле архива. Это означает, что база данных скорее всего либо была удалена, либо еще не создана в той системе, в которой она восстанавливается. Если база данных уже существует, возможно, ее придется удалить – но только в том случае, если вы твердо убеждены в актуальности данных архива.

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

В листинге 9.23 продемонстрировано восстановление базы данных booktown is файла booktown.sql, созданного в листинге 9.20 (см. подраздел "Приложение ig_dump"). Поскольку в этом примере использовался флаг – С, заранее создавать базу данных не нужно; достаточно подключиться к базе данных templatel.

Листинг 9.23. Восстановление базы данных.

booktown jworsley@booktown – ]$ psql – U manager – f booktown.sql templatel REATE DATABASE You are now connected to database booktown as user postgres. 3MMENT REATE REATE HANGE […]

По мере выполнения команд файла booktown.sql в stderr выводятся сообщения ервера (CREATE, CHANGE и т. д.).

ПримечаниеБлагодаря возможности удаленного вызова psql восстановление может проводиться по сети. Для гого на авторизованном хосте должны быть указаны правильные параметры подключения.

Использование pg_restore при восстановлении архивов в форматах .tar и .tar.gz

Если файл был создан программой pg_dump в формате, отличном от простого текста, его можно восстановить из архива .tar или .tar.gz при помощи утилиты pg__restore.

Синтаксис команды pg_restore:

pg_restore [ параметры ] [ файл ]

Если файл не задан, pg_restore ожидает поступления данных из потока stdin, следовательно, при вызове pg_restore могут использоваться средства перенаправления ввода (<). Среди параметров особого внимания заслуживает ключ – d. Если ч не задан, pg_restore вместо восстановления базы данных просто выводит ко-аиды в поток stdout (то есть на экран).

При использовании ключа создания базы данных – С все равно необходимо задать ключ – d с именем существующей базы данных для подключения. Неважно, к какой базе данных вы при этом подключаетесь, это всего лишь временное подключение до момента создания новой базы данных.

samoychiteli.ru

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

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

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

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

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

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

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

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

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

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

25.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 для каждой базы данных, чтобы оптимизатор запросов получил полезную статистику; за подробностями обратитесь к Подразделу 24.1.3 и Подразделу 24.1.6. Другие советы по эффективной загрузке больших объёмов данных в PostgreSQL вы можете найти в Разделе 14.4.

25.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 выполняется для отдельных баз данных.

25.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. Если при сборке PostgreSQL была подключена библиотека 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

Помогите восстановить базу postgres

Вопрос: Помогите восстановить БАЗУ в рабочее состояние

Здравствуйте.

О себе... Опыта работы в части администрирования DB2 нет.управление производилось в основном через центр управления.Заранее прошу сделайте, пожалуйста, скидку за терминологию и интелект. Попытки решить проблему изучая материалы форума и мат. часть в течении нескольких дней к желаемому результату не привели! Хорошо выходные - база не использовалась, а характер работы позволял день-два в режиме информационного простоя

О ПРОБЛЕМЕ После ошибки работы сервера, служба DB2 останавливается после загрузки OS и любого обращения к менеджеру базы данных

в логах сервера WinServ2003 имеется регулярные сообщения от DB2 express 9.1

ADM7513W Запущен менеджер баз данных.db2start : SQL1063N Загрузка менеджера баз данных успешно завершена.ADM1530E Началось аварийное восстановление.DM1531E Аварийное восстановление завершено успешно.

имеется резервная копия в F:\DB2BackUP\DB2TRADE.0.DB2.NODE0000.CATN0000.20141123231702.001а в папке E:\db2log\001tradeкак я думаю журналы транзакцийS0000000.LOG .... S0000031.LOG SQLLPATH.TAG

ВОПРОСЫ1 Возможность восстановления работоспособности текущей базы2 Возможность восстановление базы из резервной копии на другом сервере (подготовлен с установленным той же версии экземпляром DB23 Какой вариант выглядит наиболее приемлемым по вероятности решения и с меньшими временными затратами (размер базы более 100 Гб, время выполнения бэкапа на старом железе около 1часа )

после выполнения db2diag -Adb2gcf -u -L

прилагаю db2diag.log отредактированный в части повторяющейся бесконечно заключительных строк:

2014-12-09-15.48.06.421000+360 I12980h416 LEVEL: ErrorPID : 2116 TID : 2288 PROC : rphost.exeINSTANCE: DB2 NODE : 000FUNCTION: DB2 UDB, common communication, sqlcctcpconnr, probe:110MESSAGE : DIA3202C The TCP/IP call "connect" returned an errno="10061".

Очень надеюсь на Вашу помощьЗаранее спасибо!

Ответ: Mark Barinstein,

На старом сервере удалил из файловой системы базуСлужба db2 перестала останавливатьсяудалил базу из экземпляра (Drop), создал новую стандартную с тем же именемВ центре управления через мастер восстановления операция восстановления прошла успешно

Единственно не получилось накатить транзакции т.к. не задал все парметры

ВОПРОС Есть информация какие табличные пространства для 1С нужно восстанавливать

forundex.ru