wwwoldi.ru

About Me

Dashy

Hello word I am dashy Guy

Разное

Backup 1c postgresql: Бэкап и восстановление базы 1С в бд postgresql

alexxlab
No Comments

Содержание

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

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


Если у вас есть желание освоить Linux с нуля, не имея базовых знаний, рекомендую познакомиться с онлайн-курсом Administrator Linux.Basic в OTUS. Курс для новичков, для тех, кто хочет войти в профессию администратора Linux. Подробности по .

Данная статья является частью единого цикла статьей про сервер Debian.

Введение

Ранее я рассказывал о том, как установить и настроить postgresql для работы с 1С, а затем как провести анализ производительности базы 1С и по возможности увеличить быстродействие. После успешного выполнения первых двух задач, мы можем приступать к эксплуатации системы. Когда рабочая база 1С уже на сервере, обязательно нужно настроить ее регулярный бэкап. Желательно так же периодически проводить очистку и переиндексацию sql базы. Это увеличит ее быстродействие. Выполнять эти операции лучше всего автоматически, в нерабочее время. Именно этим мы и займемся в этой статье.

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

Способов бэкапа базы данных postgresql много. Я буду использовать самый простой — выгрузка базы данных в обычный текстовый sql скрипт с помощью pg_dump. Подробно о работе этой утилиты и ее настройках можно прочитать вот тут — https://postgrespro.ru/docs/postgrespro/9.6/app-pgdump. В сети много примеров и готовых скриптов для решения вопроса архивации баз postgresql. Например, есть вот такой скрипт. Когда я его увидел, мне просто стало лень с ним разбираться. Написать простенький свой мне гораздо проще.

Прежде чем делать непосредственно архив 1С базы, нам нужно разрешить подключаться локально к серверу бд без авторизации. Я единственный пользователь сервера, доступа к нему никто больше не имеет, в интернет он не опубликован, поэтому я сознательно иду на этот шаг, чтобы упростить себе работу. Если для вас этот вариант не подходит, то все дальнейшие скрипты вам нужно будет самим изменить, добавив в них авторизацию. Это не сложно, в описании команд все есть. Я буду все команды выполнять локально от пользователя root.

Редактируем в файле /etc/postgresql/9.6/main/pg_hba.conf строку, приведя ее к такому виду:

local   all             all                                     trust

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

# systemctl restart postgresql

Бэкап базы данных выполняется простой командой:

# pg_dump -U postgres base1c | pigz > /backup/base1c.sql.gz
postgresимя пользователя базы данных
base1cназвание бд с 1С
pigzархиватор
base1c.sql.gzфайл, куда будет сохранена резервная копия

Обращаю внимание на архиватор pigz. Я его использую, потому что он умеет жать данные, нагружая все ядра процессора, в отличие от gzip. Прирост производительности 2-3 раза. Рекомендую. На debian он ставится из стандартного репозитория:

# apt-get -y install pigz

В centos из epel:

# yum -y install epel-release
# yum -y install pigz

Попробуйте вручную в консоли выполнить команду и посмотреть на результат. Вы должны получить заархивированный файл с текстовыми sql командами в открытом виде. Теперь попробуем восстановить базу данных 1С из архива. Тут будут нюансы. Первым делом разархивируем файл:

# unpigz /backup/base1c.sql.gz

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

# unpigz -c /backup/base1c.sql.gz > base1c.sql

Создадим на сервере новую базу данных, в которую будем восстанавливать резервную копию. Перед этим посмотрим список баз данных на сервере:

# psql -U postgres -l

Создаем новую базу данных:

# createdb --username postgres -T template0 base1c-restored

Смотрим, что получилось:

Базу данных создали. Теперь загружаем в нее наш бэкап 1с:

# psql -U postgres base1c-restored < /backup/base1c.sql

Ждем приличное время. Оно будет зависеть от размера базы. После того, как восстановление завершено, можно идти в консоль кластера 1С и добавлять новую базу, указывая в качестве базы postgresql только что созданную базу с загруженным архивом.

Я сначала пошел по другому пути. Создал в консоли пустую базу, загрузил в нее бэкап через консоль postgresql. Архив вроде бы загрузился, но в базу я не мог войти, не проходила авторизация. То есть возникли какие-то проблемы. Когда сделал, как описал выше, без проблем все заработало сразу. Проверил базу, все было в порядке.


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

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

# cat /root/bin/backup-sql.sh
#!/bin/sh

# Устанавливаем дату
DATA=`date +"%Y-%m-%d_%H-%M"`

# Записываем информацию в лог с секундами
echo "`date +"%Y-%m-%d_%H-%M-%S"` Start backup base1c" >> /var/log/postgresql/service.log

# Бэкапим базу данных base1c и сразу сжимаем
/usr/bin/pg_dump -U postgres base1c | pigz > /backup/$DATA-base1c.sql.gz

echo "`date +"%Y-%m-%d_%H-%M-%S"` End backup base1c" >> /var/log/postgresql/service.log

# Удаляем в папке с бэкапами архивы старше 3-х дней
/usr/bin/find /backup -type f -mtime +3 -exec rm -rf {} \;

Я указал в названии файла с бэкапом 1с базы использовать текущую дату с точностью до минуты. В лог я пишу информацию с точностью до секунды, чтобы было точно видно, сколько длился бэкап. Просто для справки информация, можно обойтись и без лога совсем. В конце удаляю из папки все архивы старше 3-х дней. Я обычно сервером с бэкапами забираю информацию с целевых хостов. То есть я буду подключаться к sql серверу и забирать с него архивы и уже на сервере бэкапов буду их хранить и ротировать в зависимости от желаемой глубины архива. А здесь я удаляю почти сразу архивы, не храню их, чтобы не занимать место. Если вы будете хранить их долгосрочно на этом же сервере, то просто измените цифру 3 на нужное вам число дней, за которые вы хотите иметь архивную копию своей базы 1С.

Использование программы PostgreSQL Backup

Для бэкапа базы данных постгрес есть удобная и бесплатная для двух баз программа под windows — PostgreSQL Backup. Я ее установил, проверил, сделал бэкап, потом восстановил из бэкапа. Все отлично работает. Из полезных функций:

  • встроенный планировщик
  • автоматическое сжатие бэкапа
  • отправка оповещений на email

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

Обновление статистики и реиндексация в postgresql

С бэкапами разобрались, теперь настроим регламентные операции на уровне субд, чтобы поддерживать быстродействие базы данных. Тут особых комментариев не будет, в интернете очень много информации на тему регламентных заданий для баз 1С. Я просто приведу пример того, как это выглядит в postgresql.

Выполняем очистку и анализ базы данных 1С:

# vacuumdb --full --analyze --username postgres --dbname base1c

Реиндексация таблиц базы данных:

# reindexdb --username postgres --dbname base1c

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

# cat /root/bin/service-sql.sh
#!/bin/sh

# Записываем информацию в лог
echo "`date +"%Y-%m-%d_%H-%M-%S"` Start vacuum base1c" >> /var/log/postgresql/service.log
# Выполняем очистку и анализ базы данных
/usr/bin/vacuumdb --full --analyze --username postgres --dbname base1c
echo "`date +"%Y-%m-%d_%H-%M-%S"` End vacuum base1c" >> /var/log/postgresql/service.log

sleep 2

echo "`date +"%Y-%m-%d_%H-%M-%S"` Start reindex base1c" >> /var/log/postgresql/service.log
# Переиндексирвоать базу
/usr/bin/reindexdb --username postgres --dbname base1c
echo "`date +"%Y-%m-%d_%H-%M-%S"` End reindex base1c" >> /var/log/postgresql/service.log

Сохраняем скрипт и добавляем в планировщик. Хотя я для удобства сделал еще один скрипт, который объединяет бэкап и обслуживание и уже его добавил в cron:

# cat all-sql.sh
#!/bin/sh

/root/bin/backup-sql.sh
sleep 2
/root/bin/service-sql.sh

Добавялем в /etc/crontab:

# Бэкап и обслуживание БД
1 3 * * * root /root/bin/all-sql.sh

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

Описанные выше операции очистки и переиндексации можно делать в ручном режиме в программе под windows — pgAdmin. Рекомендую ее установить на всякий случай. Достаточно удобно и быстро можно посмотреть информацию или выполнить какие-то операции с базой данных посгрес.

Заключение

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

Напоминаю, что данная статья является частью единого цикла статьей про сервер Debian.

Онлайн курс по Linux

Если у вас есть желание освоить операционную систему Linux, не имея подходящего опыта, рекомендую познакомиться с онлайн-курсом Administrator Linux. Basic в OTUS. Курс для новичков, адаптирован для тех, кто только начинает изучение Linux. Обучение длится 4 месяца.

Что даст вам этот курс:

  • Вы получите навыки администрирования Linux (структура Linux, основные команды, работа с файлами и ПО).
  • Вы рассмотрите следующий стек технологий: Zabbix, Prometheus, TCP/IP, nginx, Apache, MySQL, Bash, Docker, Git, nosql, grfana, ELK.
  • Умение настраивать веб-сервера, базы данных (mysql и nosql) и работа с сетью.
  • Мониторинг и логирование на базе Zabbix, Prometheus, Grafana и ELK.
  • Научитесь командной работе с помощью Git и Docker.

Смотрите подробнее программу по .

Помогла статья? Подписывайся на telegram канал автора

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

Как создать в 1C и развернуть бэкап 1С-базы средствами PostgreSQL?

В интернете много статей, посвящённых вопросу создания бэкапа 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

Скачиваем Effector Saver: 

→ 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)

Если вы завершите инструкцию в точном соответствии, то всё будет работать.

PostgreSQL Backup — резервное копирование баз 1С

Для создание резервной копии БД PostgreSQL необходим .bat файл.

 

Скачать

ОПИСАНИЕ:

6 строка — путь в дерикторию файла «pgdump.exe»

7 строка — имя целевой базы данных (basename)

8 строка — сетевое расположение сервера баз данных

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

10 строка — имя root пользователя PostgreSQL (postgres)

11 строка — пароль root пользователя (Pa$$word)

19 строка — место хранения резервной копии (\\192.168.0.242\backup\buhgalteria\%DUMPFILE%) (желательно расшарить папку на другом ПК и хранить резервные копии баз отдельно от сервера баз данных)

20 строка — место хранения лога процесса резервного копирования (\\192.168.0.242\backup\logs\%LOGFILE%)

35 строка — название лога процесса резервного копирования (log_basename.log) После настройки .bat файла, создайте в планировщике заданий новое задание с запуском нашего файла.

REM ПРИМЕР СОЗДАНИЯ РЕЗЕРВНОЙ КОПИИ БАЗЫ ДАННЫХ POSTGRESQL
CLS
ECHO OFF
CHCP 1251
REM Установка переменных окружения
SET PGBIN=C:\Program Files (x86)\PostgreSQL\9.3.4-1.1C\bin
SET PGDATABASE=crm3
SET PGHOST=localhost
SET PGPORT=5432
SET PGUSER=postgres
SET PGPASSWORD=RSqw12Ma100
REM Смена диска и переход в папку из которой запущен bat-файл
%~d0
CD %~dp0
REM Формирование имени файла резервной копии и файла-отчета
SET DATETIME=%DATE:~6,4%-%DATE:~3,2%-%DATE:~0,2% %TIME:~0,2%-%TIME:~3,2%-%TIME:~6,2%
SET DUMPFILE=%PGDATABASE% %DATETIME%.backup
SET LOGFILE=%PGDATABASE% %DATETIME%.log
SET DUMPPATH="m:\kino-market%DUMPFILE%"
SET LOGPATH="m:\logs\kino-market%LOGFILE%"
REM Создание резервной копии
IF NOT EXIST Backup MD Backup
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.log."
ECHO %DATETIME% Ошибки при создании резервной копии базы данных %DUMPFILE%. Смотрите отчет %LOGFILE%. >> backup.log
GOTO End
REM В случае удачного резервного копирования просто делается запись в журнал
:Successfull
ECHO %DATETIME% Успешное создание резервной копии %DUMPFILE% >> backup.log
GOTO End
:End
pause

 

P.S. Для удаления бекапов старше определенного количества дней допишите в код строку(впишите путь и вместо «14» количество необходимых дней):

forfiles -p "путь к папке с бекапами" -s -m *.* -d -14 -c "cmd /c del /F /q @path"

 

PostgreSQL 9.4.2-1.1C: Резервное копирование SQL баз данных 1С самым простым путём


Ubuntu: смена часового пояса и синхронизация времени


31 октября 2018 ВК
Tw
Fb



Любой сервер нуждается в выставлении точного времени. Это нужно для самых различных вещей, начиная от сбора корректных логов, заканчивая работой WEB-приложений, в работе которых участвуют сертификаты. Установка точного времени складывается из двух частей: синхронизация самого времени и установка правильного часового пояса. Посмотрим, как нам это сделать.



Создание LiveCD RDP-клиента на основе Ubuntu 12.04.5 с помощью Remastersys


10 марта 2017 ВК
Tw
Fb



Купили простейшие ПК с SoC материнскими платами для использования в качестве клиентов RDP Windows Server 2008R2, а вот жёсткие диски или SSD в них купить забыли (да, фэйл полнейший). После длительного самобичевания и осознания, что бюджет никто нам не пополнит, стали думать, что с этим можно сделать. Решили установить Linux OS на флешки и загружаться с них. Но купили не очень быстрые флешки и они не тянут на себе даже Lubuntu (уже второй фэйл из двух). Всё виснет.
Путём длительных изысканий решили, что можно спокойно работать в режиме LiveCD. Но нам нужно, чтобы в загружаемом Live образе присутствовали ярлыки Remmina с сохранённым списком серверов. Для этого решили пересобрать Live дистрибутив Ubuntu с помощью Remastersys. Что из этого вышло — в нашем видео с подробными комментариями. Самые важные шаги мы вынесли отдельно в статью.




Honeywell Metrologic MS3780 не считывает штрих-код EAN13 + EAN5


29 октября 2016 ВК
Tw
Fb



У одного нашего клиента множество похожего товара, но всё-таки разного. Поэтому производитель печатает на товаре не привычный штрих-код EAN13, а EAN13 с дополнительными 5 символами, то есть EAN13 + EAN5. И так случилось, что сканер не считывает эти дополнительные символы. Решаем эту проблему.


Создание бэкапа базы PostgreSQL для Windows

В PostgreSQL есть утилита, которая создает дамп базы данных и называется она pg_dump. Для того чтобы автоматизировать процесс создания бэкапов баз PostgreSQL нужно будет создать bat-файл, который будет вызывать утилиту pg_dump  и вызывать его с помощью планировщика заданий. Результатом выполнения такого сценария будет ежедневное копирование базы данных PostgreSQL, ведение журнала с информацией о датах и результатах выполнения, сохранение подробных сведений о ходе выполнения каждой резервной копии в отдельный текстовый файл и в случае неудачи отображение диалогового окна с сообщением.Содержимое bat-файла следующее:

REM ПРИМЕР СОЗДАНИЯ РЕЗЕРВНОЙ КОПИИ БАЗЫ ДАННЫХ POSTGRESQL
CLS
ECHO OFF
CHCP 1251
REM Установка переменных окружения
SET PGBIN=c:\Program Files\PostgreSQL\9.2.4-1.1C\bin
SET PGDATABASE=ut
SET PGHOST=localhost
SET PGPORT=5432
SET PGUSER=postgres
SET PGPASSWORD=123456
REM Смена диска и переход в папку из которой запущен bat-файл
%~d0
CD %~dp0
REM Формирование имени файла резервной копии и файла-отчета
SET DATETIME=%DATE:~6,4%-%DATE:~3,2%-%DATE:~0,2% %TIME:~0,2%-%TIME:~3,2%-%TIME:~6,2%
SET DUMPFILE=%PGDATABASE% %DATETIME%.backup
SET LOGFILE=%PGDATABASE% %DATETIME%.log
SET DUMPPATH="Backup\%DUMPFILE%"
SET LOGPATH="Backup\%LOGFILE%"
REM Создание резервной копии
IF NOT EXIST Backup MD Backup
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.log."
ECHO %DATETIME% Ошибки при создании резервной копии базы данных %DUMPFILE%. Смотрите отчет %LOGFILE%. >> backup.log
GOTO End
REM В случае удачного резервного копирования просто делается запись в журнал
:Successfull
ECHO %DATETIME% Успешное создание резервной копии %DUMPFILE% >> backup.log
GOTO End
:End

Справочную информацию о командах, испульзуемых в этом файле можно получить из командной строки набрав следующую команду: «[Имя команды] /?»
Многие использованные здесь команды достаточно распространены и известны, поэтому хочется акцентировать внимание на нескольких менее известных.

Строки 15, 16 выполняют переход в папку в которой находится файл «backup.bat». «%0» возвращает имя bat-файла; «%~d0» и «%~dp0» возвращают соответственно диск и путь к bat-файлу. Подробные сведения о работе с параметрами файла можно посмотреть по этой ссылке.

В строке 19 формируется строковое представление даты и времени в нужном формате. При формировании происходит обращение к переменным окружения DATE и TIME, которые хранят текстовое представление даты и времени соответственно. После имени переменной указывается строка вида «:~m,n», где m — позиция в строке, n — количество символов.

В строке 27 вызывается утилита резервного копирования pg_dump.exe. Вызов выполняется с применением команды CALL, это позволяет дождаться завершения утилиты и проанализировать результат выполнения. Вызов утилиты завершается строкой «2>%LOGPATH%». Эта строка означает что поток ошибок STDERR, номер которого 2, приложения pg_dump.exe перенаправляется в файл, имя которого сохранено в переменной окружения LOGPATH. Так как приложение pg_dump.exe выводит все сообщения в стандартный поток ошибок, то в файле LOGPATH будет сохранен подробный отчет о выполнении резервного копирования.

В строках 37 и 42 выполняется перенаправление вывода в файл backup.log. Перенаправление осуществляется оператором «>>». Различие между операторами «>» и «>>» в том, что первый каждый раз создает новый файл, затирая ранее записанные данные, а второй — дописывает данные в существующий файл. Таким образом можно вести журнал с подробными сведениями о результатах резервного копирования.

Проверяем как работает bat-файл. Если дампы базы создаются, то можно приступать к созданию задачи для планировщика заданий Windows.
Создаем задание, которое будет запускать bat-файл каждый день в ночное время.

Ежедневные бэкапы со временям породят проблему свободного пространства на жестком диске. Можно чистить ручками, но лучше уж автоматизацию сделать полной. Решается этот вопрос также созданием bat-файла и задачи в планировщике заданий Windows.

Содержимое bat-файла такое:

forfiles /p "E:\BACKUP\Backup" /S /D -5 /C "cmd /c del /f /a /q @file"

Здесь указана команда при выполнении которой будут удаляться файлы старше 5 дней.
В планировщике заданий можно создать задачу на исполнения этого bat-файла раз в неделю.

Резервное копирование и обслуживание баз данных PostgreSQL для 1С:Предприятие

Создание временного хранилища

Создадим отдельный диск в виртуальной машине ESXi 6.5 для временного хранения архивных копий.

Для отображения подключенных дисков выполним команду:

fdisk -l | grep "Disk /dev/sd"

Подключенный диск имеет название sdf.

Разметим пространство.  В качестве файловой системы выберем ext4:

mkfs.ext4 /dev/sdf

Создадим точку монтирования — каталог /backup

mkdir /backup

Монтируем созданный ранее диск в каталог /backup:

mount /dev/sdf /backup

Для автоматического монтирования диска при загрузке системы выполним команду (редактор mcedit входит в состав файлового менеджера MC):

mcedit /etc/fstab

в открывшемся файле добавим строчки:

/dev/sdf /backup ext4 defaults 1 2

Резервное копирование

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

mcedit /var/lib/pgsql/9.6/data/pg_hba.conf

в открывшемся файле изменим строки:

local all all peer на local all all trust

Для принятия изменений перезагрузим сервер СУБД:

systemctl restart postgresql-9.6

Для создания резервной копии создадим скрипт, в котором воспользуемся утилитой pg_dump, позволяющая создать дамп для указанной БД.

Создание дампа происходит без блокирования таблиц и представляет снимок БД на момент выполнения команды.

Дамп БД будем архивировать с помощью pigz, т. к. он использует все ядра процессора.

Установим архиватор pigz:

yum -y install pigz

Перед архивированием можно посмотреть список БД на сервере и для справки уточнить наименование БД и её кодировку:

psql -U postgres -l

Для хранения архивов в «облаке» воспользуемся сервисом Яндекс.Диск.

Установим консольный клиент:

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




Согласно плану создания резервных копий БД, создадим 3 скрипта, которые будут создавать ежедневные, еженедельные и ежемесячные бэкапы с разными сроками хранения.


Ежедневный скрипт:


mcedit /backup/everyday-backup-pgsql.sh
Содержимое:
#!/bin/bash
 # Задаем переменные:
 TIME=`date +»%Y-%m-%d_%H-%M»`
# Записываем информацию о начале бэкапа в лог:
 echo «`date +»%Y-%m-%d_%H-%M-%S»` Start backup» >> /backup/pgsql-everyday-backup.log
# Бэкапим и архивируем. При бэкапе еще одной базы — копируем эту команду с заменой имени базы с учетом регистра.
 pg_dump -U postgres UPP | pigz > /backup/everyday/$TIME-UPP.sql.gz
# Загружаем данные на Яндекс.Диск
 cp /backup/everyday/$TIME-UPP.sql.gz /Yandex.Disk/everyday
# Записываем информацию о завершении бэкапа в лог:
 echo «`date +»%Y-%m-%d_%H-%M-%S»` End backup» >> /backup/pgsql-everyday-backup.log
# Удаляем файлы старше 5 дней с локального диска
 find /backup/everyday -type f -mtime +5 -exec rm -rf {} \;
# Удаляем файлы старше 3 дней с Яндекс.Диск.
 find /Yandex.Disk/everyday -type f -mtime +3 -exec rm -rf {} \;
Еженедельный скрипт:
mcedit /backup/everyweek-backup-pgsql.sh
Содержимое:
#!/bin/bash
# Задаем переменные:
TIME=`date +»%Y-%m-%d_%H-%M»`
# Записываем информацию о начале бэкапа в лог:
echo «`date +»%Y-%m-%d_%H-%M-%S»` Start backup» >> /backup/pgsql-everyweek-backup.log
# Бэкапим и архивируем. При бэкапе еще одной базы — копируем эту команду с заменой имени базы с учетом регистра.
pg_dump -U postgres UPP | pigz > /backup/everyweek/$TIME-UPP.sql.gz
# Загружаем данные на Яндекс.Диск
cp /backup/everyweek/$TIME-UPP.sql.gz /Yandex.Disk/everyweek
# Записываем информацию о завершении бэкапа в лог:
echo «`date +»%Y-%m-%d_%H-%M-%S»` End backup» >> /backup/pgsql-everyweek-backup.log
# Удаляем файлы старше 3 дней с локального диска
find /backup/everyweek -type f -mtime +3 -exec rm -rf {} \;
# Удаляем файлы старше 2 дней с Яндекс.Диск.
find /Yandex.Disk/everyweek -type f -mtime +2 -exec rm -rf {} \;
Ежемесячный скрипт:
mcedit /backup/everymonth-backup-pgsql.sh
Содержимое:
#!/bin/bash
# Задаем переменные:
TIME=`date +»%Y-%m-%d_%H-%M»`
# Записываем информацию о начале бэкапа в лог:
echo «`date +»%Y-%m-%d_%H-%M-%S»` Start backup» >> /backup/pgsql-everymonth-backup.log
# Бэкапим и архивируем. При бэкапе еще одной базы — копируем эту команду с заменой имени базы с учетом регистра.
pg_dump -U postgres UPP | pigz > /backup/everymonth/$TIME-UPP.sql.gz
# Загружаем данные на Яндекс.Диск
cp /backup/everymonth/$TIME-UPP.sql.gz /Yandex.Disk/everymonth
# Записываем информацию о завершении бэкапа в лог:
echo «`date +»%Y-%m-%d_%H-%M-%S»` End backup» >> /backup/pgsql-everymonth-backup.log
# Удаляем файлы старше 2 дней с локального диска
find /backup/everymonth -type f -mtime +2 -exec rm -rf {} \;
# Удаляем файлы старше 1 дней с Яндекс.Диск.
find /Yandex.Disk/everymonth -type f -mtime +1 -exec rm -rf {} \;
Даём скриптам права на запуск:
chmod 0700 /backup/everyday-backup-pgsql.sh

chmod 0700 /backup/everyweek-backup-pgsql.sh
chmod 0700 /backup/everymonth-backup-pgsql.sh
Для временного хранения архивных копий создадим соответствующие папки everyday, everyweek, everymonth:
mkdir /backup/everyday
mkdir /Yandex.Disk/everyday
mkdir /backup/everyweek
mkdir /Yandex.Disk/everyweek
mkdir /backup/everymonth
mkdir /Yandex.Disk/everymonth
Так как системный раздел небольшой, перенесем папку Yandex.Disk в backup:
mv /Yandex.Disk /backup
Создадим символьную ссылку:
ln -s /backup/Yandex.Disk /Yandex.Disk
Так как системный раз
Добавим задание в crontab:
mcedit /etc/crontab

Добавим расписание резервного копирования:
# Выгрузка БД в будние дни в полночь
00 00 * * 1 root /backup/everyday-backup-pgsql.sh
00 00 * * 2 root /backup/everyday-backup-pgsql.sh
00 00 * * 3 root /backup/everyday-backup-pgsql.sh
00 00 * * 4 root /backup/everyday-backup-pgsql.sh
00 00 * * 5 root /backup/everyday-backup-pgsql.sh
# Выгрузка БД каждое воскресенье в полночь
30 0 * * 7 root /backup/everyweek-backup-pgsql.sh
# Выгрузка БД каждое 1-ое число месяца в 00:30
0 1 1 * * root /backup/everymonth-backup-pgsql.sh
В файле cron’а должна быть последняя пустая строка. Если файл cron’а редактировали во внешнем редакторе, тогда делаем:
crontab -e
В нем пишем:
:w
:q
Обновлено 9 апреля 2019 года
!!! Важно для пользователей УПП 1.3, КА 1.1 и тех чей CF больше 1ГБ
Спустя время, обнаружил не регулярное создание архивных копий базы данных.
При выполнении скрипта everyday-backup-pgsql.sh получил ошибку:
pg_dump: Ошибка выгрузки таблицы "config": сбой в PQgetResult().
pg_dump: Сообщение об ошибке с сервера: ОШИБКА:  invalid memory alloc request size 1146779163
pg_dump: Выполнялась команда: COPY public.config (filename, creation, modified, attributes, datasize, binarydata) TO stdout;


Ошибка связана с тем, что PostgreSQL имеет ограничение 1Gb для одного поля, а 1С хранит конфигурацию БД в одном поле.
Подобная проблема не встречается если конфигурация типовая, так как её размер обычно не превышает 500-600 Мб. Но стоит внести изменения в конфигурацию — её размер становится больше 1 Гб. По крайней мере это справедливо для конфигураций УПП 1.3 (управление производственным предприятием) и КА 1.1 (комплексная автоматизация). В этом можно убедится, ну или опровергнуть, сохранив файл конфигурации. Если размер CF-ника свыше 1Гб — скорее всего мы не сможем воспользоваться pg_dump для создания архивной копии нашей БД.
Для выхода из этого положения необходимо снять с поддержки нашу конфигурацию. Обновления делать на файловой копии БД или SQL-копии, предварительно поставив на поддержку. После обновления копии нашей базы сохраняем конфигурацию и путём сравнения и объединения обновляем рабочую базу.
Восстановление базы данных из резервной копии (бэкапа)
После создания резервной копии, можем проверить, восстанавливается ли из нее база данных.
Первым делом разархивируем файл:
unpigz -c /backup/everyday/YYYY-mm-dd_HH-MM-UPP.sql.gz > UPP.sql
Так как настоятельно не рекомендуется восстанавливать копию в рабочую базу, то создадим на сервере новую базу данных, в которую будем восстанавливать резервную копию. Перед этим посмотрим список баз данных на сервере:
# psql -U postgres -l
Создаем новую базу данных upp-temp:
# createdb --username postgres -T template0 upp-temp
В созданную базу данных загрузим резервную копию:
psql -U postgres upp-temp < /backup/everyday/UPP.sql
После завершения  восстановления, в консоле кластера 1С добавим новую базу. В качестве базы postgresql укажем созданную базу с загруженной копией.
Обновление статистики и реиндексация в PostgreSQL
Настроим регламентные операции в PostgreSQL для предотвращения падения производительности базы данных.
Будем выполнять очистку и анализ базы данных, а также реиндексацию ее таблиц.
Оформим регламентные операции в виде скрипта и будем исполнять его по расписанию.
Создадим скрипт everyday-service-pgsql.sh:
mcedit /backup/everyday-service-pgsql.sh
Запишем в него следующее содержимое:
#!/bin/sh
# Записываем информацию о начале очистки БД в лог
echo «`date +»%Y-%m-%d_%H-%M-%S»` Start vacuum» >> /backup/service.log
# Выполняем очистку и анализ базы данных
/usr/bin/vacuumdb —full —analyze —username postgres —dbname UPP
# Записываем информацию об окончании очистки БД в лог
echo «`date +»%Y-%m-%d_%H-%M-%S»` End vacuum» >> /backup/service.log
# Ставим на паузу выполнение скрипта на 10 секунд
sleep 10
# Записываем информацию о начале переиндексации таблиц БД в лог
echo «`date +»%Y-%m-%d_%H-%M-%S»` Start reindex» >> /backup/service.log
# Переиндексируем таблицы базы данных
/usr/bin/reindexdb —username postgres —dbname UPP
# Записываем информацию об окончании переиндексации таблиц БД в лог
echo «`date +»%Y-%m-%d_%H-%M-%S»` End reindex» >> /backup/service.log
Дадим скрипту право на запуск:
chmod 0700 /backup/everyday-service-pgsql.sh
Добавим исполнение данного скрипта в расписание cron. Осуществлять запуск будем ежедневно после резервного копирования, в данном случае на 2 часа ночи:
# Исполнение скрипта регламентных операций
 00 02 * * * root /backup/everyday-service-pgsql.sh
 
 
 
Поделиться ссылкой:
Похожее
Работа с бэкапами 1С средствами PostgreSQL
Как известно, сисадмины делятся на две категории, это те кто еще не делает бэкапы и кто уже делает. Из первой категории во вторую обычно попадают после какого-либо факапа или после пинка от более опытных коллег. Сегодня мы рассмотрим возможности бэкапирования базы 1С 8.3 средствами PostgreSQL. В качестве стенда используется сервер на centos 7 с postgresql-9.6.
Встроенный в платформу 1С механизм выгрузки/загрузки информационной базы имеет 2 минуса:
  • скорость выгрузки/загрузки
  • для его использования необходимо завершить все пользовательские сеансы
Это не всегда приемлемо, особенно когда база должна быть доступна в режиме 24/7/365 или размер базы таков, что выгрузка может продолжаться “вечность”. В таких случаях можно сохранять базу средствами СУБД. В MS SQL этот механизм достаточно прозрачен и прост, а вот на postgres есть несколько финтов, которые могут сделать наши бэкапы нежизнеспособными, что при определенном стечении обстоятельств может весьма плачевно сказаться на нашей работе.
PostgreSQL предоставляет нам достаточно обширные механизмы для создания бэкапов. Мы рассмотрим только один, но в двух вариациях.
Вариант 1 (Работа с бэкапами 1С средствами postgresql из терминала)
1.1 Создание бэкапа.
pg_dump --host localhost --port 5432 --username "postgres" --no-password --format custom --blobs --section pre-data --section data --section post-data --encoding UTF8 --verbose --file "~/MyBase.backup" "MyBase"
Два последних параметра ключевые в этой операции. Первый (–file) отвечает за место куда мы сохраняем файл бэкапа, второй – база которую мы бэкапим.
1.2 Загрузка базы из бэкапа.
pg_restore --host localhost --port 5432 --username "postgres" --dbname "CopyMyBase" --role "postgres" --no-password --section pre-data --section data --section post-data --verbose "~/MyBase.backup"

Стоит обратить внимание на один момент. В параметре –dbname мы указываем имя базы, куда загружать наш дамп. На момент загрузки она уже должна быть создана на вашем сервере и она должна быть пустая. Если заливать бэкап в непустую базу, то данные существующей базы просто дополнятся данными из бэкапа.
Вариант 2 (Работа с бэкапами 1С средствами postgresql с использованием pg_admin)
2.1 Создаем бэкап, по шагам:
  1. Выбираем нашу базу в pg_admin и в контекстном меню выбираем “Резервная копия…”
  2. Заполняем следующие параметры:
    1. Имя файла
    2. Формат: Настраиваемый
    3. Кодировка: UTF8
    4. pre-data
    5. Data (Данные)
    6. Post-data
    7. Blobs
  3. Нажимаем кнопку “Резервная копия”
2.2 Загрузка базы из бэкапа
  1. Выбираем базу куда мы заливаем бэкап в pg_admin и в контекстном меню выбираем “Восстановить…”
  2. Заполняем следующие параметры:
    1. Имя файла
    2. Pre-data
    3. Data (Данные)
    4. Post-data
  3. Нажимаем на кнопку “Восстановить”
 
После восстановления у меня выдается ошибка, но база создана и приподключении к ней из 1С база работает, поэтому по возможности лучше использовать вариант 1.
Спасибо за внимание, надеюсь что эта небольшая статья вам помогла, буду рад комментариям.
Поделиться ссылкой:
Понравилось это:
Нравится Загрузка…
Похожее
 1 8.3 PostgreSQL 11.5 
 PostgreSQL (MSSQL). ,,,. ,.
,,. postgrespro.ru
 pg_dump — Postgres: https://postgrespro.ru/docs/postgrespro/11/app-pgdump
 pg_restore — Postgres: https://postgrespro.ru/docs/postgrespro/11/app-pgrestore.html
  1. 1 8.3 PostgreSQL. 
 Бат- ()
 REM //////////////////////////////////////////////// ///////////////////////////////// 
 РЭМ сибек 
 РЭМ 1С POSTGRESQL 
 CLS 
 ЭХО ВЫКЛ 
 CHCP 866 —  1251 Windows, 866 DOS 
 REM POSTGRESQL 
 УСТАНОВИТЬ PGBIN = C: \ Program Files \ PostgreSQL \ 11.5-7.1C \ bin \ 
 УСТАНОВИТЬ PGDATABASE = bdpostgre  — Postgre  
 УСТАНОВИТЬ PGHOST = localhost 
 УСТАНОВИТЬ PGPORT = 5432 
 УСТАНОВИТЬ PGUSER = postgres  — Postgre  
 УСТАНОВИТЬ PGPASSWORD = пароль  — Postgre 
 Батарея REM- () 
 % ~ d0 
 CD% ~ dp0
 REM LOG 
 SET DAT =% date: ~ 0,2 %% date: ~ 3,2 %% date: ~ 6,4%  —  
 SET DUMPFILE = D: \ 1C BackUp \% DAT% -сибек.pgsql.backup – 
 УСТАНОВИТЬ LOGFILE = D: \ 1C BackUp \% DAT% -sibek.pgsql.log  —  
 SET DUMPPATH = «% DUMPFILE%» 
 SET LOGPATH = «% LOGFILE%»
 REM () 
 ВЫЗОВ «% PGBIN% \ pg_dump.exe» —format = custom —verbose —file =% DUMPPATH% 2>% LOGPATH%
 REM (), 
 ЕСЛИ НЕ% ERRORLEVEL% == 0 GOTO Error 
 GOTO Successfull 
 REM 
 : Ошибка 
 DEL% DUMPPATH% 
 MSG * «.backup_sibek.log. «
 ECHO% DATETIME%% DUMPFILE%. %ЖУРНАЛЬНЫЙ ФАЙЛ%. >> backup_sibek.log 
 GOTO End
 REM 
 : Успешно 
 ECHO% DATETIME%% DUMPFILE% >> backup_sibek.log 
 GOTO End 
 : Конец
 REM 5, 
 FORFILES / p «D: \ 1C BackUp \» / s / m *. * / D -5 / c «CMD / c del / Q @FILE»
 ! () … 
 летучая мышь-, летучая мышь- (2-3),.
  2. 
:  -> ->  » ,  . 
  
   (летучая мышь),
.
, г.
  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.
 1 PostgreSQL: //infostart.ru/public/1180438/
 .
 PostgreSQL Windows 
 PostgreSQL .bat.
:
 6 — «pgdump.exe»
 7 — (базовое имя)
 8 —
 9 —
 10 — корень PostgreSQL (postgres)
 11 — корень (Pa $$ слово)
 19 — (\\ 192.168.0.242 \ резервная копия \ buhgalteria \% DUMPFILE%) ()
 20 — (\ 192.168.0.242 \ резервная копия \ журналы \% LOGFILE%)
 35 — (log_basename.log) .bat,.
 1 
 2 
 3 
 4 
 5 
 6 
 7 
 8 
 9 
 10 
 11 
 12 
 13 
 14 
 15 
 16 
 17 
 18 
 19 
 20 
 21 
 22 
 23 
 24 
 25 
 26 
 27 
 28 
 29 
 30 
 31 
 32 
 33 
 34 
 35 
 36 
 37 
 38		  REM POSTGRESQL  
  CLS  
  ECHO OFF  
  CHCP 1251  
  REM  
    SET PGBIN = C: \ Program Files (x86) \ PostgreSQL \ 9.3.4-1.1C \ bin    
          SET PGDATABASE = crm3    
          SET PGHOST = localhost    
          УСТАНОВИТЬ PGPORT = 5432    
          УСТАНОВИТЬ PGUSER = postgres    
          УСТАНОВИТЬ ПАРОЛЬ bat = RSqw12Ma100
02 68  
 % ~ d0  
  CD% ~ dp0  
  REM -  
  SET DATETIME =% DATE: ~ 6,4% -% DATE: ~ 3,2% -% DATE: ~ 0,2%% ВРЕМЯ: ~ 0,2% -% ВРЕМЯ: ~ 3,2% -% ВРЕМЯ: ~ 6,2%  
  SET DUMPFILE =% PGDATABASE%% DATETIME%.резервная копия  
  SET LOGFILE =% PGDATABASE%% DATETIME% .log  
    SET DUMPPATH =       "m: \ kino-market% DUMPFILE%"    
          SET LOGPATH =       "m: \ logs \ kino-market% LOGFILE%"    
  REM  
  ЕСЛИ НЕ СУЩЕСТВУЕТ Backup MD Backup  
  CALL   "% PGBIN% \ pg_dump.exe "  --format = custom --verbose --file =% DUMPPATH% 2>% LOGPATH%  
  REM  
  ЕСЛИ НЕ% ERRORLEVEL% == 0 GOTO Error  
  GOTO Successfull  
  REM  
 : ошибка  
  DEL% DUMPPATH%  
  MSG *   ". backup.log. " 
  ECHO% DATETIME%% DUMPFILE%.% LOGFILE%. >> backup.log  
  GOTO End  
  REM  
 : Успешно  
    ECHO% DATETIME% DUMPFILE % >> резервное копирование.журнал    
  GOTO Конец  
 : Конец  
  пауза 
 P.S. («14»):
 1  forfiles -p   ""   -s -m *. * -D -14 -c   "cmd / c del / F / q @path" 
 .
 Как сделать резервную копию и восстановить базу данных PostgreSQL в Windows 
 Postgres предлагает три принципиально разных подхода к резервному копированию данных:
  •  SQL-дамп (или логический)
  •  Резервное копирование на уровне файловой системы (или физическое)
  •  Непрерывное архивирование (или восстановление на момент времени)
 Давайте обсудим эти методы один за другим, но если вы предпочитаете инструменты с графическим интерфейсом, вы можете использовать наше бесплатное приложение для создания резервных копий базы данных, которое, по сути, является мощной оболочкой для pg_dump, которая создает дампы SQL.
 Как создать файл дампа PostgreSQL 
 В Postgres для извлечения базы данных в файл сценария или другой архивный файл используется утилита pg_dump. Важным преимуществом этой утилиты является то, что вы можете восстанавливать ее дампы на более новых версиях PostgreSQL или на машинах с другой архитектурой. Другие методы резервного копирования, такие как резервное копирование на уровне файлов и непрерывное архивирование, привязаны к конкретной версии и архитектуре сервера.
 Самый простой способ использования этой команды:
 pg_dump  имя_базы_данных >  база данных.sql  
 или:
 pg_dump  имя_базы_данных  -f  database.sql  
 Эта команда создает файл SQL, содержащий команды, необходимые для воссоздания базы данных в том же состоянии, в котором она была во время резервного копирования.
 Если вы получили ошибку «pg_dump» не распознается как внутренняя или внешняя команда », добавьте путь к каталогу bin PostgreSQL в переменную среды PATH (в моем случае это« C: \ Program Files \ PostgreSQL \ 11 \ bin » ). Вариант для изменения переменной среды — это запуск команды с полным путем, например:
 «C: \ Program Files \ PostgreSQL \ 11 \ bin \ pg_dump»  имя_базы_данных > база данных .sql  
 Команда должна запускаться пользователем с полномочиями на чтение всей информации базы данных. Если у вашего пользователя Windows недостаточно прав для вашей базы данных, вы можете запустить эту команду от пользователя Postgres:
 pg_dump -U postgres  имя_базы_данных >  database.sql  
 Запуск pg_dump в пакетном режиме (автоматически) 
 Если вы планируете автоматическое резервное копирование базы данных, тогда вам может потребоваться избавиться от запроса пароля. Это будет полезно, если вы запускаете резервное копирование в пакете или сценариях, где нет пользователя, чтобы ввести пароль.Вы можете сделать это, назначив пароль переменной PGPASSWORD:
 SET PGPASSWORD =  my_password  pg_dump -U postgres  имя_базы_данных> database.sql  
 В качестве альтернативы, если вы не хотите хранить пароль в командного файла, вы можете поместить учетные данные в% APPDATA% \ postgresql \ pgpass.conf в следующем формате:
 имя хоста: порт: база данных: имя пользователя: пароль 
 Звездочки могут заменить имя хоста и базу данных.
 Следующие команды создадут каталог и добавят запись в файл одним пакетом:
 cd% appdata% mkdir postgresql cd postgresql echo localhost: 5432:  my_database : postgres:  my_password  >> pgpass.conf 
 Резервное копирование удаленного сервера 
 Если вам нужно создать резервную копию удаленного сервера, добавьте параметры -h и -p:
 pg_dump -h  host_name  -p  port_number database_name >  database.sql  
 If ваша схема базы данных содержит OID (например, внешние ключи), вы должны сделать так, чтобы pg_dump сбрасывал OID, используя параметр -o. Если ваше приложение никак не ссылается на столбцы OID, этот параметр не следует использовать.
 Резервное копирование одной таблицы 
 Для создания дампа одной таблицы используйте опцию -t:
 pg_dump -t  table_name database_name >  table.sql  
 В этом случае pg_dump не будет выгружать другие объекты базы данных, связанные с выбранной таблицей. Это означает, что нет гарантии, что вы сможете без ошибок восстановить этот дамп на чистой базе данных.
 В старых (до 8.2) версиях PostgreSQL -t  имя_таблицы  выводит все таблицы с указанным именем. Современные движки Postgres сбрасывают все, что видно на пути поиска по умолчанию. Если вы хотите вернуться к старому поведению, вы можете написать -t  «*.table_name ».
 Кроме того, вы должны написать что-то вроде -t  имя_схемы.имя_таблицы , чтобы выбрать таблицу определенной схемы вместо старых параметров, например -n  имя_схемы  -t  имя_таблицы .
 Сжатие сценария резервного копирования 
 Если вам нужно сжать выходной файл, вы должны использовать параметр -Z:
 pg_dump -Z6  имя_базы_данных >  database.gz  
 Эта команда заставляет весь выходной файл быть сжат, как если бы он был пропущен через gzip, со степенью сжатия, равной 6 (может варьироваться от 0 до 6).
 Другой вариант получения файла резервной копии меньшего размера — использование пользовательского формата файла при резервном копировании.
 Как восстановить файл дампа PostgreSQL 
 Поскольку текстовые файлы, сгенерированные pg_dump, содержат набор команд SQL, их можно передать в утилиту psql. Сама база данных не будет создана psql, поэтому вы должны сначала создать ее самостоятельно из template0. Итак, общая форма команды для восстановления дампа:
 createdb -T template0  имя_базы_данных  psql  имя_базы_данных  < база данных.sql  
 Перед тем, как приступить к восстановлению дампа SQL и воссозданию объектов с исходным владельцем и / или разрешениями, крайне важно убедиться, что все пользователи, которым предоставлены разрешения на объекты, или владеющие объектами в загруженных база данных уже существует. В противном случае процесс восстановления не удастся.
 Восстановление удаленной базы данных 
 Если вам нужно восстановить базу данных на удаленном сервере, вы можете подключить к нему psql с помощью параметров -h и -p:
 psql -h  имя_хоста  -p  номер_порта имя_базы_данных  < база данных.sql  
 Можно выполнить дамп базы данных напрямую с одного сервера на другой благодаря способности pg_dump и psql писать в каналы или читать из них, например:
 pg_dump -h  source_host имя_базы_данных  | psql -h  host_host имя_базы_данных  
 Эта команда скопирует базу данных:
 createdb -T template0  new_database  pg_dump  existing_database  | psql  new_database  
 Обработка ошибок 
 Если возникает ошибка SQL, сценарий psql продолжает выполняться; это по умолчанию.Такое поведение можно изменить, запустив psql с переменной ON_ERROR_STOP, и если обнаружится ошибка SQL, psql выйдет со статусом выхода 3.
 psql --set ON_ERROR_STOP = on  database_name  < database.sql  
 В случае ошибки вы получите частично восстановленную базу данных. Чтобы избежать этого и завершить восстановление, либо полностью успешное, либо с полным откатом, настройте восстановление всего дампа как одной транзакции. Для этого используйте параметр -1 в psql:
 psql --set ON_ERROR_STOP = on -1  имя_базы_данных  < база данных.sql  
 Как сделать резервную копию нескольких баз данных PostgreSQL одновременно 
 Pg_dump может выгрузить только одну базу данных за раз, и информация о табличных пространствах или ролях не будет включена в этот дамп. Это происходит потому, что они предназначены не для каждой базы данных, а для всего кластера. Существует программа pg_dumpall, которая поддерживает удобный дамп всего содержимого кластера базы данных. Он сохраняет определения ролей и табличных пространств (данные в масштабе кластера) и выполняет резервное копирование каждой базы данных в данном кластере.pg_dumpall работает следующим образом: он испускает команды для воссоздания табличных пространств, пустых баз данных и ролей, а затем вызывает pg_dump для каждой базы данных. Хотя каждая база данных будет внутренне согласованной, моментальные снимки разных баз данных могут быть не полностью синхронизированы.
 В основном эта команда используется следующим образом:
 pg_dumpall>  all_databases.sql  
 Psql и опция -f могут использоваться для восстановления полученного дампа:
 psql -f  all_databases.sql  postgres 
 Независимо от того, к какой базе данных вы подключаетесь, файл сценария, созданный с помощью pg_dumpall, будет содержать все необходимые команды для создания и подключения к сохраненным базам данных.
 Как сделать резервную копию PostgreSQL в файл архива пользовательского формата 
 Хотя простой текстовый формат, создаваемый pg_dump, естественен и прост, в то же время он не очень гибкий, поскольку может создавать огромные выходные файлы. В качестве альтернативы PostgreSQL имеет небольшую приятную функцию, которая позволяет пользователям экспортировать так называемый «пользовательский формат», формат, который архивируется по умолчанию (без дополнительных действий) и обеспечивает значительную гибкость, особенно при повторном импорте.
 Для создания файла резервной копии в пользовательском формате дампа необходимо добавить параметр -Fc:
 pg_dump -Fc  имя_базы_данных >  database.dump  
 Этот формат файла необходимо использовать с pg_restore для восстановления базы данных. Это позволяет pg_restore выбирать, что восстанавливается, или даже переупорядочивать элементы перед восстановлением. Форматы архивных файлов предназначены для передачи между архитектурами.
 Чтобы восстановить пользовательский формат файла, используйте следующую команду:
 pg_restore -d  имя_базы_данных база данных.dump  
 Используя параметр -j, можно значительно сократить время восстановления большой базы данных на сервере, работающем на многопроцессорной машине. Это достигается за счет запуска наиболее трудоемких частей pg_restore, а именно тех, которые загружают данные, создают ограничения или создают индексы с использованием нескольких одновременных задач. Каждое задание представляет один поток или один процесс; он использует отдельное соединение с сервером и зависит от операционной системы. Например, эта команда восстановит базу данных в четырех параллельных заданиях:
 pg_restore -j 4 -d  database_name database.dump  
 Используйте следующее, чтобы удалить базу данных и воссоздать ее из дампа:
 dropdb  имя_базы_данных  pg_restore -C -d  имя_базы_данных database.dump  
 С параметром -C данные всегда восстанавливаются в базу данных имя, которое появляется в файле дампа.
 Выполните следующее, чтобы перезагрузить дамп в новую базу данных:
 createdb -T template0  имя_базы_данных  pg_restore -d  имя_базы_данных database.dump  
 Другие форматы резервного копирования PostgreSQL 
 pg_dump предоставляет два других формата выходных файлов: каталог и деготь.Оба они восстанавливаются утилитой pg_restore.
 Для создания архива в формате каталога необходимо использовать параметр -Fd:
 pg_dump -Fd  имя_базы_данных  -f  database.dump  
 Будет создан каталог с одним файлом для каждой таблицы и выгруженным большим двоичным объектом , а также так называемый файл Table of Contents, который описывает скопированные объекты в машиночитаемом формате, который может читать pg_restore. Стандартные инструменты Unix могут использоваться для управления архивом формата каталогов; например, инструмент gzip можно использовать для сжатия файлов в несжатом архиве.Этот формат поддерживает параллельные дампы, по умолчанию сжатые.
 Формат tar совместим с форматом каталога: действительный архив в формате каталога создается при распаковке архива в формате tar. Однако формат tar не поддерживает сжатие. Кроме того, при использовании формата tar относительный порядок элементов данных таблицы не может быть изменен во время процесса восстановления.
 Чтобы создать файл tar, используйте параметр -Ft:
 pg_dump -Ft  имя_базы_данных  -f  база данных.tar  
 Как сделать резервную копию определений объектов базы данных 
 Время от времени возникает необходимость в резервном копировании только определений объектов базы данных, что позволяет восстановить только схему. Это может быть полезно на этапе тестирования, когда вы не хотите сохранять старые тестовые данные заполненными.
 Используйте следующую команду для резервного копирования всех объектов во всех базах данных, включая роли, базы данных, табличные пространства, таблицы, схемы, индексы, функции, триггеры, ограничения, привилегии, представления и владения:
 pg_dumpall --schema-only>  определения.sql  
 Используйте следующую команду для резервного копирования только определения роли:
 pg_dumpall --roles-only>  roles.sql  
 Используйте следующую команду для резервного копирования определения табличных пространств:
 pg_dumpall --tablespaces-only>  tablespaces.sql  
 Резервное копирование на уровне файловой системы 
 Альтернативная стратегия резервного копирования — прямое копирование файлов, которые PostgreSQL использует для хранения данных в базе данных. Можно использовать любой метод резервного копирования файловой системы, например:
 xcopy «C: \ Program Files \ PostgreSQL \ 11 \ data» «D: \ backup» / E 
 После этого вы сможете запустить новый сервер экземпляр с тем же именем выпуска в этой папке (обратите внимание, что вы должны запустить эту команду на уровне администратора):
 pg_ctl start -D «D: \ backup» 
 Этот метод дает вам следующие преимущества:
  •  Быстрее чем логическое резервное копирование (дамп SQL), такое же быстрое, как простое копирование файлов
  •  Резервное копирование всего экземпляра (кластера)
  •  Не вызывает конкуренции блокировок и не зависит от снятия блокировок другими соединениями
  •  Практически мгновенный процесс восстановления — нет необходимости выполнять операторы SQL для возврата данных
, и в то же время это подразумевает некоторые ограничения:
  •  Требует выключения базы данных
  •  Может быть восстановлен только на той же основной версии PostgreSQL
  •  Единая база данных es или отдельные таблицы не могут быть восстановлены: нужно восстановить все или ничего
  •  Создает очень большие резервные копии, поскольку они включают в себя все индексы и раздутие и, следовательно, могут быть намного больше, чем дампы SQL
 Непрерывное архивирование 
 Метод непрерывного архивирования сочетает резервное копирование на уровне файловой системы с резервным копированием файлов WAL (в котором хранятся все изменения, внесенные в файлы данных базы данных).Этот способ более сложен в администрировании, чем любой из предыдущих подходов, но он имеет ряд существенных преимуществ:
  •  Нет необходимости иметь идеально согласованную резервную копию файловой системы в качестве отправной точки. Воспроизведение журнала исправит любые внутренние несоответствия в резервной копии (это не имеет принципиального отличия от того, что происходит во время восстановления после сбоя). Таким образом, вам не нужно создавать снимок файловой системы, просто tar или аналогичный инструмент архивирования.
  •  Непрерывное резервное копирование может быть достигнуто простым продолжением архивирования файлов WAL.Это особенно ценно для больших баз данных, где не всегда удобно выполнять полное резервное копирование.
  •  Нет необходимости полностью воспроизводить записи WAL до конца. Вы можете остановить воспроизведение в любой момент и получить согласованный снимок существующей базы данных. Таким образом, этот метод поддерживает так называемое «восстановление на определенный момент времени»: базу данных можно восстановить до ее состояния в любое время с момента создания резервной копии базы данных.
  •  Если вы непрерывно загружаете серию файлов WAL на другую машину, на которой был загружен тот же базовый файл резервной копии, у вас будет система горячего резервирования: вторую машину можно запустить в любое время с почти текущей копией база данных.
 Как и простой метод резервного копирования файловой системы, этот метод может поддерживать восстановление только всего кластера базы данных, но не подмножества. Кроме того, для этого требуется большое архивное хранилище: базовая резервная копия может быть громоздкой, а загруженная система будет генерировать много мегабайт трафика WAL, который необходимо заархивировать. Однако это предпочтительный метод резервного копирования во многих ситуациях, когда требуется высокая надежность.
 Мы не будем рассматривать весь процесс настройки непрерывного архивирования, так как он исчерпывающе описан в документации.
 Как сделать резервную копию базы данных PostgreSQL с помощью SQLBackupAndFTP 
 Если вы предпочитаете графический интерфейс для управления резервными копиями, вы можете попробовать нашу бесплатную утилиту под названием SQLBackupAndFTP. Внутреннее использование pg_dump добавляет больше удобства и кучу других полезных функций, таких как:
  •  выполнение резервного копирования по расписанию
  •  уведомление вас, если что-то пошло не так
  •  отправка вашей резервной копии в один из известных сервисов облачного хранения (например, Dropbox, Google Диск, Amazon S3 и т. Д.)
  •  шифрование архива
  •  резервное копирование файлов
  •  поддержка баз данных SQL Server, My SQL и Azure
 Начать работу с SQLBackupAndFTP довольно просто. После загрузки и установки подключите его к базе данных PostgreSQL, нажав кнопку «Gear» в разделе «Подключиться к серверу базы данных». Во всплывающем окне выберите PostgreSQL (TCP / IP) в качестве типа сервера, затем укажите логин / пароль. После этого нажмите «Проверить соединение», чтобы проверить, все ли в порядке, и нажмите «Сохранить и закрыть», чтобы применить все настройки:
 Затем вам нужно выбрать базы данных, которые вы хотите сделать резервную копию, щелкнув шестеренку в разделе «Выбрать». Раздел «Базы данных»:
 После этого выберите место назначения, куда будут отправляться резервные копии базы данных PostgreSQL, щелкнув значок «плюс» в разделе «Хранить резервные копии в выбранных местах назначения».
 Вы можете отправить резервную копию в следующие облачные хранилища: локальная или сетевая папка, FTP-сервер, Amazon S3, Dropbox, Google Drive, OneDrive, Box, хранилище Azure, OneDrive, для бизнеса, Backblaze B2, Яндекс Диск:
 Если вы хотите запустить резервное копирование по расписанию, вам необходимо настроить план резервного копирования. Сделать это можно следующим образом: включите переключатель рядом с заголовком «Расписание резервного копирования» и нажмите кнопку «Шестеренка», чтобы получить доступ к расширенным настройкам расписания резервного копирования:
 Это все.Если вам нужно создать резервную копию прямо сейчас, нажмите «Запустить сейчас»:
. При необходимости, если вам нужно применить некоторые параметры pg_dump, вы можете прокрутить вниз, щелкнуть «Дополнительные настройки…», а затем «Дополнительные настройки…» снова в раздел «Параметры резервного копирования». Это даст вам следующее окно с несколькими быстрыми параметрами и возможностью добавить свои собственные:
 Как восстановить базу данных PostgreSQL с помощью SQLBackupAndFTP 
 Есть два способа восстановить ранее созданную резервную копию с помощью SQLBackupAndFTP:
  •  Из истории & восстановить », если резервная копия была создана с помощью SQLBackupAndFTP
  •  С помощью« Задания восстановления », если резервная копия была создана другими способами, скорее всего, непосредственно с помощью утилиты pg_dump
 В первом случае вам нужно найти резервную копию вы хотите восстановить в разделе «История и восстановление» главного окна, щелкните значок с тремя точками и выберите «Восстановить из резервной копии»: вы увидите всплывающее окно, в котором вам нужно выбрать, из какой базы данных вы хотите восстановить, на следующем снимке экрана есть только одна опция: на последнем шаге у вас будет возможность изменить имя базы данных (если вы не хотите перезаписывать существующую базу данных) и указать проход архива word (если вы настроили его при создании архива):
 Как восстановить произвольный дамп SQL с помощью SQLBackupAndFTP 
 Если у вас есть произвольный дамп PostgreSQL из резервной копии базы данных, который вы хотите восстановить на этой машине, вы можете воспользоваться функцией «Восстановить задание», доступной в SQLBackupAndFTP.Это задание берет дамп SQL из облачного хранилища и восстанавливает его в выбранной базе данных. Процедура настройки такого задания аналогична созданию резервных копий.
 Создайте «задание восстановления», нажав «Задание»> «Добавить новое задание восстановления»:
 Выберите место, где находится ваша резервная копия:
 В разделе «Хранить базы данных для восстановления» выберите резервную копию, которая должна быть восстановленным:
 Подключитесь к серверу PostgreSQL в разделе «Восстановление на сервер базы данных»:
 Теперь, когда вся подготовка завершена, восстановите резервную копию, нажав кнопку «Выполнить сейчас»:
.
No related posts.

Share :

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *