Резервное копирование и восстановление БД 1С 8.3 на PostgreSQL 11.5

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

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

Postgre SQL резервирование восстановление копирование 8

Резервное копирование баз данных 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.

Пример Bat-файла с командами для резервирования (выделенные строки надо убрать)

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С Сервере и подключать к Postgre:

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

Во вложении Bat-файл для копирования 2 баз.

Как развернуть базу данных 1С на PostgreSQL можно почитать тут: //infostart.ru/public/1180438/

Скачать файлы

Наименование Файл Версия Размер
BackUp 1С 8.3 for POSTGRE 11.5

.bat 4,01Kb
25
.bat 4,01Kb 25 Скачать

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. info1i 106 30.01.20 23:17 Сейчас в теме
Т.е. восстановление у Вас не получилось автоматизировать.
Прилагаю ссылки, как мне удалось эту задачу решить.
http://alexanderrudnitskiy.blogspot.com/2019/10/postgresql.html
http://alexanderrudnitskiy.blogspot.com/2019/01/postgresql-cmd-psql.html
Я не отцеплял базу от кластера 1С.
Делал на версии PostgreSQL 9.6.
trickster; +1 Ответить
2. ClickUp 367 31.01.20 04:01 Сейчас в теме
(1) Восстановление работает, как положено, только в чистую базу и если ее первоначально создать в Postgre, если база рабочая и ее надо восстановить (заменить, переписать) на копию, то тут возникают проблемы (решение было удаление ее из 1с сервера и загрузка в базу Postge и потом повторное создание на 1с сервере и привязка в postgre)
41. user1253944 10.02.20 08:59 Сейчас в теме
(2) Я правильно понимаю, что по такому Вашему сценарию теряется журнал регистрации 1С? Он ведь не в базе постгреса хранится. На мой ламерский взгляд вариант (39) более правильный.
42. ClickUp 367 10.02.20 09:35 Сейчас в теме
(41) Восстанавливайте в копию базы и проблем не будет (в новую созданную базы на сервере 1с)
3. starik-2005 2294 31.01.20 11:49 Сейчас в теме
Как на вашей винде все заморочено!! )))

В линухе все очень просто: https://infostart.ru/public/1051601/ (может быть поможет статья с восстановлением бэкапа (2), хоть и для 9.6 описано, но не должно ничего принципиально поменяться).
4. mad_maksim 91 02.02.20 16:27 Сейчас в теме
handy backup хорошо научилась работать с любыми базами 1С.
рекомендую
5. ClickUp 367 02.02.20 17:52 Сейчас в теме
(4) Это все хорошо только он платный.
6. capitan 1948 03.02.20 12:59 Сейчас в теме
Сейчас на Хабре идет цикл расшифровок докладов по высоконагруженным постгри
https://habr.com/ru/post/485622/
Инструменты создания бэкапов PostgreSQL. Андрей Сальников (Data Egret)
7. comol 4551 03.02.20 16:14 Сейчас в теме
Эээ так pg_dump зашквар же вроде, не? Не надо в современном постгресе так делать...
8. ClickUp 367 03.02.20 16:23 Сейчас в теме
(7) критикуешь-предлагай.
9. comol 4551 03.02.20 16:32 Сейчас в теме
(8) pg_basebackup, WAL... со всеми вытекающими....
BTRVODKA; +1 Ответить
10. starik-2005 2294 03.02.20 16:39 Сейчас в теме
(9)
pg_basebackup
Ну тут есть существенный минус:
pg_basebackup создаёт бинарную копию файлов кластера, контролируя режим создания копии автоматически. Резервные копии всегда создаются для кластера целиком и невозможно создать копию для какой-либо сущности базы отдельно. Для этой цели можно использовать, например, утилиту pg_dump.
(документация pg)
Т.е. если на кластере и рабочие базы, и тестовые, то забэкапить рабочие базы отдельно и потом развернуть в тестовые не получится...

С "вытекающими" - так тут масса способов. И те же самые ограничения.

Но всегда, предположу, есть и еще какой-нить топчик, о котором никто не знает )))
12. comol 4551 03.02.20 16:44 Сейчас в теме
(10) О том что надо разделять рабочий кластер и тестовый не говорить?.

Да не... pg_dump он просто в принципе устарел. Оно же создаёт консистентную резервную копию, т.е. пока идёт бэкап создаются новые версии. Это пипец какая нагрузка на БД и пипец как долго. Ну и собственно если всё падает сразу после бэкапа - всё что не забэаплено потеряно.

Нормальный DBA стреляется от таких бэкапов сам, пока его не застрелили :). pg_basebackup работает уже с доставкой журнала транзакций,

соответственно pg_basebackup - это единственный допустимый способ резервного копирования для production среды

pg_dump - для теста/дева ну или depricated
14. comol 4551 03.02.20 16:47 Сейчас в теме
(12)
pg_basebackup - это единственный допустимый способ резервного копирования для production среды

З.Ы. Не единственный конечно... У Postgres Pro есть нормальный инструмент в платной версии
17. starik-2005 2294 03.02.20 16:58 Сейчас в теме
(12)
О том что надо разделять рабочий кластер и тестовый не говорить?.
Так у добрых людей давно бэкапится докер, данные мигрируют через rsync,например (да вообще масса разных штук для работы с файлами - та же zfs), отдельно скулом по статистике бэкапятся отдельные измененные таблицы, ... Там масса плюшек разных исходя из разных кейсов использования постгреса и возможностей железяк.

С другой стороны, большинство баз на постгресе - это однокомпьютерные 1с+SQL-сервера, в которых для бэкапа подоткнут отдельный диск, на который все это периодически кладется.
18. comol 4551 03.02.20 17:02 Сейчас в теме
(17)
добрых людей давно бэкапится докер
postgresql в docker (statefull) может у добрых но очень смелых людей :)))))))))) Ну а бэкап всего контейнера вместо бэкапа WAL ещё и у ... хм... не слишком дальновидных :)

80% нормальных инсталяций постгреса, даже те которые с patroni кластером юзают pg_basebackup. Остальные - от постгреспро.
Ссылка на хабр выше была... на хайлоад с ребятами общались на эту тему.
24. starik-2005 2294 03.02.20 17:09 Сейчас в теме
(18)
Ссылка на хабр выше была... на хайлоад с ребятами общались на эту тему.
Ну чел написал для колхозников о том, как бэкапить и что. Ну и ежу понятно, что докер - не для хранилища базы, а для сервиса только - хранилище отдельно, оно в реальном режиме улетает в слейв.

У pg_basebackup есть преимущества: нагрузка на сервер существенно ниже, чем у pg_dump, но и транзакции в бэкап подтягиваются, которые после начала бэкапа произошли и при восстановлении данные на момент окончания бэкапа подтягиваются. Но мне, например, у клиентов с одним кластером куда проще вытащить бэкап pg_dump'ом и развернуть его назад в тестовую базу, чем заниматься поддержкой двух кластеров. В итоге у меня есть продуктовая база и тестовая на конец вчерашнего дня. Предложи вариант, как организовать подобное с помощью других средств?
26. herfis 408 03.02.20 17:19 Сейчас в теме
(24) Подозреваю, что будет песня про то, что "сложившейся практикой" в "реальном продакшене" является как раз схема "одна база" - "один кластер". И начиная с некоторых масштабов и количества баз я даже могу с этим согласиться.
Но считать, что если вам пока не нужна оркестрация, то вас нельзя называть "нормальным продом" - это эребор.
Постоянно вижу в обсуждениях эти воинственные суждения (и у вас тоже). Мол или "ларек" или "нормальный прод" сразу со всеми взрослыми свистоперделками. Середины не бывает :)
29. comol 4551 03.02.20 20:00 Сейчас в теме
(24)
развернуть его назад в тестовую базу
Ваще не вопрос - в тестовую конечно надо pg_dump-ом. А если прод рухнет? Или что-нить страшное случится? Но ты уж раз где то читал про zfs и "прочие хипстерские технологии" то правильно тестовую базу разворачивать как нибудь вот так:
https://gitlab.com/postgres-ai/database-lab/-/tags/0.1?fbclid=IwAR2KAZlVgAzUJxCknTiHYpC-rHi5BXXtD8W_6aC3YJY434Td-u_zqZ0PgcM
Ну и кластер для прода и теста в любом случае должен быть разный... хоть в контейнерах, хоть в VM, хоть на физических серверах - это базовые законы.
P.S. естественно когда говорю "правильно" - имеется в виду "технически правильно" а не "коммерчески правильно". То что верно коммерчески можете решать только вы на конкретном проекте/клиенте.
21. herfis 408 03.02.20 17:05 Сейчас в теме
(12) Начал читать про pg_basebackup. Написано, что он используется для копирования файлов КЛАСТЕРА ЦЕЛИКОМ. И в документации по этой же команде говорится о рациональности использования pg_dump для создания бэкапа отдельной базы.
Про "единственный допустимый способ резервного копирования для production среды" и "depricated pg_dump для дева" - это чье-то частное мнение или есть вызывающие доверие пруфы? Ибо в документации на pg_dump текущей версии я подобных намеков не замечаю.
30. comol 4551 03.02.20 20:02 Сейчас в теме
(21)
Ибо в документации на pg_dump текущей версии я подобных намеков не замечаю.
Спросите у живых DBA и подумайте сами.
Прежде всего ответьте себе на вопрос: "С данными за какое время вы готовы расстаться в случае падения сервера?".
34. starik-2005 2294 04.02.20 10:58 Сейчас в теме
(30) в опщем совет - не пей кньяк грузинский вражеский, и не жуй дряни, и неикури травы.

У тех, у кого "технически-правильно" прод, тест и дев - у них дампом базв будет бэкапиться очень долго поэтому ни бэкапят слейв прода специальными утилитами, которые к постгресу не относятся от слова никак. Какие-нить 1С-ные типа что-то понимающие ДБА - они будут юзать приведенную тобой фичу. А обычные конторы, в которых постгрес от недостатка бабла стоит будут дампить, и размер их базы должен намекать на то, почему у них нет бабла на серверную венду и мелкософтовский скул.
35. herfis 408 04.02.20 11:30 Сейчас в теме
(30) Многие отвечают на этот вопрос так, что если умножить вероятность краха базы на стоимость восстановления дня работы, то суточного бэкапа бывает достаточно. Когда недостаточно - да, нужны бэкапы транзакций. И вот то, что в постгресе этот востребованный режим резервирования/восстановления до сих пор реализован через жопу (попутно проходя через гланды), несмотря на серьезность и широту использования постгреса - демонстрация блеска и нищеты опенсорса во всей красе. Чтобы использовать postgres в продакшене в нормальный рост и с минимумом приседаний, нужно обложиться со всех сторон дополнительным тулингом (который в проприетарных базах идет из коробки единой поставкой с ядром). Хочешь человечных бэкапов? Доп-инструмент. Хочешь человечного мониторинга и анализа? Доп-инструмент. Это я так - ворчу.
Pawlick; acanta; +2 Ответить
11. ClickUp 367 03.02.20 16:42 Сейчас в теме
(9) это по вашему предложение, решение готовое?
Такие предложения и я вам кину.... инструменты, такие как pg_dump, pg_basebackup, barman, wal-e, wal-g, pgbackrest, BART и pg_probackup.
взятые с того же хабра
13. comol 4551 03.02.20 16:45 Сейчас в теме
(11) Нуу... я статью про резервное копирование постгреса не писал... поэтому конечно не готовое решение.
просто написав про pg_dump вы "учите плохому". На что я не могу не обратить внимание....
15. ClickUp 367 03.02.20 16:52 Сейчас в теме
(13) Возможно есть и лучше методы, не спорю, всегда готов почерпнуть и дополнить знания, говоря "учу плохому" возникает вопрос, скажи а как надо? И тут приходят истинные умы, читай документацию, загугли изучай пробуй и т.д.
16. comol 4551 03.02.20 16:56 Сейчас в теме
(15) Ну сорян. Спасибо за старания, конечно статья хорошая... Просто должен прийти тролль и всё загадить :))).
Конечно при прочих равных лучше настроенный регулярный pg_dump чем ничего.
Но всё-таки лучше загугли :). Просто на будущее... я не просто потроллить пишу. pg_dump это правда не очень хорошо для нормального прода....
19. ClickUp 367 03.02.20 17:02 Сейчас в теме
(16) Начав поиски в интернете как сделать копию бд и равернуть ее на Postgre, на вас просто вывалят куча не работающего мусора, 80% из которого это методы на pg_dump.
Чем он плох (вкратце)? Бэкапы этим методом у клиента делается каждый день на протяжении полу года не разу проблем не было с разверткой БД. Возможно когда в момент бэкапа упадет сервак.... но тут я думаю не кто не застрахован от краха хоть все БД в целом.
Может нам просто везло.....
20. comol 4551 03.02.20 17:03 Сейчас в теме
(19)
Чем он плох (вкратце)
представляете себе блокировку всей таблицы?.... А теперь представьте всей базы... И транзакцию длинной в весь бэкап. Только MVCC и спасает.
22. herfis 408 03.02.20 17:06 Сейчас в теме
(20)
Только MVCC и спасает.

Абсолютно нормальная ситуация для фулл-бэкапа. Или MVCC или откладывание контрольной точки.
27. comol 4551 03.02.20 19:42 Сейчас в теме
(22) Да... просто full бэкап должен быть или редким или ночным... или единственным... А если существует только full... ну как то не очень это нормально
23. ClickUp 367 03.02.20 17:07 Сейчас в теме
(20) Возможно в нашем случае не все проще.... бэк делается ночью в базах не кого нет. не каких рабочих процессов с базой не проходит кроме самого бэка.
28. comol 4551 03.02.20 19:43 Сейчас в теме
(23) Ну а если упало днём? часов в 6 вечера... Откатываемся к ночному бэкапу?....
32. ClickUp 367 04.02.20 03:53 Сейчас в теме
(28) Да. Не во всех организациях требуется писать каждую транзакцию и потеря дня работы не кого не напугает, это не розница какая нить и не производство где по тыс доков лупят каждый час. Я не говорю что этот метод надо использовать всем и поголовно, каждый сам для себя решит что ему применять и как копировать, это один из вариантов.
Кто пишет каждую транзакцию, а кто то делает копии раз в неделю раз в месяц и им этого хватает.....
Организации бывают разные и всех под одно ровнять не стоит, и как тут уже было сказано середины не бывает либо это "ларек с булочками" либо это "газпром" или другой проект грандиозных масштабов.
36. comol 4551 04.02.20 11:39 Сейчас в теме
(32)
потеря дня работы не кого не напугает
если ситуация такая то естественно pg_dump правильный выбор. Оно самое простое и безпроблемное.
48. stopa85 04.11.20 22:40 Сейчас в теме
(8) Если вы 1сник и чуть-чуть админ, то это самый правильный способ.

А так я использую pg_basebackup раз в два дня, архивирую журнал транзакций раз каждые 15минут (он там маленький 16мб, если заполнится раньше, то и архивируется раньше) и держу реплику боевого сервера.

Ещё и вашим способ делаю копии. Но раз в неделю)

Ещё мониторю все эти процессы заббиксом. Так что если что повиснет я быстро об этом узнаю.

Итого у меня есть три звена
1. Мастер который бекапим
2. Слейв который постоянно подтягивает данные и может быть очень быстро введен в боевой режим
3. Выделенный сервер резервного копирования. На нем лежат pg_basebackup'ы, архив транзакций, еженедельные pg_dump'ы

Итого:
1.Уберите любые два звена, я восстановлю работоспособность.
2. Возможность восстановить состояние кластера за 1секуду до сбоя (или ошибки админа или умышленной порчи инфы)
3. Можно из дампа поднять копию для разработки или найти копию ЗУП 3х месячной давности (бухи просят иногда, когда накосячат)
(8)
33. ivanow-sv 04.02.20 08:51 Сейчас в теме
может немного не по теме, но про PostgreSQL
стоит ли мигрировать с 9.6 на 10-ую , а то и на 11.5 как в статье? (у нас 1С 8.3)
37. comol 4551 04.02.20 11:42 Сейчас в теме
(33) Стоит. Параллельное выполнение многих операций сделано.
38. ivanow-sv 04.02.20 12:20 Сейчас в теме
(37)
(33) Стоит. Параллельное выполнение многих операций сделано.

к Linux решениям тоже относится?
40. comol 4551 05.02.20 12:57 Сейчас в теме
(38) Postgres в принципе относится к Linux решениям. Не надо его использовать на винде! Ну кроме случаев когда сервер один, база небольшая и потеря дня работы не критична. Там просто на WIndows используется другой способ доступа к диску, и работа с кучей мелких файлов на NTFS не оптимальна.
39. Gorus 47 05.02.20 11:48 Сейчас в теме
У меня на 9.6.6 восстанавливается без удаления базы на сервере 1С, правда на сервере pg базу нужно удалять и создавать заново.
Делаю так (для тестовой базы):
1. Создаю новую базу на pg сервере с приставкой "_new"
CRE ATE     DATABASE "XXXBase_new"
  WITH OWNER = postgres
       ENCODING = 'UTF8'
       TABLESPACE = pg_default
       LC_COLLATE = 'Ukrainian_Ukraine.1251'
       LC_CTYPE = 'Ukrainian_Ukraine.1251'
       CONNECTION LIMIT = -1;

2. Восстанавливаю базу из выгрузки:
"C:\Program Files\PostgreSQL\9.6.6-1.1C\bin\pg_restore" -U postgres -d XXXBase_new --verbose PathYYY.backup

или через psql:
"C:\Program Files\PostgreSQL\9.6.6-1.1C\bin\psql" -U postgres XXXBase_new < YYY.sql

3. Переименовую базу в "_old"
ALT ER     DATABASE "XXXBase" RENAME TO "XXXBase_old"

4. Переименовую загруженную базу:
ALT ER     DATABASE "XXXBase_new" RENAME TO "XXXBase"

5. Через некоторое время удаляю базу "_old":
DR OP     DATABASE "XXXBase_old"
cleaner_it; +1 Ответить
43. user1253944 11.02.20 02:21 Сейчас в теме
(39)
(42) Не понял, что именно Вы хотели до меня донести словами "проблем не будет". Вы хотите сказать, что при восстановлении в новую созданную на сервере 1С базу у меня каким-то образом перенесутся и журналы регистрации 1С? Откуда? Они ведь не хранятся вместе с данными на sql-сервере, а хранятся отдельно на сервере 1С.
Если же Ваше "проблем не будет" относится просто к восстановлению базы, то у меня, в тех редких случаях, когда так требовалось поступать, всегда без проблем отрабатывал следующий алгоритм:
1. блокировка на сервере 1С регламентых заданий и регистраций пользователей в проблемной базе. Убедиться, что активных сеансов нет
2. переименование (на всякий случай) средствами postgres проблемной базы (в моём случае к имени базы подставляется штамп дата-время операции)
3. восстановление из дампа копии базы.
4. снятие блокировок на сервере 1С
В таком случае журналы 1С оставались на своём месте и были доступны

Кстати, буду благодарен за мысли, как автоматически сохранять вместе с копией базы и журналы регистраций 1С на момент создания копий с возможностью их развёртывания при восстановлении.
44. GreenDragon 21.04.20 10:57 Сейчас в теме
(43) Скидывайте регулярно журнал в какую-нибудь базюку и дальше то же самое, что и с основной базой. Можете прям тут же на инфостарте поискать по словам "журнал регистрации"
45. popov_i 5 03.08.20 12:39 Сейчас в теме
В файле лога выдает следующие иероглифы " ‘Ёб⥬Ґ ­Ґ г¤ Ґвбп ­ ©вЁ гЄ § ­­л© Їгвм." Куда копнуть? С настройкой языков windows связано как я понимаю или шрифты?
46. Suulla Uola 6 04.09.20 04:36 Сейчас в теме
Статья полезная. Сижу пробую.
На 1С Сервере можно не создавать базу, а указать новое имя в строке "База данных:"
47. dkonakov 8 10.09.20 20:08 Сейчас в теме
Спасибо за ваш файл. Попробовал, а восстановление прекрасно работает в ту же базу кстати через пг админ.
Оставьте свое сообщение

См. также

Циклический бэкап по дням недели Промо

Архивирование (backup) v7.7 v8 1cv8.cf 1cv7.md Россия Абонемент ($m)

В интернете часто можно встретить статьи о том, как написать скрипты для автоматического архивирования баз MSSQL. Методика, в них предлагаемая создает новый архив каждый новый день. Более подробно об этом можно почитать в http://outcoldman.ru/ru/blog/show/127 Я предлагаю незначительное усовершенствование скриптов и генерацию архивов по дням недели с циклической их перезаписью. Скрипт тоже не полностью мой, а скомпонован из различных примеров, найденных в интернете, но, надеюсь, именно представленный вариант будет полезен не только мне.

1 стартмани

15.06.2010    39702    milkers    15    

Архивирование базы данных 1С средствами сервера

Архивирование (backup) v8 1cv8.cf Россия Абонемент ($m)

Практическое описание технологии архивирования файловой базы 1С средствами Windows Server 2008 R2.

1 стартмани

12.10.2020    786    zemskov    10    

Резервные копии SQL с помощью планировщика виндовс и скрипта

Архивирование (backup) v8 Абонемент ($m)

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

1 стартмани

12.03.2020    2863    VID1234    15    

Настройка PostgreSQL 11.5 и 1C: Предприятие 8.3.16 на Windows Server 2008R2

Системное администрирование v8 1cv8.cf Россия Абонемент ($m)

Под «Окнами» «Слона» водили… Когда файловая БД 1С вырастает и начинает тормозить, встает вопрос по переводу базы на SQL, безусловно, лидеры и самые используемые при настройке SQL баз на 1С это ПО Microsoft SQL Server и PostgerSQL, (прочие IBM DB2 и Oracle Datebase), но жирный плюс в сторону PostgerSQL, что она условно бесплатная, в отличие от цены на MSSQL.

1 стартмани

22.01.2020    52684    ClickUp    36    

Исполняемый .bat файл для резервного копирования 1С

Архивирование (backup) v8 1cv8.cf Абонемент ($m)

Простейшее решение для выгрузки .dt, доступное любому пользователю 1С.

1 стартмани

14.05.2018    27441    SergPetr    32