Введение

Вы уже успели заметить, что обновлятор по умолчанию архивирует серверные базы 1с в формате dt.

При этом выгрузка в dt имеет ряд серьёзных недостатков:

• не рекомендуется фирмой "1С" (ссылка)
• требует монопольного доступа
• требует много времени
• требует много ресурсов сервера
• нет никаких гарантий, что в такую выгрузку попадают абсолютно все данные при малейшем повреждении базы
• зачастую приводит к ошибкам сервера 1с

Именно поэтому я рекомендую при первой возможности отказаться от выгрузки в dt в пользу архивации средствами СУБД.

Обновлятор умеет одинаково хорошо работать как с MS SQL Server, так и с набирающей обороты PostgreSQL.

При этом не важно на какой ОС работает сервер с установленной СУБД. Это может быть как Windows, так и любой дистрибутив Linux (CentOS, Debian, Ubuntu, ГосЛинукс, Altlinux, Rosa, МСВСфера, Red Hat).

Как включить архивацию базы средствами СУБД

1. Зайдите в свойства базы и перейдите на закладку "Архивация" и установите опцию "Включить sql архив":

Выполните необходимые настройки. При этом я не рекомендую устанавливать опцию "Дополнительно делать dt выгрузку" по причинам озвученным во введении этой статьи.

2. Далее перейдите на закладку "Общее" и укажите там сервер СУБД, если он ещё не указан:

Готово!

Как восстановить созданный sql-архив через обновлятор?

Вы всегда можете восстановить базу из её резервной sql-копии. Для этого нажмите на базе правой кнопкой и выберите следующий пункт:

Варианты восстановления из резервной копии

При (ручном или автоматическом) восстановлении серверной базы 1с из sql-копии вам будет предложено указать опции восстановления:

Вариант "ничего не делать с базой в кластере"

В этом случае резервная копия будет развернута в ту же самую базу на кластере 1с.

К плюсам этого варианта восстановления можно отнести то, что сохраняется старый журнал регистрации.

Но в то же время могут быть проблемы с кэшем сервера 1с, если метаданные исходной и восстановленной базы отличаются друг от друга (ведь восстановление мы делаем на уровне сервера СУБД, а кластер 1с ничего не знает об этом).

Одним из проявлений таких проблем могут быть ошибки при выполнении кода конфигурации, когда платформа 1с ругается на какой-нибудь неизвестный ей объект метаданных (например, реквизит справочника), а при проверке он оказывается на месте.

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

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

Но если мы оставили базу заблокированной после восстановления, то следует внимательно отнестись к процедуре её разблокировки.  Это можно сделать прямо из обновлятора (пункт 6.08 из меню операций), но обратите внимание, что в этом случае регламентные задачи нужно будет разблокировать отдельно (если это требуется) через пункт 6.14.

Вариант "пересоздать базу в кластере с теми же параметрами"

В этом случае резервная копия будет восстановлена в ту же самую базу в кластере 1с, но эта база (в кластере) на определенных этапах будет удалена и добавлена вновь с теми же самыми параметрами.

Это позволит избежать проблем с кэшем сервера 1с, описанным в предыдущем варианте (см. выше), без перезапуска кластера, но в то же время разорвётся связь текущей базы с её предыдущим журналом регистрации.

И если речь идёт о восстановлении резервной копии в чистую, только что созданную базу, журнал регистрации которой пуст или не существенен для нас, то проблем нет. Но если мы восстанавливаем резервную копию в уже существующую рабочую базу - журнал регистрации обычно требуется сохранить.

Полная автоматизация восстановления журнала регистрации, к сожалению, не возможна при работающем кластере 1с, это придётся (при необходимости) сделать в ручном режиме.

Инструкция для переноса журнал регистрации из старой базы (выполняется до восстановления базы из резервной копии):

1. Заходим в папку кластера 1с (обычно это что-то типа "c:\Program Files\1cv8\srvinfo\reg_1541\"), в которой находим файл 1CV8Clst.lst
2. В этом файле находим строчку с именем нашей базы и её идентификатором:
   
3. Узнав идентфикатор базы находим каталог, в котором хранится её журнал регистрации. В нашем случае это будет каталог: "c:\Program Files\1cv8\srvinfo\reg_1541\0440e0d9-b4a7-49cc-9fd2-39164685ebbd"
4. Записываем себе этот путь (мы к нему ещё вернёмся после восстановления базы из резервной копии).
5. Делаем восстановление базы из резервной копии.
6. Снова заходим в файл 1CV8Clst.lst и видим там новый идентификатор базы.
7. Останавливаем кластер и выполняем перенос подпапки 1Cv8Log из пункта 4 в новое расположение базы (которое мы узнали по её новому идентификатору в пункте 6).

Но что если мы спохватились уже после того как выполнили восстановление из резервной копии и база в кластере 1с была удалена и добавлена вновь (то есть её идентификатор уже изменился). Как узнать папку, в которой хранится журнал регистрации старой базы?

Если вы обнаружили это сразу после восстановления базы, то есть шанс найти её старый идентификатор в файле 1CV8Clsto.lst, который является копией 1CV8Clst.lst (до его последнего изменения) и лежит там же. Получается, что перед каждым  изменением настроек кластера 1с (которое приводит к изменению файла 1CV8Clst.lst), этот файл перед изменением копируется в 1CV8Clsto.lst.

Если же база уже исчезла из 1CV8Clsto.lst, то её старый идентификатор просто так уже не найти. И ничего не остаётся кроме как по очереди исследовать журналы регистрации всех подпапок из "c:\Program Files\1cv8\srvinfo\reg_1541\*\1Cv8Log" и уже по содержимому журналов регистрации устанавливать тот, что относился к нужной базе. Журналы можно просматривать или восстанавливая их в чистую (файловую) базу или же при помощи утилиты DB Browser for SQLite (если речь о новом формате хранения).

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

Нюансы для MS SQL Server

Настройте права учетной записи sql-сервера

Прошу вас очень подробно ознакомиться с этим пунктом, особенно если ваш sql-сервер находится на другой машине (соответствующая галка в настройках сервера СУБД). Здесь много нюансов, на которые нужно обратить внимание.

Прежде всего обратите внимание на то, что служба sql-сервера работает от имени некоторой учётной записи.

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

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

Права на временную папку обновлятора (по умолчанию это папка 'Data\Temp' внутри обновлятора) могут понадобиться, когда архив сначала записывается во временную папку, а уже затем переносится в основную папку архивов. Такое поведение возможно, если вы настроили запись архивов в конечную папку от имени определенного пользователя для защиты созданных архивов от шифровальщиков.

Если sql-сервер находится на другой машине...

В этом случае не забудьте поставить галку "Сервер находится на другом компьютере" в настройках сервера СУБД...

... а также выполнить следующие требования.

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

Эта общая папка должна быть подключена в обновляторе здесь.

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

Права на запись в эту шару (как на уровне сетевой папки, так и на уровне ограничений безопасности NTFS) должны быть настроены так, чтобы учетная запись, под которой работает обновлятор была в состоянии изменять и удалять файлы в этой шаре и её подпапках.

Не сломается ли разностное копирование на sql-сервере?

Начиная с версии от 3 июля 2018 года обновлятор помечает создаваемые sql-копии как copy-only.

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

Такие копии являются изолированными от обычной последовательности резервных копий SQL Server.

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

Итак, резервные sql-копии, которые создаёт обновлятор (начиная с 3 июля 2018 года) помечаются как copy-only, а значит не нарушают возможную цепочку архивов, которые могут включать в себя разностные копии.

Это значит, что когда вы создаёте разностную копию базы, sql-сервер в качестве опорной точки (базы) никогда не возьмёт копию, созданную обновлятором, так как она copy-only. Вместо этого он обратиться к предыдущей полной копии базы, которая создавалась не как copy-only.

Всё это позволяет создавать sql-копии через обновлятор (перед опасными операциями с базой), не боясь испортить основную схему резервного копирования.

Этапы восстановления из резервной копии (ms sql)

Для базы 1с на MS SQL восстановление из резервной копии происходит в 4 шага.

Шаг 1 (ms sql)

Обновлятор принудительно завершает все соединения  (в том числе для администрирования) с базой в кластере 1с.

Шаг 2 (ms sql)

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

На этом шаге обновлятор удаляет базу из кластера 1с (без удаления соответствующей ей базе на сервере СУБД), чтобы затем (после восстановления базы на сервере СУБД из резервной копии) создать её вновь с теми же параметрами.

Шаг 3 (ms sql)

Обновлятор загружает резервную копию в соответствующую базу на сервере СУБД.

Шаг 4 (ms sql)

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

На этом шаге обновлятор вновь создаёт базу в кластере 1с с теми же параметрами и связывает её с соответствующей базой на сервере СУБД.

Нюансы для PostgreSQL

Выбор дистрибутива

Для того, чтобы обновлятор смог работать с базами 1с на PostgreSQL в настройках сервера СУБД необходимо указать путь к папке bin установленного PostgreSQL:

Дистрибутив PostgreSQL, который мы указываем в обновляторе:

• должен быть для Windows
• источники дистрибутива
  • сайта компании Postgres Professional
  • репозиторий компании Postgres Professional
  • сайта фирмы "1С"
• должен иметь версию в точности равную тому PostgreSQL, что установлен на сервере СУБД (желательный вариант), либо превосходить его

При этом нам не важно на какой ОС стоит сервер СУБД.

Вот пример рабочего окружения:

• рабочая СУБД установлена на сервере с CentOS 7: дистрибутив PostgreSQL 9.6.9 (версия для CentOS 7)
• обновлятор установлен на Windows; на этой же машине установлен PostgreSQL 9.6.9 (версия для Windows), который указан в настройках обновлятора

Проблемы с кодировкой в сообщениях от сервера СУБД

Откройте файл настроек postgresql.conf на сервере СУБД и впишите туда (вместо имеющейся) строчку:

lc_messages = 'en_US.UTF-8'

Этапы восстановления из резервной копии (postgres)

Для базы 1с на PostgreSQL восстановление из резервной копии происходит в 10 шагов. Такое большое количество шагов обусловлено требованием отказоустойчивости к выполнению операции, чтобы учесть все возможные варианты ошибок. Чтобы не получилось так, что после операции восстановления пользователь вообще остался без рабочей базы.

Шаг 1 (postgres)

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

Шаг 2 (postgres)

Обновлятор создаёт пустую временную базу на сервере СУБД, формируя её имя следующим образом: %ИмяРабочейБазы%_temp_base_for_restoring_by_updater_1c

Шаг 3 (postgres)

Обновлятор загружает резервную копию в созданную на предыдущем шаге пустую временную базу.

Шаг 4 (postgres)

Обновлятор принудительно завершает все соединения с базой (в том числе для администрирования) в кластере 1с.

Шаг 5 (postgres)

Здесь возможны два варианта

Если вы выбрали вариант восстановления "ничего не делать с базой  в кластере", то обновлятор на этом шаге устанавливает в кластере 1с для нашей базы свойство 'Имя базы данных' в пустое значение. Это нужно, чтобы кластер 1с перестал использовать соответствующую базу на сервере СУБД.

Если же вы выбрали вариант восстановления "пересоздать базу в кластере с теми же параметрами", то на этом шаге обновлятор удаляет базу из кластера 1с (без удаления соответствующей ей базы на сервере СУБД).

Шаг 6 (postgres)

Обновлятор ожидает 10 секунд, чтобы кластер 1с перестал использовать рабочую базу на сервере СУБД.

Шаг 7 (postgres)

Обновлятор переименовывает рабочую базу на сервере СУБД в другое имя, формируя его следующим образом: %ИмяРабочейБазы%__old_base_before_restoring_by_updater_1c

Шаг 8 (postgres)

Обновлятор переименовывает временную базу %ИмяРабочейБазы%_temp_base_for_restoring_by_updater_1c в рабочую базу %ИмяРабочейБазы%

Шаг 9 (postgres)

Здесь также возможны два варианта.

Если вы выбрали вариант восстановления "ничего не делать с базой  в кластере", то обновлятор на этом шаге вновь настраивает нашу базу в кластере 1с на рабочую базу %ИмяРабочейБазы% на сервере СУБД.

Если же вы выбрали вариант восстановления "пересоздать базу в кластере с теми же параметрами", то обновлятор на этом шаге вновь создаёт базу в кластере 1с и связывает её с рабочей базой %ИмяРабочейБазы% на сервере СУБД.

Шаг 10 (postgres)

Обновлятор удаляет исходную рабочую базу %ИмяРабочейБазы%__old_base_before_restoring_by_updater_1c с сервера СУБД, так как она нам больше не нужна.

Этот шаг можно отменить, установив галку 'Не удалять рабочую базу при восстановлении' в свойствах базы:

Эту галку имеет смысл устанавливать, если вы хотите лично контролировать результаты восстановления резервной копии и только затем самому удалять исходную рабочую базу %ИмяРабочейБазы%__old_base_before_restoring_by_updater_1c.

Что из себя представляет созданная резервная копия

Обновлятор создаёт резервную копию PostgreSQL следующей командой:

pg_dump --no-password --quote-all-identifiers --format=plain --dbname=postgresql://"%user_name%":"%user_password%"@"%host%"/"%base_name%" --file="backup.sql"

С подробной документацией и ключами к команде pg_dump можно ознакомиться здесь.

Формат plain выбран по следующим причинам:

• на выходе получается обычный sql файл, который, при его выполнении в чистой базе, воссоздаёт исходную базу
• все другие форматы являются теми же самыми sql файлами, но пожатыми специальным образом для специальных целей; обновлятору это ни к чему, так как он сам умеет сжимать получившийся архив, если вы устанавливаете соответствующую галку в свойствах базы
• формат plain является предпочтительным при проблемах с восстановлением базы из архива или повреждением самого архивного файла, так как его легко прочитать и отредактировать
• формирование архива в формате plain требует меньше ресурсов сервера СУБД

Чтобы восстановить резервную копию в формате plain не нужно использовать утилиту pg_restore. Она предназначена для других форматов архивов и фактически сначала разархивирует резервную копию в plain формат, а затем выполняет её в базе через psql.

Вам нужно сразу выполнять (через утилиту psql) резервную копию в формате plain в чистой базе из шаблона template0 (это должна быть чистая база в субд, созданная не через 1с).

Обновлятор умеет это делать автоматически.

Если же хотите сделать это вручную, то создайте чистую базу (через тот же pgAdmin из шаблона template0), а затем выполните вот этот скрипт для восстановления резервной копии в эту базу:

psql --echo-errors --quiet --set="ON_ERROR_STOP=on" --file="BACKUP.sql" --dbname=postgresql://"USER":"PASSWORD"@"HOST:PORT"/"NEW_BASE_NAME"

Как разрешить (или запретить) восстановление резервной копии в НЕ пустую базу

Для PostgreSQL, обновлятор, по умолчанию, запрещает восстановление резервной копии СУБД в не пустую базу 1с.

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

Это сделано в целях безопасности, чтобы по неопытности пользователь не смог затереть рабочую базу.

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

Как изменить формат архива?

По умолчанию обновлятор выгружает резервную копию в формате plain.

При необходимости вы можете изменить формат на custom:

В этом случае восстанавливать такой архив нужно будет при помощи утилиты pg_restore (если вы делаете восстановление через обновлятор он определит тип архива и правильный способ восстановления сам).

Подробнее про форматы архивов вы можете почитать в документации к утилите pg_dump.