Развернуть копию базы 1с postgresql из бэкапа

Обновлено: 07.07.2024

Данный материал является продолжением Быстро, дёшево и массово подстраховать базы клиентов от утери. Комплексная система удалённого резервного копирования, только для PostgreSQL. О rsync, о том, как настраивать серверную часть написано в предыдущей статье, и необходимо с ней ознакомиться, чтобы в полной мере понять данный материал. Вся статья посвящена настройке клиента на Windows (в unix-подобных гораздо сделать такой скрипт гораздо проще). Решение не требует ни наличия белых адресов со стороны клиента, ни VPN. Связь инициируется клиентом. Механизмы репликации не задействованы, и поэтому поднятие pgsql на стороне сервера не требуется. Интерес к PG усилился, после того как поступили сведения, что по производительности он уже уверенно идёт в очковой зоне противника (MSSQL 34 попугая, а Postgres 47. Не пойму где я недоглядел. (Тест Гилёва))

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

Среди поставленных задач:

обеспечить себе удобную работу с копиями на серверах клиентов (а-ля MSSQL);
обеспечить передачу резервных копий на свой сервер, с минимальной нагрузкой на сеть;
поделиться материалом народом, получить советы, конструктивную критику и помощь.

Также я обновил бинарную составляющую клиентской части, а именно rsync и ssh. Файлы взяты из последней установки cygwin и будут включены в архив с составе статьи за шеккель (таки должен же шо то я с этого поиметь). Но вообще его можно не качать и собрать всё самостоятельно, всё что есть в архиве - есть в статье, остальное выдернуть из cygwin или взять например вот

С WAL (архивация журнала транзакций)

С архивами WAL можно восстановить копию на любой момент времени. В течение дня можно передавать на удалённый сервер файлы WAL, таким образом удалённая копия будет актуальная в течение дня. Файловая копия экземпляра сервера, это тоже самое, как если бы вы остановили сервер, скопировали из него папку data и запустили в другом месте, только без остановки сервера.

Минусы:

Нельзя сделать делать копию одной какой-то базы;
примерно в 1,5 раза больший размер дневной копии;
не всякая версия PG сможет проиграть вашу копию, желательно, чтобы была та же самая версия;
громоздкость.

Плюсы

Можно получить копию на любой момент времени;
восстанавливается быстрее, чем логическая копия.

Мой подход

Раз в сутки (ночью), выполняется pg_basebackup в папку rsync\data (полная базовая копия всего экземпляра сервера). Оттуда rsync отправляет её на север в виде файлов и не удаляет. То есть всегда за счет этого занято место полного размера экземпляра(1). Я пошёл на это сознательно, так так есть шанс, что место на диске займёт что-нибудь другое и резервное копирование вообще не сработает, так же этой копией можно быстро восстанавливать текущую копию.(тем же самым rsync). После создания копии, база в виде набора файлов (несжатая) отправляется на сервер посредством rsync. Такой подход даёт минимальную нагрузку на сеть (speedup более 200(в 200 раз быстрее, чем передача всех данных)). Я пробовал экономить место отправляя tar+ --rsyncable pigz и получил (speedup около 40). После передачи данных файл сжимается и кладётся в postgres\archive

Включен режим архивирования журнала wal в папку rsync\wal_archive. Оттуда каждый час архивированные файлы wal уходят на backup-сервер.

Вот так переносятся та же 2,4GB(dt) база, по каналу 2Mbit/s, в виде копии экземпляра сервера:

Восстановление

Поскольку восстановить можно только весь экземпляр, а останавливать основной нельзя, то должен существовать второй экземпляр, назовём его текущая копия. Текущую копию необходимо инициализировать, то есть создать службу Windows(это несложно). Затем перенести из папки postgres\rsync\data, если копия сегодняшняя, либо достать из архива базовую копию за запрошенный день. И в зависимости от того, какую часть дня нужно восстановить накатывается журнал транзакций. То есть появляется ещё одна папка postgres\current_copy, которая занимает столько же места, сколько основной экземпляр(2).

Итого: Для того, чтобы функционировал мой вариант потребуется дополнительное место, занимаемое основным экземпляром PGSQL умноженным на два, и каждая дневная сжатая копия будет весить примерно в 1,5 больше, чем копия сделанная pg_dump. Это основной минус моего подхода. Ну и следствие вот такой архитектуры резервного копирования PG в том, что нельзя восстановить почасовую копию какой-то одной базы данных, восстанавливать придётся все, или нужно распределять базы по экземплярам, что ещё хуже (но возможно с привлечением какой-нибудь автоматики, написанной к примеру на 1С).

Таким образом вот этот способ не подойдёт для основного моего сервера, где множество мелких баз, к которым желательно сохранять почасовые копии, так как восстанавливать все базы для получения последней копии одной из них будет накладнее, чем pg_dump/pg_restore одной базы. Может быть будут применяться оба метода, но однозначно PosgreSQL вот именно в этом аспекте существенно неудобнее MSSQL, но дарёному слону в зубы не смотрят. PG зато выигрывает в части переноса базовой копии на удалённый backup-сервер так как полная копия MSSQL ни черта не rsyncable.

Процесс восстановления базы за сегодняшний день на 10 часов, при том, что сегодня эту базу на сегодня уже восстанавливали:

Процесс занимает около 3-х минут. Если день другой, то восстановление будет занимать около 10 минут. На этой машине, которая мне досталась, всего одна 2,4 база, SATA HDD и i5-7400.

Матчасть

Инициализация

C:\Backup\etc - содержит файл nsswitch.conf необходимый для определения $HOME.

Для того, чтобы бинарники, производные от новых cygwin могли найти $HOME необходимо заполнить файл /etc/nsswitch.conf

Это укажет, что home именно там и нигде иначе, и указать cygwin где вообще находится корень, чтобы он мог найти etc/nsswitch.conf.

Если правильно указали ключи и настроили права на C:\Backup\home\.ssh, то ssh ключи должны попасть в эту папку по нажатию C:\Backup\bin\ssh-keygen.exe.

Включите архивацию в файле postgresql.conf

archive_timeout - это время в секундах, по истечению которого файл WAL будет сформирован, даже если он не заполнен до конца. Весить и заполненный и незаполненный файл будет одинаково. Если интенсивность работы с базой невысокая, а вам необходимо иметь почасовую копию, то поставьте 3600 (час). Я для себя выключил, так как посчитал излишним.

Вариант без архивации WAL

PostgresSimple.bat

"PostgresSimple.bat backup" создаст резервную копию и отправит на удалённый сервер
"PostgresSimple.bat restore base base_copy" Сделает текущую копию базы base в base_backup
"PostgresSimple.bat restore base base_copy 2019-07-29" Восстановит копию базы base в base_backup за 2019.07.29

Так же необходимо создать файл C:\Backup\bin\postgresbases.txt вида:

Для того, чтобы знать что архивировать.

Вариант с архивацией WAL

PostgresWAL.bat

"PostgresWAL.bat backup" создаст и отправит на сервер полную резервную копию (запускается раз в сутки, ночью)
"PostgresWAL.bat backup h" отправит на сервер журнал WAL (запускается каждый час в рабочее время)
"PostgresWAL.bat init" создаст службу postgres_copy на которой будет работать скопированный экземпляр
"PostgresWAL.bat restore [день] [время]" Восстановит экземпляр сервера на указанные дату и время
[день] - today (сегодняшний день), либо дата в формате 2019-07-29
[время] - пусто - начало дня, last - конец дня, либо дата в форматe 13:00:00
Например:
"PostgresWAL.bat restore today last" - последняя сегодняшняя копия
"PostgresWAL.bat restore today" самая ранняя сегодняшняя копия
"PostgresWAL.bat restore 2019-07-29 13:00:00" конкретные время и день

Канэс

На сегодняшний день мной ещё не накоплен ни опыт использования механизмов, указанных в статье, ни эксплуатации postgres в боевых условиях, почти нет телеметрии, достаточной для того, чтобы её показать. Отталкиваясь статьи планирую внедрять PG по мере необходимости и добывать драгоценный опыт. Кто использует PG, напишите пожалуйста, есть ли в скриптах или методике ошибки, которые могут сыграть роковую роль? На что стоит обратить внимание? Как бы вы сделали?
Напрягает кодировка логов после PGSQL - не знаю что с ней делать, некритично, но проблема есть. Возможно стоит доработать скрипт отправкой email, если что-то не так. Пока на данный момент угроблено огромное количество времени и уже пока завязывать исследования до лучших времён.

В интернете куча статей, как установить 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"

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

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

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

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"

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

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

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

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

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

(1) lustin,
Зачем так сложно ?
cmd - файл в задания под какой нибуть локальной админской записью.

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

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

где файл_дампа — это файл, содержащий вывод команды pg_dump. База данных, заданная параметром имя_БД не будет создана данной командой , так что вы должны создать её сами из базы template0 перед запуском psql (например, с помощью команды createdb -T template0 имя_БД)

Ещё следует уточнить что кодировка дампа должна совпадать с кодировкой сервера БД.

PostgreSQL не восстанавливает текущую базу из дампа.
Поэтому, я восстанавливаю базу так:
dropdb имя_базы
createdb имя_базы
psql имя_базы < файл_дампа

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

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

dropdb $base_name
createdb $base_name
gunzip -c $archive_name | psql $base_name

У нас с восстановлением базы из дампа проблем вроде не вылезает, не ругается:
dropdb -U postgres [имя базы]
createdb -U postgres [имя базы]
pg_restore -U postgres -d [имя базы] [имя файла] Для разграничения архивов по дням: namebase_backup_%date:

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

(7) Можно ли этим способом делать бэкап базы не выгоняя пользователей из базы? pg_dump — это программа для создания резервных копий базы данных Postgres Pro. Она создаёт целостные копии, даже если база параллельно используется. Программа pg_dump не препятствует доступу других пользователей к базе данных (ни для чтения, ни для записи).
Нет, нельзя. Одна операция в 1с меняет данные во многих sql таблицах. Бэкап базы существеннен по времени и у вас нет гарантии, что данные за это время не изменятся. Вы сделаете несколько бэкапов и они будут рабочие, но однажды попадете на восстановление данных. (14) Не вводите людей в заблуждение.
Не только можно, но и в большинстве случаев это единственный вариант. Например если база весит пару терабайт, работает 24/7/365 и каждый час простоя стоит N килобаксов.
А по поводу длительности операции - там снэпшот создается, так что итоговый бэкап получается вполне себе консистентным.
Не знаю как насчет терабайт, а вот с базой 300Гб (select pg_database_size('base');), которая используется 24/7/365, я сначала был такого же мнения как и вы. Бэкап делался минут 40, в течении которых пользователи плевались и матерились, т.к. предприятие тормозило еще как. Так вот в один прекрасный день, когда неудачно прошло обновление конфигурации и база отказалась запускаться, пришлось воспользоваться самым свежим бэкапом, сделанным таким путем, и каково же было мое недоумение, когда он загрузился без проблем, но при открытии в 1с счет фактур предприятие вылетало. Вы можете возразить, что мол кеши надо было чистить, но все это конечно было сделано. Сейчас система переделана. Два сервера: один мастер, другой слейв. Когда нужно сделать бэкап, слейв теряет соединение с мастером, к нему подключается сервер 1с предприятия и средствами 1с делают бэкап. После этого слейв подключается к мастеру и синхронизируется.
Снепшот может и создается (хотя не уверен, а проверять ваши слова лень), но это снепшот sql базы. А вот 1с в этот момент может что-то активно писать и поменять данные в 1 таблице sql, и тут произойдет снепшот sql, а еще в 10 таблицах не успеет поменять, хотя должна, чтобы поддерживать свою логику. Вы же знаете, что одно добавление в регистр записи, может запускать множество других регистраций и каждая из них будет запускаться как одна транзакция в sql. Поэтому данные в базе у вас обязательно испортятся. Возможно база у вас и загрузится и даже работать будет, но данные будут неполными и это аукнется позже. (16), А есть уверенность, что в момент потери связи между серверами 1С были записаны все необходимые движения? Вы считаете что все движения, связанные с проведением документа в 1С происходят в одной 1С транзакции? А есть уверенность, что в момент потери связи между серверами 1С были записаны все необходимые движения?
Я говорил про сервера postgresql, а не 1с. Уверенности конечно нет, но т.к. бэкап делается средствами 1с, то 1с при обнаружении испорченных данных в документе его просто не выгрузит в бэкап. В результате структура базы будет цела, правда за минусом документа.
Ага, не понял вас сразу. То есть фактически плюсом этого решения является то, что боевая база не тормозит в момент бэкапа? Но вот в плане надёжности такого решения я испытываю сильные сомнения. В момент обрыва связи между серверами postgre вероятность потерять данные не меньше чем при снепшоте. То что потом бэкап делается средствами 1С не панацея. Сталкивался я со случаями, когда бэкап из dt не разворачивался из-за сбойных данных внутри.
Добрый день,
Выполнял выше указанные скрипты. Дамп отрабатывает без ошибок, но при попытки сделать восстановление в пустую созданную БД отрабатывает не корректно с ошибками, база не запускается. Так же создаю резервные копии как писали в коментах.
Но есть один вопрос. Иногда требуется срочно восстановить какую нибудь копию базы за определенный день. с командной строки я ее восстанавливаю в новую базу созданную посредством psql, но в 1ске то она не появиться надо вручную ее создать или с помощью 1с или через консоль администрирования 1с. А как через командную строку создать базу в 1с?

Хотелось бы рассказать про еще один "чудесный" способ передачи файла с дампом базы от облачного хостера 1С сервера. Возможно это сможет кому-то съэкономить часов 5 драгоценного времени, особенно для таких как я, которые за 15 лет работы с 1С - за ненадобностью postgre в глаза не видели, да и с линуксообразными тоже не особо.

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

Хочешь научиться автоматически разворачивать и поддерживать высоконагруженные проекты? Тогда рекомендую познакомиться с онлайн курсом " Infrastructure as a code." в OTUS. Актуально для системных администраторов и devops инженеров. Подробности по .

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

Введение

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

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

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

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

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

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

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

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

В centos из epel:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

В PostgreSQL есть две утилиты для бекапа pg_dump и pg_dumpall .

pg_dump используется для бекапа одной базы;

pg_dumpall для бекапа всех баз и сервера в целом (необходимо запускать под postgresql-суперпользователем).

Мы будем использовать pg_dump.

Мне лично нравятся эти утилиты для создания копий ИБ, в отличие от создания dt-файла, тем, что они не требуют выгонять пользователей 1С, что весьма удобно.

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

Добрый день.
Спасибо за видеоинструкцию по резервному копированию.
Вы могли бы сделать ещё одну инструкцию по восстановлению архива БД из дампа в рабочую БД 1С? Буду вам очень благодарен. (2) infosoft-v, Да, конечно, видеоинструкция по восстановлению обязательно будет, ожидайте на днях.
(3) DoctorRoza, На выходных поправим, а пока ссылка на предыдущую статью смотрите здесь . Поддерживаю предыдущий пост! Да и киньте ссылку на предыдущую статью! :) Посмотрел видео, ну что сказать, чисто для программистов, которые в теме! Без понятного разбора и детальных пояснений. Таки для бэкапов средствами pgsql я бы посоветовал pg_basebackup
Прекрасно работает наживую, при работающих пользователях и значительно меньше нагружает сервер (6)
патченый постгрес для 1с разве это имеет pg_basebackup ?
в обычном постгресе да, в 1с вроде даже в тестовых сборках нет
ткните, если кто найдет

Просмотры 31798

Загрузки 52

Рейтинг 8

Создание 06.07.15 22:38

Обновление 06.07.15 22:38

№ Публикации 376013

Тип файла Архив с данными

Конфигурация Не имеет значения

Операционная система Linux

Вид учета Не имеет значения

Доступ к файлу Абонемент ($m)

Код открыт Не указано

См. также

Обработка для управления подключениями пользователей и создание бэкапа КЛИЕНТ-СЕРВЕРНОЙ базы данных 1С 8.2-8.3 (управляемое приложение,"такси") Промо

(©Топчий Д.Ю.) Данная обработка позволяет легко и быстро отключить от любой БД одного или несколько пользователей одновременно, установить блокировку сеансов, что необходимо при регламентных операциях с БД, создать резервную копию базы, удалить "дубли" сеансов. Обработка отключает соединения и сеансы указанных пользователей, даже если сеанс или соединение были "повисшими". Возможна интеграция в любую конфигурацию! (Обновление от 11.03.2016, версия 3.0)

2 стартмани

06.11.2012 60632 614 hakerxp 44

Автообновление конфигурации после обмена

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

1 стартмани

02.09.2021 1331 2 Volvo32 1

Портал TopBy (бэкап электронных накладных)

Обработка предназначена для получения списка электронных накладных с портала TopBy и возможностью их скачивания в форматах XML и XLS файлы.

1 стартмани

29.08.2021 1125 1 kozusenok 0

Конфигурация для создания резервных копий баз на сервере 1С: предприятие (SQL)

Конфигурация выполняет выгрузку баз в файлы DT, работающих в клиент-серверном режиме (SQL).

1 стартмани

11.08.2021 1528 5 macrosina 5

Конфигурация для автоматизации бэкапов Промо

Конфигурация для организации резервного копирования и хранения бэкапов информационных баз во внутреннем формате 1С *.dt

1 стартмани

23.01.2015 33461 178 dusha0020 43

Создание копии базы самим пользователем средствами SQL

Как-то надоело постоянно бухгалтеру восстанавливать копии базы для тестов. Сделал обработку, которая умеет автоматически создать копию с текущей базы средствами sql и восстановить в выбранную копию.

1 стартмани

12.07.2021 1551 2 77dream77 6

Методика многоуровневого резервного копирования SQL баз данных 1С (и не только)

Описание методики резервного копирования баз данных MS SQL Server по схеме дед-отец-сын и набор скриптов для ее реализации. Разработана для баз 1С, но подходит для любых.

5 стартмани

29.05.2021 1902 3 tedkuban 0

Изменение допустимого размера базы для сжатия при резервном копировании

Если резервное копирование файловой базы 1С:Бухгалтерия 3.0 или 1С:Зарплата и управление персоналом 3 (ЗУП) у Вас перестало архивировать файл 1CD (просто копирует файл 1CD вместо добавления его в ZIP), то скорее всего у Вас база стала более 2 ГБ. В штатном резервном копировании установлено жесткое ограничение на этот размер. Данное расширение позволяет задать любой другой допустимый размер базы для сжатия.

1 стартмани

12.04.2021 1957 0 3soft 0

Безопасное копирование файловых баз данных 1С (1Cv8.1CD) Промо

Безопасное копирование файловых баз данных 1С (1Cv8.1CD) При подключенных пользователях!

1 стартмани

22.12.2014 53263 121 BorovikSV 28

История данных - расширение для конфигурации "INFOSTART ERP community edition"

Расширение позволяет хранить (восстанавливать) историю данных прикладных объектов (справочников, документов, движений регистров по документам).

10 стартмани

16.03.2021 2500 5 33lab 9

Автоматическое архивирование и обновление типовых 1С с рассылкой уведомлений

Автоматическое архивирование и обновление типовых 1С. Программа запускается по таймеру в назначенных заданиях Windows. По указанному ключу в запуске будет обновлять конфигурацию или архивировать.

1 стартмани

13.03.2021 2325 2 eda_light 3

Проверка резервного копирования

Программа проверяет наличие бэкапов на текущую дату в указанных каталогах.

1 стартмани

04.02.2021 2215 0 r.moschenskiy 0

Резервное копирование SQL-базы 1С в два клика Промо

Простой и надежный способ бэкапа без углубления в тонкости настройки SQL Server Management Studio

1 стартмани

26.09.2012 54145 140 skilster 9

Архивирование резервных копий файловой базы 1С: Бухгалтерия 3.0

1 стартмани

18.12.2020 3705 0 Smarty1963 0

Программа резервного копирования баз (1С и др.) на Python 3

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

Читайте также: