ГлавнаяРазноеPostgresql восстановление базы из backup

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


Восстановление postgresql базы 1с из бэкапа

Восстановить базу postgresql из бэкапа можно двумя способами:

1. Если у вас имеется выгрузка БД (базы данных) из конфигуратора, файл с разрешением *dt (как делать выгрузку БД средствами 1С я писал в этой статье), то необходимо просто загрузить базу из этого файла.

2. Загрузка БД с помощью инструментов pgAdmin (актуально при наличии выгрузки с помощью этого инструмента, как делать выгрузку читайте тут):

Заходим в pgAdmin (в примере используется pgAdmin III версии 1.21.1) под пользователем, указанном при установке PostgreSQL как суперюзер, указываем пароль, переходим в браузер объектов.

Далее выделяем нужную нам БД, запоминаем значения свойств (кодировку, тип символа и самое главное — название базы) и удаляем базу данных.

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

После создания базы данных, выбираем ее правой кнопкой мыши, нажимаем «Восстановить», указываем путь к файлу с копией вашей БД и нажимаем «ОК».

Процедура длительная, в зависимости от конфигурации вашего сервера и размера базы данных, так что можете посвятить себя какой-то альтернативной задаче на 30-40 минут точно).По завершению появится сообщение «Процесс вернул код выхода 0», нажимайте «ОК» и пробуйте запускать вашу базу данных в 1С.

Если вы все сделали правильно, то база запустится.

jcover.ru

Как восстановить базу данных PostgreSQL из архива | Info-Comp.ru

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

Чуть ранее мы с Вами рассмотрели возможность создания резервной копии базы данных PostgreSQL в материале Как создать архив базы PostgreSQL, а теперь пора научиться восстанавливать базы из backup.

Если Вы знаете, как создается backup в PostgreSQL, то понимаете, что это делается достаточно просто, поэтому и восстановить базу также не составит труда.

Мы с Вами рассматривали два варианта создания архива, через графический интерфейс pgAdmin и через командную строку, поэтому и восстанавливать мы будем также двумя способами. Только в отличие от создания backup, через батник (для ежедневной автоматической архивации) который нам был нужен практически только для того, чтобы автоматизировать этот процесс и забыть про него, при восстановлении нам такая автоматизация не нужна, так как не каждый день приходится восстанавливать базу данных. Но мы все равно рассмотрим вариант через bat-файл, только для того чтобы Вы знали, как это делается и в случае необходимости оперативно восстановили базу, путем простого запуска батника, так как через графический интерфейс, согласитесь, займет немного больше времени.

Итак, приступим, если Вы помните, что при архивации использовалась утилита pg_dump.exe, то при восстановлении используется утилита pg_restore.exe

Примечание! Как и при создании архива, в качестве примера мы использовали локальный сервер PostgreSQL 8.4, на Windows 7, так и сегодня мы будем использовать именно данные версии СУБД и ОС.

Восстанавливаем базу через pgAdmin

Открываем pgAdmin, подключаемся к серверу, выбираем правой кнопкой мыши базу, и щелкаем «Восстановить»

Затем открывается окно восстановления базы, где Вы можете задать параметры восстановления, в частности выбрать архив, я здесь поставил галочку «Очистить перед восстановлением» так как если ее не ставить достаточно часто база восстанавливается с ошибкой (но все равно восстанавливается), и жмем «ОК»

После Вам останется, дождаться восстановления и нажать кнопку «Завершить»

Восстанавливаем базу с помощью батника

Для этого открываем блокнот (удобней Notepad++) и вставляем в него следующие команды (символ ^ это перенос строки):

"C:/Program Files/PostgreSQL/8.4/bin\pg_restore.exe" ^ --host localhost --port 5432 --username postgres ^ --dbname test --clean --verbose "C:\temp\test_backup.backup"

Где, не трудно догадаться  первая строка это запуск утилиты, вторая это подключение к серверу, третья выбор базы для восстановления, параметры восстановления и соответственно из чего это все восстанавливать. Только одно замечание, при восстановлении проверьте путь к архиву, т.е. необходимо выбрать актуальный архив на момент восстановления, чтобы не получилось ситуации, когда Вы якобы восстановили базу, только скажем прошлогодней версии, а пользователи смотрят и удивляются:)

Нам останется только сохранить этот текстовый документ с расширением .bat и проверить его работу.

Как видите, восстанавливать базу не так страшно как кажется.

На сегодня все, в следующих статьях мы будем рассматривать, как можно создавать и восстанавливать backup базы данных, но только уже на СУБД MSSql 2008.

Похожие статьи:

info-comp.ru

Postgresql восстановление базы из дампа

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

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

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

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

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

steptosleep.ru

Резервное копирование и восстановление в PostgreSQL

Посвящается Владимиру Габриелю

Ушел из жизни молодым Владимир Габриель. Этот замечательный человек сделал много для развития экосистемы свободного программного обеспечения в России. Работая в Microsoft, Владимир проводил тематические конференции по свободному программному обеспечению, на которые приглашались местные российские хакеры, в число которых попадал и я. С одной стороны, конечно, на этих конференциях решались корпоративные задачи компании Microsoft, шла реклама технологий, технологических платформ и мировоззрений. С другой стороны, организаторы не боялись привезти в Россию лидеров сообществ и компаний, занимавшихся свободным ПО, — Брайана Беклендорфа, Эрика Рэймонда, Эндрю Мортона, Мигеля де Иказу, Мэтта Эсея. Образования и общения с живыми иконами не хватало, поэтому подобные конференции были для нас, как глоток свежего воздуха.

Владимир работал на этих конференциях не с самой удобной, с протестной аудиторией. И добивался результата — пусть с ним не соглашались, но запоминали. Можно рассматривать и компанию Датавед, как попытку экспериментальной проверки острых, иногда жестких и неудобных, вопросов и тем, поднимавшихся Владимиром на этих конференциях. Причем же здесь PostgreSQL?

В октябре Владимир участвовал в подготовке небольшого технического текста для нашего сайта, посвященного организации резервного копирования в свободной СУБД PostgreSQL. Может быть в тексте обсуждаются и не самые оригинальные вопросы, но зато вечные.

PostgreSQL предлагает несколько режимов резервного копирования и восстановления баз данных (БД). Поскольку БД располагаются в файловой системе, вполне нормальным методом является резервное копирование на уровне файлов, то есть копирование самого каталога, где размещаются файлы БД. Единственное условие для использования такого режима — полный останов сервера PostgreSQL.

Для систем высокой готовности такой режим резервного копирования не подойдет. Поэтому PostgreSQL позволяет выполнять резервное копирование при запущенном сервере, не прерывая его обычной работы. Наиболее простой режим — это получение дампа БД в текстовом виде (в форме операторов SQL). Для экономии дискового пространства можно сразу же сжимать такой дамп утилитой сжатия (например, gzip). Также существует возможность создания дампа БД в двоичной форме, а также возможность задавать специальные параметры для большего удобства в получении резервной копии и её последующего восстановления.

PostgreSQL также предоставляет возможность резервного копирования в реальном времени посредством Write-Ahead Log (WAL). За счет этого возможно восстановление содержания БД на конкретный момент времени, а также инкрементальное резервное копирование.

Дамп SQL

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

pg_dump bd_name > dump.sql

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

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

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

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

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

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

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

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

psql bd_name < dump.sql

База данных, заданная параметром bd_name не будет создана данной командой. Необходимо создать её из базы template0 перед запуском psql (например, с помощью команды createdb -T template0 bd_name). Аналогично pg_dump, команда psql позволяет указать сервер, к которому осуществляется подключение и имя пользователя, от имени которого осуществляется подключение.

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

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

psql --set ON_ERROR_STOP=on bd_name

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

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

Например:

pg_dump -h сервер1 bd_name | psql -h сервер2 bd_name

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

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

Использование утилиты pg_dumpall

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

pg_dumpall > dump.sql

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

psql –f dump.sql postgres

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

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

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

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

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

pg_dump bd_name | gzip > dump.sql.gz

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

gunzip -c dump.sql.gz | psql bd_name

Или

cat dump.sql.gz | gunzip | psql bd_name

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

pg_dump bd_name | split -b 1m - dump.sql

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

cat dump.sql* | psql bd_name

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

pg_dump -Fc bd_name > dump.sql

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

pg_restore –d bd_name dump.sql

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

www.dataved.ru

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

Создание резервной копии базы PostgreSQL

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

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

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

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

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

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

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

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

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

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

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

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

В принципе можно сжать и текстовый формат резервной копии используя стандартные инструменты Linux – ипользовать программу сжатия, например gzip:

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

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

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

или:

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

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

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

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

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

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

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

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

где файл_дампа — это файл, содержащий вывод команды pg_dump. База данных, заданная параметром имя_БД не будет создана данной командой, так что ее необходимо предварительно создать из шаблона базы template0 перед запуском psql, например, с помощью команды:

createdb -T template0 имя_БД

psql поддерживает опции для указания сервера, к которому осуществляется подключение и имени пользователя, похожие на pg_dump.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

www.oslogic.ru

Как создавать и разворачивать бэкапы 1С баз при работе с PostgreSQL

В интернете много статей, посвящённых этому вопросу, однако некоего практического материала на основе бесплатных решений нам встретить не удалось.

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

Создание архивных копий

Бэкап проходит в 3 этапа:

  1. Делаем выгрузку из PostgreSQL (например, в 22:00)
  2. Архивируем выгрузку из PostgreSQL (напрммер, в 2:00)
  3. Удаляем старые файлы выгрузки из PostgreSQL (например, в 21:45)

На выходе остаются архивы .zip 

!!! Внимание !!!

Вырузку делаем НЕ на виртуалку с PostgreSQL, а на сетевую шару на хосте. В идеале - на отдельный специально выделенный хард.

Задача 1 из 3

1.1. Заводим учётку "SQLbackup" с админскими правами и придумываем для неё пароль.

1.2. Создаём папки и шары с полным разрешением для юзера "SQLbackup" (и ещё кого-нибудь, кому будут нужны эти архивы. Сторонним 1С-никам, например):

1.2.1 Папку "C:\BackupSQL-cmd" - Туда будем складывать командные файлы .bat

1.2.2 Папку и шару "\\server1\SQLBackup\SQL\" - туда будем складывать выгрузки баз

1.2.3 Папку и шару "\\server1\SQLBackup\" - туда будем складывать архивы, т.е. готовые бэкапы

1.3. Создаём первый командный файл "BackupPGSQL.bat" (он выгружает SQL-базы в файл):

SET PGPASSWORD=123456 

set DAT=%date:~6,4%%date:~3,2%%date:~0,2%

"C:\Program Files\PostgreSQL\9.4.2-1.1C\bin\pg_dump.exe" --host localhost --port 5432 --username "postgres" --role "postgres" --no-password --format custom --blobs --section pre-data --section data --section post-data --encoding UTF8 --verbose --file "\\server1\SQLBackup\SQL\%DAT%-accounting.backup" "accounting"

Где: 

"SET PGPASSWORD=123456" - ставим пароль от административной учётки Постгри (по умолчанию называется postgres)

"\\server1\SQLBackup\SQL\%DAT%-accounting.backup" - путь, куда мы выгружаем базу и имя файла, состоящего из сегодняшней даты и " accounting.backup" (пример: "20170830-accounting.backup")

"accounting" - имя самой базы, которую мы бэкапим

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

1.4. Создаём второй командный файл "RemoveOldBackups.bat" (он будет удалять базы, архивация которых описана далее):

net use z: \\server1\SQLBackup\SQL /persistent:no

cd z:

forfiles /p "z:" /S /D -1 /C "cmd /c del /f /a /q @file"

:repeat

for /f "tokens=*" %%i in (' dir /b /s /ad "z:" ') do 2>nul rd /q "%%i" && goto:repeat

net use z: /delete

Где "/D -1" означает, что все файлы в папке, дата создания которых больше 1 дня удалять.

Задача 2 из 3. Effector Saver

Скачиваем: 

https://efsaver.ru/download.html

Устанавливаем Effector Saver как сервис от учётки SQLbackup.

Создаём задачу "Бэкап выгрузок SQL Postgre", тип "Архивирование произвольных данных", в которой отмечаем: 

  • Галочка "Включить в архив файлы" 
  • Файлы --> Путь к файлам. Здесь указываем путь, куда мы положили выгрузки баз. В нашем примере это "\\server1\SQLBackup\SQL\" 
  • Настройка архивов --> Каталог архитвов. Здесь указываем путь, куда мы положим архивные файлы. В нашем примере это "\\server1\SQLBackup\" 
  • Настраиваем расписание.

Задача 3 из 3. Планировщик задач

Создаём две задачи от юзера "SQLbackup" - на оба .bat файла (из Задачи 1)

Необходимые опции:

  • "Run whether user is logged on or not" 
  • "Run with hightest priveleges"

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

1. При необходимости - удаляем старую базу, т.к. в имеющуюся базу бэкап разворачивать нельзя - база не будет работать!!!

В случае если PostgreSQL используется для 1С, делаем так:

Вариант 1 (плох тем, что если баз несколько, то сервер выгонит всех пользователей сразу из всех баз)

  1. Останавливаем службу 1С сервера (Описание: Агент сервера 1С:Предприятия 8.х ...)
  2. Идём в C:\Program Files\PostgreSQL\9.4.2-1.1C\bin
  3. Запускаем pgAdmin3.exe
  4. Подключаемся к нашему серверу (2 клика мышкой на нём)
  5. Выбираем "Базы данных", ищем нашу базу и "Удалить..."

Вариант 2 (надо знать административный пароль от базы, которую надо грохнуть)

  1. Пуск, Стрелочка вниз, Администрирование серверов 1С Предприятия ... 
  2. Находим наш сервер, Кластеры, Локальный кластер, Информационные базы 
  3. Находим нашу базу и нажимаем Удалить. Вводим пароль и удаляем (полностью!). 
  4. Консоль пока не закрываем.

2. Создаём новую базу. 

  1. Идём в C:\Program Files\PostgreSQL\9.4.2-1.1C\bin 
  2. Запускаем pgAdmin3.exe 
  3. Подключаемся к нашему серверу (2 клика мышкой на нём) 
  4. Выбираем "Базы данных" и "Новая база данных..." 
  5. Консоль пока не закрываем.

3. Восстанавливаем резервную копию

  1. Создаём новую базу. Достаточно заполнить только поле "Имя" 
  2. По созданной базе пр. кн. мыши, "Восстановить..." 
  3. Просто выбираем Имя файла и нужную базу.

4. Возвращаемся в консоль "Администрирование сервера 1С"

  1. Пр. кн. мыши на "Информационные базы", Создать --> Информационная база 
  2. Вводим: 
  • Имя 
  • Сервер баз данных (для PostgreSQL - ip адрес сервера PostgreSQL!) 
  • Тип СУБД 
  • База данных 
  • Пользователь сервера БД и его пароль (в нашем примере, напомню, это postgres и пароль 123456)

Вот и всё. Если вы всё сделаете в точном соответствии с приложенной инструкцией, то всё будет работать.

Читайте также
Может быть интересно

www.zeluslugi.ru

Как восстановить данные PostgreSQL из резервной копии

Как и всё, что содержит важные данные, базы данных PostgreSQL следует регулярно сохранять в резервной копии. В Effector Saver реализовано резервное копирование баз PostgreSQL сервера, обеспечивающее надёжное хранение и быстрое восстановление данных.

Вид задачи «Архивирование произвольных данных» позволяет сделать корректную копию СУБД, не прерывая работу пользователей. Подробнее о создании задачи «Архивирование произвольных данных» «О задаче Архивирование произвольных данных»

В данной статье подробно рассмотрим как восстановить данные PostgreSQL из резервной копии.

Effector saver сохраняет резервные копии PostgreSQL в архивах Zip и 7-Zip. Поэтому, перед восстановлением данных PostgreSQL, распакуйте подлежащую восстановлению резервную копию.

Запустите pgAdmin III.

В Браузере объектов разверните дерево «Серверы». Нажмите правой кнопкой мыши по узлу «Базы данных» и выберите «Новая база данных…».

Откроется окно создания новой базы данных.

Во вкладке «Свойства» в поле «Имя», введите наименование новой базы, все остальные поля оставьте без изменений. Нажмите «ОК».

После, раскройте узел «Базы данных» и выберите ранее созданную базу данных, нажмите по ней правой кнопкой мыши и в появившемся контекстном меню выберете «Восстановить…».

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

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

Оставьте все параметры восстановления как есть и нажмите «Восстановить». Запустится процесс восстановления базы данных.

После того, как процесс по восстановлению будет удачно завершен, нажмите «Завершено».

efsaver.ru