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

Публикация № 540298

Администрирование - Архивирование (backup)

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

47
Алгоритм резервного копирования баз 1С: 8 средствами PostgreSQL.

В интернете куча статей, как установить PostgreSQL и залить в него базу из dt.

Но столкнулся с проблемой резервного копирования и восстановления базы средствами PostgreSQL.

т.е.  при восстановлении базы сыпались ошибки, и восстановленная копия базы не работала.

Ошибочный алгоритм.

1. Делаем резервную копию скриптом или с помощью pgAdmin III --- получаем файлик bkp...

2. Создаем пустую базу средствами 1С сервера.

3. Восстанавливаем резервную копию скриптом или с помощью pgAdmin III в базу, созданную на шаге 2.

и болт : во время восстановления уже видны ошибки и восстановленая копия получается не рабочая (в конфигуратор пускает, но в предприятие уже не войти, "ошибка аутентификации пользователя" и т.п.)

Правильный алгоритм.

1. Делаем резервную копию скриптом или с помощью pgAdmin III --- получаем файлик bkp...

Пример командного файла :

"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 "c:\1c_base.backup" "1c_base"

pause

где   "1c_base"  - имя базы

       "c:\1c_base.backup"  - имя файла резервной копии

2. Создаем пустую базу средствами Postgre - Я делал pgAdmin III -ом. (и пока не добавляем ее через "Администрирование сервера 1С" )

пустую базу можно создать командой CREATE DATABASE https://www.postgresql.org/docs/9.1/static/sql-createdatabase.html

3. Восстанавливаем резервную копию скриптом или с помощью pgAdmin III в базу созданную на шаге 2.

Пример командного файла :

"C:\Program Files\PostgreSQL\9.4.2-1.1C\bin\pg_restore.exe" --host localhost --port 5432 --username "postgres" --dbname "1c_base_copy" --role "postgres" --no-password  --section pre-data --section data --section post-data --verbose "C:\ 1c_base.backup"

pause

где   "1c_base_copy"  - имя пустой базы, созданой в шаге 2 средствами PostgreSQL

       "c:\1c_base.backup"  - имя файла резервной копии

4. Добавляем базу созданную на шаге 2 с  восстановленной информацией в список баз на сервере 1С через остнастку "Администрирование сервера 1С".

Вот и все !!! Всем удачного дня !!!

47

См. также

Специальные предложения

Вознаграждение за ответ
Показать полностью
Комментарии
Избранное Подписка Сортировка: Древо
2. dimisa 110 01.08.16 17:02 Сейчас в теме
(1) lustin,
Зачем так сложно ?
cmd - файл в задания под какой нибуть локальной админской записью.
3. cssprite 25 02.08.16 08:21 Сейчас в теме
http://postgresql.ru.net/manual/backup-dump.html

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

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

где файл_дампа — это файл, содержащий вывод команды pg_dump. База данных, заданная параметром имя_БД не будет создана данной командой, так что вы должны создать её сами из базы template0 перед запуском psql (например, с помощью команды createdb -T template0 имя_БД)
neyasytyf; cleaner_it; +2 Ответить
4. oldcopy 120 03.08.16 10:46 Сейчас в теме
Ещё следует уточнить что кодировка дампа должна совпадать с кодировкой сервера БД.
cleaner_it; +1 Ответить
5. freeraider 23 05.08.16 06:38 Сейчас в теме
PostgreSQL не восстанавливает текущую базу из дампа.
Поэтому, я восстанавливаю базу так:
dropdb имя_базы
createdb имя_базы
psql имя_базы < файл_дампа

Мой скрипт восстановления для Linux (работает под пользователем postgres):

#!/bin/bash

if [ -z "$1" ] ; then
echo "Скрипт восстановления базы 1С. Параметры: 1 имя директории бэкапа, 2 имя базы 1С" 1>&2
exit
fi

base_name="$2"
dir_name="$1"

archive_name=$dir_name/$base_name.sql.gz

dropdb $base_name
createdb $base_name
gunzip -c $archive_name | psql $base_name
6. zazabadak 02.09.16 12:11 Сейчас в теме
У нас с восстановлением базы из дампа проблем вроде не вылезает, не ругается:
dropdb -U postgres [имя базы]
createdb -U postgres [имя базы]
pg_restore -U postgres -d [имя базы] [имя файла]
7. Seltick 31.05.17 22:12 Сейчас в теме
Для разграничения архивов по дням: namebase_backup_%date:~6,4%-%date:~3,2%-%date:~0,2%.backup

Если у пользователя установлен пароль: SET PGPASSWORD=123

Готовый скрипт:

SET PGPASSWORD=123

"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 "D:\1cBackupNew\ut11_backup_%date:~6,4%-%date:~3,2%-%date:~0,2%.backup" "ut11"
Daseraf; frkbvfnjh; dimisa; +3 Ответить
11. frkbvfnjh 510 10.01.18 06:48 Сейчас в теме
(7) Можно ли этим способом делать бэкап базы не выгоняя пользователей из базы?
12. der_mensch 10.01.18 10:47 Сейчас в теме
(11) Можно. В документашке прямо так и заявлено:
pg_dump — это программа для создания резервных копий базы данных Postgres Pro. Она создаёт целостные копии, даже если база параллельно используется. Программа pg_dump не препятствует доступу других пользователей к базе данных (ни для чтения, ни для записи).
alexfps79; +1 Ответить
13. frkbvfnjh 510 10.01.18 12:11 Сейчас в теме
14. xmolex 12 19.06.18 17:52 Сейчас в теме
(11)
м делать бэкап базы не выг

Нет, нельзя. Одна операция в 1с меняет данные во многих sql таблицах. Бэкап базы существеннен по времени и у вас нет гарантии, что данные за это время не изменятся. Вы сделаете несколько бэкапов и они будут рабочие, но однажды попадете на восстановление данных.
15. t.v.s. 93 19.06.18 18:18 Сейчас в теме
(14) Не вводите людей в заблуждение.
Не только можно, но и в большинстве случаев это единственный вариант. Например если база весит пару терабайт, работает 24/7/365 и каждый час простоя стоит N килобаксов.
А по поводу длительности операции - там снэпшот создается, так что итоговый бэкап получается вполне себе консистентным.
16. xmolex 12 20.06.18 09:24 Сейчас в теме
(15)
там снэпшот создается, так что итоговый бэкап полу

Не знаю как насчет терабайт, а вот с базой 300Гб (select pg_database_size('base');), которая используется 24/7/365, я сначала был такого же мнения как и вы. Бэкап делался минут 40, в течении которых пользователи плевались и матерились, т.к. предприятие тормозило еще как. Так вот в один прекрасный день, когда неудачно прошло обновление конфигурации и база отказалась запускаться, пришлось воспользоваться самым свежим бэкапом, сделанным таким путем, и каково же было мое недоумение, когда он загрузился без проблем, но при открытии в 1с счет фактур предприятие вылетало. Вы можете возразить, что мол кеши надо было чистить, но все это конечно было сделано. Сейчас система переделана. Два сервера: один мастер, другой слейв. Когда нужно сделать бэкап, слейв теряет соединение с мастером, к нему подключается сервер 1с предприятия и средствами 1с делают бэкап. После этого слейв подключается к мастеру и синхронизируется.
Снепшот может и создается (хотя не уверен, а проверять ваши слова лень), но это снепшот sql базы. А вот 1с в этот момент может что-то активно писать и поменять данные в 1 таблице sql, и тут произойдет снепшот sql, а еще в 10 таблицах не успеет поменять, хотя должна, чтобы поддерживать свою логику. Вы же знаете, что одно добавление в регистр записи, может запускать множество других регистраций и каждая из них будет запускаться как одна транзакция в sql. Поэтому данные в базе у вас обязательно испортятся. Возможно база у вас и загрузится и даже работать будет, но данные будут неполными и это аукнется позже.
17. alexbur 13 30.07.18 21:02 Сейчас в теме
(16), А есть уверенность, что в момент потери связи между серверами 1С были записаны все необходимые движения? Вы считаете что все движения, связанные с проведением документа в 1С происходят в одной 1С транзакции?
18. xmolex 12 31.07.18 16:03 Сейчас в теме
(17)
А есть уверенность, что в момент потери связи между серверами 1С были записаны все необходимые движения?

Я говорил про сервера postgresql, а не 1с. Уверенности конечно нет, но т.к. бэкап делается средствами 1с, то 1с при обнаружении испорченных данных в документе его просто не выгрузит в бэкап. В результате структура базы будет цела, правда за минусом документа.
19. alexbur 13 02.08.18 06:15 Сейчас в теме
(18)
Я говорил про сервера postgresql, а не 1с.

Ага, не понял вас сразу. То есть фактически плюсом этого решения является то, что боевая база не тормозит в момент бэкапа? Но вот в плане надёжности такого решения я испытываю сильные сомнения. В момент обрыва связи между серверами postgre вероятность потерять данные не меньше чем при снепшоте. То что потом бэкап делается средствами 1С не панацея. Сталкивался я со случаями, когда бэкап из dt не разворачивался из-за сбойных данных внутри.
8. Vovan58 40 05.06.17 00:52 Сейчас в теме
Рекомендую вот это описание : https://postgrespro.ru/docs/postgrespro/9.5/app-pgdump и https://postgrespro.ru/docs/postgrespro/9.6/app-pgrestore.html - вроде все понятно описано :) и по-русски!
9. fedor_b 03.10.17 18:07 Сейчас в теме
Спасибо помогло. Наступал на те же грабли.
10. edgi 02.11.17 13:27 Сейчас в теме
Так же создаю резервные копии как писали в коментах.
Но есть один вопрос. Иногда требуется срочно восстановить какую нибудь копию базы за определенный день. с командной строки я ее восстанавливаю в новую базу созданную посредством psql, но в 1ске то она не появиться надо вручную ее создать или с помощью 1с или через консоль администрирования 1с. А как через командную строку создать базу в 1с?
20. MulderCelica 20.10.18 07:44 Сейчас в теме
Хотелось бы рассказать про еще один "чудесный" способ передачи файла с дампом базы от облачного хостера 1С сервера. Возможно это сможет кому-то съэкономить часов 5 драгоценного времени, особенно для таких как я, которые за 15 лет работы с 1С - за ненадобностью postgre в глаза не видели, да и с линуксообразными тоже не особо.

Речь пойдет про Windows платформу, а именно server 2012.
Съезжая с хостинга клиент попросил отдать ему выгрузку базы 1С. В итоге со словами "Вот, могу отдать только SQL дамп. Но без СУБД вы все равно ничего не сможете сделать" - прилетает архив размером 700 мег формата bla_bla_bla_UT11.sql.gz
SQL дамп это прекрасно, подумал я, запуская SQL management studio...
Распаковав это хозяйство получил 1,5 гиг файл формата .sql
Попытки подпихнуть это в MS SQL успехом не увенчались.
Пришлось первый раз разбираться с postgre. Последняя на текущий момент версия была 10, но так как ей нужна была платформа не ниже 8.3.14 - была отправлена в корзину.
Поставил 9.6.7 с сайта 1С.
Ставится запуском postgresql-9.6.7-1.1C(x64).msi все параметры по умолчанию, предлагает указать некий пароль (даже не показывая к какому юзеру/уч.записи он относится), не менее 4х знаков, и после инсталляции запускает Stack Builder который предлагает поставить кучу какого-то не нужного барохла. Закрыл ничего не инсталлируя. pgAdmin 4 это адовая программа, которая открылась всего два раза. Сначала я создал там базу, выбрал в меню "восстановить из бекапа". Меня отправили прописывать какие то пути к скриптам. Что за (...) - тебе же указали пути при установке! Но нет, надо что-то там в настройках указать. кое как нашел настройки. Попутно хочется добавить, что через 5 минут вглядывания в интерфейс этого ... у меня стали болеть глаза. Я почувствовал себя пользователем Windows 3.11 , ни больше ни меньше. Заодно поменял языковую опцию на русский. Это, видимо, было ошибкой - после этого надо было рестартовать сервис, и больше pgAdmin-4 не запустился ни разу. Ну ничего, рядом в папке \bin валялась 3я версия этой чудесной программы. Она всё же согласилась работать, но архив мой открывать и грузить никак не хотела. Кнопка "Загрузить" так активной и не стала.
перерыл кучу всевозможной информации, нашел массу примеров скриптов, которые то запускают pg_restore то psql , причем принципиально понять почему одни используют одно, а другие другое - я никак не мог. Но у всех в примерах дампы были формата *.backup и с моим файлом это никак не хотело работать.
В итоге оказалось, что этот дамп - по сути текстовый набор sql инструкций, который создает таблички и постит туда данные. Некий набор запросов. Очень большой набор запросов.
В итоге строка запука восстановления стала выглядеть так:
C:\Program Files\PostgreSQL\9.6.7-1.1C\bin>psql pg_db_name < backup.sql

система спрашивает пароль, и что бы я ей не указывал - не пускает. Пароль при инсталляции, пароль от системной учетной записи админа, пустой пароль - всё равно валит ошибку
fe_sendauth: no password supplied

Что надо сделать чтобы это победить:
Надо найти файл pg_hba.conf в корневой директории установки ЭТОЙ СУБэДы, и найдя среди кучи закоментированного мусора, значимые - подправить пару строчек, указав в колонке METHOD вместо способа идентификации md5, просто trust
host all all 0.0.0.0/0 trust

Снова запускаем команду... И опять ошибка
psql: FATAL: role "vasily_pupkin" does not exist

Оказывается он пытается от имени текущей учетной записи windows что то сделать, и наличие у вас хоть прав администратора всея вселенная - его ничуть не смущают, вы всё равно идете лесом.
В итоге команда принимает следующий вид:
C:\Program Files\PostgreSQL\9.6.7-1.1C\bin>psql -U postgres pg_db_name < backup.sql
, где postgres это по сути SA.
И по экрану радостно побежали заголовки sql запросов... Заняло это минут 30.
Далее прописываем базу в консоле администрирования 1С, пользователь БД - postgres , пароль как раз тот что был при инсталляции.
Добавляем базу в список баз 1С.
И вот, к концу написания данного опуса - у меня на руках уже родимый .dt с которым уже чувствуешь себя хорошо. Работоспособность проверена.
eaa; addinaq; defini; goodwill; dimisa; acanta; +6 Ответить
21. PbI4 1 02.11.18 14:48 Сейчас в теме
А ни у кого не случается иногда такая ошибка при ресторе?

pg_restore: обрабатываются данные таблицы "public._usersworkhistory"
pg_restore: обрабатываются данные таблицы "public._yearoffset"
pg_restore: обрабатываются данные таблицы "public.config"
pg_restore: [внешний архиватор] не удалось прочитать входной файл: конец файла


При чём всегда после конфига и иногда рестор отрабатывает без ошибки на том же самом дампе
22. vsasav 421 05.12.18 09:58 Сейчас в теме
(21) https://infostart.ru/public/956734/ - вот здесь все подробно описал, в том числе и вашу ситуацию, когда архив выгружается с помощью --format custom. Сам наткнулся на эти грабли при выполнении команды pg_restore. Это означает, что pg_dump прерывался с ошибкой на таблице public.config, однако, файл архива был создан, и следует уже использовать мой метод.
Оставьте свое сообщение