Как сделать резервную копию postgresql из pgadmin 4
Добавил пользователь Дмитрий К. Обновлено: 05.10.2024
Резервное копирование баз данных 1С является обязательным, чтобы в случае непредвиденной проблемы всегда была возможность все восстановить. В статье мы рассмотрим, как произвести резервное копирование и восстановление из копии базы 1 8.3, работающей на PostgreSQL 11.5.
Столкнулся с проблемой резервирования и восстановления бэкпапа на PostgreSQL (оказалось все не так просто как MSSQL). На просторах нашей не объятой сети, найти что то дельное и работающее из коробки очень проблемно, поэтому все пришлось собирать по кусочкам из разных источников, методом проб и ошибок чтобы получить действительно рабочую схему. Также решение проблем, с которыми можно столкнуться.
pg_dump — выгрузить базу данных Postgres:
REM /////////////////////////////////////////////////////////////////////////////////
REM РЕЗЕРВИРВОВАНИЕ ПЕРВОЙ БАЗЫ sibek
REM ПРИМЕР СОЗДАНИЯ РЕЗЕРВНОЙ КОПИИ БАЗЫ ДАННЫХ 1C НА POSTGRESQL
CLS
ECHO OFF
CHCP 866 - установить кодовую страницу 1251 Windows, 866 DOS
REM УКАЗАНИЕ ПЕРЕМЕННЫХ СРЕДЫ POSTGRESQL
SET PGBIN=C:\Program Files\PostgreSQL\11.5-7.1C\bin\
SET PGDATABASE=bdpostgre - Имя базы на Postgre сервере
SET PGHOST=localhost
SET PGPORT=5432
SET PGUSER=postgres - Имя пользователя Postgre сервера
SET PGPASSWORD=password - Пароль пользователя Postgre сервера
REM ПЕРЕХОД В КАТАЛОГ С bat-ФАЙЛОМ (ОТКУДА ЗАПУЩЕН ФАЙЛ)
%~d0
CD %~dp0
REM ФОРМИРОВАНИЕ ИМЕНИ ФАЙЛА ДЛЯ РЕЗЕРВНОЙ КОПИИ И LOG ФАЙЛА ОТЧЕТА
SET DAT=%date:~0,2%%date:~3,2%%date:~6,4% - Получаем текущую дату для имени файла
SET DUMPFILE=D:\1C BackUp\%DAT%-sibek.pgsql.backup - Бэкап файл базы
SET LOGFILE=D:\1C BackUp\%DAT%-sibek.pgsql.log - лог файл процесса
SET DUMPPATH="%DUMPFILE%"
SET LOGPATH="%LOGFILE%"
REM ВЫПОЛНЕНИЕ КОМАНДЫ (ПРОГРАММЫ) ДЛЯ СОЗДАНИЕ РЕЗЕРВНОЙ КОПИИ БАЗЫ
CALL "%PGBIN%\pg_dump.exe" --format=custom --verbose --file=%DUMPPATH% 2>%LOGPATH%
REM ВЫПОЛНЕНИЕ КОМАНДЫ (ПРОГРАММЫ) ЗАВЕРШЕНО, ЕСЛИ ОШИБОК НЕТ ТО КОНЕЦ
IF NOT %ERRORLEVEL%==0 GOTO Error
GOTO Successfull
REM ПРИ ВОЗНИКНОВЕНИИ ОШИБОК УДАЛЯЕТСЯ ПОВРЕЖДЕННЫЙ ФАЙЛ КОПИИ И СООТВЕТСТВУЮЩАЯ ЗАПИСЬ В ЖУРНАЛЕ О ЕЕ СОЗДАНИИ
:Error
DEL %DUMPPATH%
MSG * "Ошибка при создании резервной копии базы данных. Смотрите backup_sibek.log."
ECHO %DATETIME% Ошибки при создании резервной копии базы данных %DUMPFILE%. Смотрите отчет %LOGFILE%. >> backup_sibek.log
GOTO End
REM ЕСЛИ КОПИЯ СДЕЛАНА БЕЗ ОШИБОК ДЕЛАЕТСЯ ЗАПИСЬ В ЖУРНАЛЕ РЕГИСТРАЦИИ
:Successfull
ECHO %DATETIME% Успешное создание резервной копии %DUMPFILE% >> backup_sibek.log
GOTO End
:End
REM УСТАНАВЛИВАЕТСЯ ПАРАМЕТРЫ ДЛЯ КОПИИ ХРАНИТЬ 5 ДНЕЙ ОТ ДАТЫ СОЗДАНИЯ, УДАЛЯТЬ ПО ИСТЕЧЕНИЮ
FORFILES /p "D:\1C BackUp\" /s /m *.* /d -5 /c "CMD /c del /Q @FILE"
ВАЖНО! Убрать все пробелы после параметров (чтобы сразу был перенос строки) иначе работать не будет т.к. пробелы будут считаться как символы.
Если несколько БД то можно сделать для каждой БД отдельный bat-файл, либо скопировать полностью код и вставить в один bat-файл (2-3 раза) в зависимости от количества баз, изменяя только имя базы и имена файлов бэкапа и логов.
2. Автоматическое резервирование по расписанию
Заходим в раздел Триггеры там настраиваем расписание выполнения задания
В разделе Действия указываем какое действие выполнять (в нашем случае указываем наш bat-файл), где прописаны все необходимые команды
После выполнения команды в указанной папке будет создан бэкап и лог файлы процесса выполнения.
На этом этап резервирование закончен, переходим в этапу восстановления БД из резервной копии.
3. Восстановление копии БД 1С 8 на PostgreSQL
На этом этапе были небольшие трудности. т.к. не где не было указано конкретно, что надо делать именно так и по другому это не заработает (пришлось догадываться).
Первая проблема. При попытка восстановить БД может возникнуть ошибка:
Не какие регистрации данной DLL (regsvr32), обновление и прочее не помогу, надо данную DLL скопировать в System32 и все заработает как часы.
DLL находится: C:\Program Files\PostgreSQL\11.5-7.1C\pgAdmin 4\bin\python36.dll
DLL скопировать: C:\Windows\System32\python36.dll
Вторая проблема. При восстановление БД в PostgreSQL, она должна быть создана только на Postgre сервер, а в консоле 1С Севера ее быть не должно иначе будет куча ошибок проблем и результат отрицательный (в сравнении с MSSQL таких проблем нет). Так и не разобрался почему, но если настроена связь базы данные на 1с сервере и PostgreSQL сервере то база валится в ошибки (Сервер 1с и PostgreSQL находятся на одном ПК, возможно причина в этом).
Поэтому перед восстановлением создаем базу данных в PostgreSQL, правой кнопкой создать, указываем имя БД, параметры все стандартные по умолчанию.
После чего наживаем правой кнопкой на созданную БД выбираем пункт "Восстановить"
И указываем параметры:
Процесс восстановление займет какое то время.
После этого в базу можно заходить и работать, все работает корректно проблем в работе не было.
1) Формат
2) Степень сжатия
3) Кодировка
4) Имя роли
Что поставить в этих полях ?
Может на других вкладках какие то важные параметры еще ?
а гуи пг-админа - это обёртка, формирующая эту командную строку, при этом постоянно накалывающаяся на длинных путях/именах и т.п. штуках.
изучите
pg_dump --help
- и будет вам щасье, как в понимании "крыжиков" пж-одмина (и часто упускаемой опции global в оном), так и ващще
когда и если в пг-админе реализуют безошибочно все опции pg_dump -- тогда и только тогда пользоваться им станет чуть удобнее, чем. (при этом не забывайте смотреть, какой версией бинарников настроен пользоваться пж-одмин, дабы они соответствовали версии базы, и не нужно ли перед выполнением дампа сменить ему путь к бинарникам в параметрах (в последнем это файл/параметры/пути/PG ).
Вам никто не ответит на этот вопрос, так как он поставлен некорректно.
Например:
Вы делаете дамп схемы и данных с "удалить существующее перед заливкой", в этом случае дамп будет с DROP TABLE и т.д. А теперь вы восстанавливаете в базе где нету этих таблиц. Вы получаете бледный вид и холодные ножки.
Пример 2:
Вы делаете дамп, однако таких пользователей в восстанавливаемой базе нету. Рещение - использовать pg_dumpall.
Контрпример2:
Вы делаете pg_dumpall, а потом накатываете все это на живую базу, где уже есть эти пользователи.
Резервная копия - это копия данных из вашей базы данных, которую можно использовать для восстановления этих данных. Резервные копии - это резервные копии физических файлов, используемых для хранения и восстановления ваших баз данных, таких как файлы данных, управляющие файлы и другие. Каждая физическая резервная копия - это копия файлов, хранящих информацию базы данных в каком-либо другом месте, будь то на диске или в каком-либо автономном хранилище, например на ленте.
Преимущества резервного копирования:
Имея действительные резервные копии базы данных, вы можете восстановить ваши данные после многих сбоев, таких как:
- Отказ носителя: Отказ носителя - это сбой чтения или записи файла на диске, необходимого для запуска базы данных, из-за физической проблемы с диском, такой как сбой головки.
- Аппаратные сбои, например, поврежденный диск.
- Ошибки пользователя, например, удаление таблицы по ошибке.
- Стихийные бедствия.
Компонент резервного копирования и восстановления сервера PostgreSQL обеспечивает необходимую защиту для защиты важных данных, хранящихся в базах данных сервера. Чтобы минимизировать риск потери данных, вам необходимо создавать резервные копии ваших баз данных, чтобы регулярно вносить изменения в ваши данные. Хорошо спланированная стратегия резервного копирования и восстановления помогает защитить базы данных от потери данных. Проверьте свою стратегию, восстановив набор резервных копий, а затем восстановив базу данных.
Резервное копирование базы данных PostgreSQL
pg_dump - это утилита для резервного копирования базы данных PostgreSQL. Это делает последовательные резервные копии, даже если база данных используется одновременно. pg_dump не блокирует доступ других пользователей к базе данных (читателей или писателей).
Вы можете использовать программу командной строки pg_dump или phpPgAdmin для резервного копирования базы данных PostgreSQL в файл.
Доступ к командной строке на компьютере, где хранится база данных. Если у вас есть физический доступ к компьютеру, вы можете открыть DOS или окно терминала для доступа к командной строке.
Введите следующую команду и нажмите клавишу ВВОД. Замените USERNAME своим именем пользователя, а DBNAME - именем базы данных, которую вы хотите экспортировать:
Синтаксис:
Введите свой пароль в строке ввода пароля.
Файл Mybackup.pgsql теперь содержит все данные для базы данных DBNAME. Если файл Mybackup.pgsql находится на удаленном компьютере, загрузите файл на локальный компьютер.
Полный синтаксис и другие параметры pg_dump
Синтаксис:
Следующие параметры командной строки управляют параметрами подключения к базе данных
| вариант | Описание |
|---|---|
| -d dbname --dbname = имя_бд | Указывает имя базы данных для подключения. |
| -х хозяин --host = хост | Указывает имя хоста компьютера, на котором работает сервер. |
| порт --port = порт | Указывает расширение TCP-порта или локального расширения файла сокета домена Unix, на котором сервер ожидает подключения (по умолчанию используется переменная среды PGPORT). |
| -U имя пользователя --username = имя пользователя | Имя пользователя. |
| -w --no-пароль | Никогда не выдавайте запрос пароля. |
| -W --пароль | Принудительно pg_dump запрашивает пароль перед подключением к базе данных. Эта опция никогда не важна, так как pg_dump автоматически запросит пароль, если сервер требует аутентификацию по паролю. |
| --role = RoleName | Задает имя роли, которая будет использоваться для создания дампа. |
Восстановить базу данных PostgreSQL
Текстовые файлы, созданные pg_dump, предназначены для чтения программой psql. Введите следующую команду и нажмите клавишу ВВОД. Замените USERNAME вашим именем пользователя, а DBNAME - именем базы данных, в которую вы хотите восстановить данные.
Синтаксис:
где Mybackup.pgsql - это файл, выводимый командой pg_dump. Эта команда не будет создавать базу данных dbname, поэтому вы должны создать ее самостоятельно из template0 перед выполнением psql (например, с помощью createb -T template0 dbname). psql поддерживает параметры, аналогичные pg_dump, для указания сервера базы данных, к которому нужно подключиться, и имени пользователя для использования. Дампы нетекстовых файлов восстанавливаются с помощью утилиты pg_restore.
Примечание. Перед восстановлением дампа SQL все пользователи, которым принадлежат объекты или которым были предоставлены разрешения для объектов в выгруженной базе данных, должны уже существовать. Если этого не произойдет, при восстановлении не удастся воссоздать объекты с первоначальным владельцем и / или разрешениями.
pg_restore - это утилита для восстановления базы данных PostgreSQL из архива, созданного pg_dump в одном из текстовых форматов.
pg_restore может работать в двух режимах. Если указано имя базы данных, pg_restore подключается к этой базе данных и восстанавливает содержимое архива непосредственно в базу данных. В противном случае сценарий, содержащий команды SQL, необходимые для перестройки базы данных, создается и записывается в файл или стандартный вывод. Этот вывод сценария эквивалентен формату вывода простого текста pg_dump. Поэтому некоторые параметры, управляющие выводом, аналогичны параметрам pg_dump.
Синтаксис:
pg_restore принимает следующие аргументы командной строки в таблицу.
| Опции | Описание |
|---|---|
| имя файла | Расположение файла архива (или каталога для архива в формате каталога), который необходимо восстановить. Если не указан, используется стандартный ввод. |
| -a --data только | Восстановите только данные, а не схему (определения данных). Эта опция похожа, но по историческим причинам не идентична, указав --section = data. |
| -с --clean | Очистите (отбросьте) объекты базы данных перед их воссозданием. |
| -С --Создайте | Создайте базу данных перед ее восстановлением. Если также указан параметр --clean, удалите и заново создайте целевую базу данных перед подключением к ней. Когда используется эта опция, база данных с именем -d используется только для выдачи начальных команд DROP DATABASE и CREATE DATABASE. Все данные восстанавливаются в имени базы данных, которое появляется в архиве. |
| -d dbname --dbname = имя_бд | Подключитесь к базе данных dbname и восстановите непосредственно в базе данных. |
| -e --exit-на-ошибки | Выйдите, если при отправке команд SQL в базу данных возникла ошибка. По умолчанию это продолжение и отображение количества ошибок в конце восстановления. |
| -f имя файла --file = имя_файла | Укажите выходной файл для сгенерированного скрипта или для листинга при использовании с -l. По умолчанию используется стандартный вывод. |
| -F формат --format = формат | Укажите формат архива. Нет необходимости указывать формат, так как pg_restore определит формат автоматически. Если указано, это может быть одно из следующих: c custom: архив находится в пользовательском формате pg_dump. d directory: архив является каталогом архива. t tar: архив является архивом tar. |
| -Я индекс --index Задает = индекс | Восстановить определение только именованного индекса. |
| -j количество рабочих мест --jobs = число-рабочих мест | Запустите самые трудоемкие части pg_restore - те, которые загружают данные, создают индексы или создают ограничения - используя несколько одновременных заданий. Эта опция может значительно сократить время восстановления большой базы данных на сервере, работающем на многопроцессорной машине. |
| -l --список | Перечислите содержимое архива. |
| -L список-файл --use-список = список-файлы | Восстановите только те элементы архива, которые перечислены в list-file, и восстановите их в порядке их появления в файле. list-file обычно создается путем редактирования вывода предыдущей операции -l. Строки можно перемещать или удалять, а также закомментировать, поместив точку с запятой (;) в начале строки. |
| -n пространство имен --schema = схема | Восстановите только те объекты, которые находятся в именованной схеме. Это можно комбинировать с опцией -t, чтобы восстановить только определенную таблицу. |
| -О --no-владелец | Не выводите команды для установки владельца объектов в соответствии с исходной базой данных. По умолчанию pg_restore выдает операторы ALTER OWNER или SET SESSION AUTHORIZATION, чтобы установить владельца созданных элементов схемы. |
| -P имя-функции (argtype [, . ]) --function = имя-функции (argtype [, . ]) | Восстановите только названную функцию. |
| -Р --no-переподключение | Эта опция устарела, но все же принята для обратной совместимости. |
| -s --schema только | Восстанавливайте только схему (определения данных), а не данные, в той степени, в которой записи схемы присутствуют в архиве. Эта опция является обратной к -data-only. |
| -S имя пользователя --superuser = имя пользователя | Укажите имя пользователя суперпользователя, которое будет использоваться при отключении триггеров. Это актуально, только если используется --disable-triggers. |
| стол --table = таблица | Восстановить определение и / или данные только именованной таблицы. Это можно сочетать с параметром -n, чтобы указать схему. |
| -T триггер --trigger = триггер | Восстановить только названный триггер. |
| -v --подробный | Определяет подробный режим. |
| -V --версия | Распечатайте версию pg_dump и выйдите. |
| -Икс --no-привилегии --no-ACL | Запретить восстановление прав доступа (команды предоставления / отзыва). |
| -1 --single-транзакции | Выполните восстановление как одну транзакцию. |
| --disable-спусковые | Эта опция актуальна только при выполнении восстановления только данных. |
| --no-данные для-неудавшихся столов | По умолчанию данные таблицы восстанавливаются, даже если команда создания таблицы не выполнена (например, потому что она уже существует). С этой опцией данные для такой таблицы пропускаются. Это поведение полезно, если целевая база данных уже содержит требуемое содержимое таблицы. Этот параметр действует только при восстановлении непосредственно в базу данных, но не при выводе сценария SQL. |
| --no-безопасность-этикетка | Не выводите команды для восстановления меток безопасности, даже если их содержит архив. |
| --no-табличные | Не выводите команды для выбора табличных пространств. С помощью этой опции все объекты будут создаваться в любом табличном пространстве по умолчанию при восстановлении. |
| --section = имя раздела | Только восстановить названный раздел. |
| --use-SET-сеанса авторизации | Выведите стандартные команды SQL SET SESSION AUTHORIZATION вместо команд ALTER OWNER, чтобы определить владение объектом. |
| -? --Помогите | Показать справку об аргументах командной строки pg_restore и завершиться. |
Следующие параметры командной строки управляют параметрами подключения к базе данных
PostgreSQL – это современная открытая система управления базами данных (или СУБД), которая часто используется для хранения информации, необходимой для работы сайтов и веб-приложений.
Для предотвращения потери ценных данных очень важно внедрить схему резервного копирования. Данное руководство охватывает несколько практических способов создания резервных копий данных в PostgreSQL.
Для выполнения руководства необходим виртуальный выделенный сервер Ubuntu 12.04 и PostgreSQL 9.1 (руководство также действительно для более новых версий СУБД).
Резервное копирование при помощи pg_dump
PostgreSQL предоставляет утилиту pg_dump, которая позволяет сделать дамп базы PostgreSQL в целях резервного копирования.
Утилита pg_dump запускается из командной строки Linux. Ее базовый синтаксис выглядит так:
pg_dump name_of_database > name_of_backup_file
Для запуска команды нужно иметь право на чтение всей информации БД, потому ее, как правило, следует запускать как суперпользователь (англ. superuser).
Для примера можно войти как пользователь postgres (стандартный пользователь БД PostgreSQL) и выполнить команду на стандартную БД, которая тоже зовется postgres:
sudo su - postgres
pg_dump postgres > postgres_db.bak
Данная команда является клиентской программой PostgreSQL, потому ее можно запускать на удаленной системе (если она имеет соответствующие права на БД).
Чтобы создать резервную копию данных удаленной системы, внесите в команду флаг -h (который указывает на удаленный хост) и -p (указывает на удаленный порт):
pg_dump -h remote_host -p remote_port name_of_database > name_of_backup_file
Кроме того, можно указать другого пользователя при помощи опции -U. Синтаксис будет иметь такой вид:
pg_dump -U user_name -h remote_host -p remote_port name_of_database > name_of_backup_file
Помните: как и любая другая клиентская команда, pg_dump имеет определенные требования аутентификации. Это значит, что для создания резервной копии системы необходимо иметь валидные учетные данные этой системы.
Восстановление дампа PostgreSQL с помощью pg_dump
psql empty_database backup_file
Примечание: эта операция перенаправления не создает требуемую базу данных. Ее нужно создать отдельно до запуска команды.
createdb -T template0 restored_database
psql restored_database
При этом будет создана пустая БД на основе template0.
Для корректного восстановления дампа можно выполнить еще одно действие – воссоздать любого пользователя, который владеет или имеет привилегии на объекты в базе данных.
К примеру, если БД принадлежит пользователю test_user, то перед импортированием нужно создать его в восстанавливаемой системе:
createuser test_user
psql restored_database
Устранение ошибок восстановления
По умолчанию СУБД PostgreSQL продолжит восстанавливать данные, даже столкнувшись с ошибкой.
Но во многих случаях это поведение нежелательно, поскольку позже будет очень непросто обнаружить ошибку и восстановить прежний вид БД.
Чтобы система PostgreSQL прерывала восстановление в случае возникновения ошибки, наберите:
psql --set ON_ERROR_STOP=on restored_database backup_file
Эта команда остановит операцию восстановления PostgreSQL в случае ошибки.
Конечно, в системе останется поврежденная БД, которая была лишь частично восстановлена; тем не менее, такой подход позволяет устранять ошибки по мере их поступления, а не после полного восстановления БД (что может оказаться достаточно непростой задачей).
Во многих ситуациях отличным решением может оказаться использование опции -1 (цифра один) или –single-transaction:
psql -1 restored_database backup_file
Эта опция выполняет весь процесс восстановления в рамках одной транзакции.
Разница между этой опцией и настройкой ON_ERROR_STOP заключается в том, что она либо полностью завершит процесс, либо же не выполнит совсем ничего.
Этот процесс может оказаться очень затратным для восстановления больших БД, но во многих случаях отсутствие в системе поврежденной БД стоит израсходованных ресурсов.
Резервное копирование и восстановление всех БД PostgreSQL
Утилита pg_dumpall позволяет создать резервную копию абсолютно всех данных.
Синтаксис этой команды очень похож на синтаксис pg_dump; но в данном случае не нужно указывать БД, поскольку команда скопирует все доступные базы данных:
Чтобы восстановить эти баз данных, нужно передать файл psql с БД по умолчанию:
psql -f backup_file postgres
Итоги
Резервная копия данных – неотъемлемый компонент плана хранения данных любого вида. К счастью, PostgreSQL предоставляет удобные утилиты, позволяющие создавать эффективные резервные копии важной информации.
Важно регулярно проверять и обновлять свои резервные копии, чтобы в случае необходимости иметь доступ к последним версиям баз данных. Запомните: резервные копии полезны только в том случае, если с их помощью можно восстановить систему до ее последнего состояния.
Читайте также: