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

30.01.20

База данных - Архивирование (backup)

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

Скачать файл

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование По подписке [?] Купить один файл
BackUp 1С 8.3 for POSTGRE 11.5
.bat 4,01Kb
70
70 Скачать (1 SM) Купить за 1 850 руб.

Столкнулся с проблемой резервирования и восстановления бэкпапа на 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/

Готовое решение

Database Compression Tool (DCT): Универсальный инструмент сжатия, свертки и конвертации баз данных 1С

Универсальный инструмент сжатия, свертки и конвертации баз данных 1С.

Свертка баз данных еще никогда не была такой простой и быстрой!

DCT ускоряет работу базы, освобождая гигабайты пространства и повышая производительность системы. Доступна ДЕМО версия!


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

См. также

Архивирование (backup) Инструменты администратора БД Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Платные (руб)

Данная разработка позволит решить вопрос с резервным копированием Ваших баз в автоматическом режиме, расположенных на сервере 1С. Система умеет ставить блокировки на вход, блокировать фоновые задания, принудительно отключать сеансы пользователей. И все это система делает в автоматически при создании бэкапа (или через команду). Выгрузка происходит в родной формат 1С - .dt. Так же система умеет архивировать данные выгрузки с установкой пароля. Умеет менять расширение файла zip или dt на любое указанное вами, что позволит сохранить выгрузки от шифровальщика. Может удалять старые копии выгрузок, оставляя указанное количество резервных копий, начиная с самой поздней. Только для WINDOWS!

6000 руб.

06.11.2012    72806    627    45    

85

Архивирование (backup) Системный администратор Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб)

Программа позволяет выполнять автоматическое создание копий файловых и серверных информационных баз 1С Предприятие 8 и размещение копий в облаке Яндекс.Диск, локальном или сетевом ресурсе.

1200 руб.

03.09.2014    15712    21    6    

27

Архивирование (backup) Администрирование СУБД Системный администратор Россия Бесплатно (free)

Постараюсь объяснить, зачем нужно резервное копирование именно журнала транзакций, а не только базы данных, и почему я словно сбросил груз, настроив его - как, покажу, естественно. Кстати, будут скрипты T-SQL (с подробными комментариями) - отличный способ сделать администрирование базы более уютным.

04.12.2023    9451    n_mezentsev    15    

27

Архивирование (backup) Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

В данной инструкции будет описано, как с помощью pgAdmin, bat-файлов и планировщика заданий Windows организовать резервное копирование, восстановление и хранение копий баз данных.

07.10.2022    28666    sapervodichka    37    

147

Архивирование (backup) Системный администратор Платформа 1С v8.3 Конфигурации 1cv8 Россия Абонемент ($m)

Захотелось клиентам выгрузку архива баз, и выгрузку в дт, готовые скрипты с сети не заработали. Может, кому-то поможет. Релиз 8.3.18.1741.

1 стартмани

25.08.2022    5737    3    Gnom-Gluck    6    

7

Архивирование (backup) Системный администратор Программист Платформа 1С v8.3 Абонемент ($m)

Небольшая утилита для копирования файловых баз данных 1С.

1 стартмани

02.06.2022    4693    3    Giblarium    12    

5
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. info1i 236 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.
xvchk; trickster; +2 Ответить
2. ClickUp 722 31.01.20 04:01 Сейчас в теме
(1) Восстановление работает, как положено, только в чистую базу и если ее первоначально создать в Postgre, если база рабочая и ее надо восстановить (заменить, переписать) на копию, то тут возникают проблемы (решение было удаление ее из 1с сервера и загрузка в базу Postge и потом повторное создание на 1с сервере и привязка в postgre)
41. user1253944 10.02.20 08:59 Сейчас в теме
(2) Я правильно понимаю, что по такому Вашему сценарию теряется журнал регистрации 1С? Он ведь не в базе постгреса хранится. На мой ламерский взгляд вариант (39) более правильный.
42. ClickUp 722 10.02.20 09:35 Сейчас в теме
(41) Восстанавливайте в копию базы и проблем не будет (в новую созданную базы на сервере 1с)
3. starik-2005 3088 31.01.20 11:49 Сейчас в теме
Как на вашей винде все заморочено!! )))

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

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

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

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

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

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

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

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

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

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

У pg_basebackup есть преимущества: нагрузка на сервер существенно ниже, чем у pg_dump, но и транзакции в бэкап подтягиваются, которые после начала бэкапа произошли и при восстановлении данные на момент окончания бэкапа подтягиваются. Но мне, например, у клиентов с одним кластером куда проще вытащить бэкап pg_dump'ом и развернуть его назад в тестовую базу, чем заниматься поддержкой двух кластеров. В итоге у меня есть продуктовая база и тестовая на конец вчерашнего дня. Предложи вариант, как организовать подобное с помощью других средств?
26. herfis 513 03.02.20 17:19 Сейчас в теме
(24) Подозреваю, что будет песня про то, что "сложившейся практикой" в "реальном продакшене" является как раз схема "одна база" - "один кластер". И начиная с некоторых масштабов и количества баз я даже могу с этим согласиться.
Но считать, что если вам пока не нужна оркестрация, то вас нельзя называть "нормальным продом" - это эребор.
Постоянно вижу в обсуждениях эти воинственные суждения (и у вас тоже). Мол или "ларек" или "нормальный прод" сразу со всеми взрослыми свистоперделками. Середины не бывает :)
29. comol 5108 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 513 03.02.20 17:05 Сейчас в теме
(12) Начал читать про pg_basebackup. Написано, что он используется для копирования файлов КЛАСТЕРА ЦЕЛИКОМ. И в документации по этой же команде говорится о рациональности использования pg_dump для создания бэкапа отдельной базы.
Про "единственный допустимый способ резервного копирования для production среды" и "depricated pg_dump для дева" - это чье-то частное мнение или есть вызывающие доверие пруфы? Ибо в документации на pg_dump текущей версии я подобных намеков не замечаю.
25. пользователь 03.02.20 17:12
Сообщение было скрыто модератором.
...
31. пользователь 03.02.20 20:12
Сообщение было скрыто модератором.
...
30. comol 5108 03.02.20 20:02 Сейчас в теме
(21)
Ибо в документации на pg_dump текущей версии я подобных намеков не замечаю.
Спросите у живых DBA и подумайте сами.
Прежде всего ответьте себе на вопрос: "С данными за какое время вы готовы расстаться в случае падения сервера?".
34. starik-2005 3088 04.02.20 10:58 Сейчас в теме
(30) в опщем совет - не пей кньяк грузинский вражеский, и не жуй дряни, и неикури травы.

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

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

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

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

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

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

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

к Linux решениям тоже относится?
40. comol 5108 05.02.20 12:57 Сейчас в теме
(38) Postgres в принципе относится к Linux решениям. Не надо его использовать на винде! Ну кроме случаев когда сервер один, база небольшая и потеря дня работы не критична. Там просто на WIndows используется другой способ доступа к диску, и работа с кучей мелких файлов на NTFS не оптимальна.
39. Gorus 48 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 4 03.08.20 12:39 Сейчас в теме
В файле лога выдает следующие иероглифы " ‘Ёб⥬Ґ ­Ґ г¤ Ґвбп ­ ©вЁ гЄ § ­­л© Їгвм." Куда копнуть? С настройкой языков windows связано как я понимаю или шрифты?
46. Suulla Uola 7 04.09.20 04:36 Сейчас в теме
Статья полезная. Сижу пробую.
На 1С Сервере можно не создавать базу, а указать новое имя в строке "База данных:"
47. dkonakov 10 10.09.20 20:08 Сейчас в теме
Спасибо за ваш файл. Попробовал, а восстановление прекрасно работает в ту же базу кстати через пг админ.
49. пользователь 11.04.21 14:32
Сообщение было скрыто модератором.
...
50. XelOla 18 21.05.21 11:22 Сейчас в теме
Здравствуйте!
Подскажите, как при отключенном сервере 1С
скопировать базу постредством Постгри (разово)
и перенести на новый сервер, где стоит ключ сервера 1С.
51. e9953 05.04.22 09:42 Сейчас в теме
Спасибо тебе, добрый человек, за статью. Мне как раз нужно было именно это!
Оставьте свое сообщение