Смещение периодов хранения резервных копий

  оглавление  Где указывается информация о сервере СУБД ?

Настройка sql-архивов (MS SQL Server и PostgrgeSQL) в обновляторе

Введение

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

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

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

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

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

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

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

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

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

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

Готово!

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

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

При этом в MS SQL Server предусмотрена защита от случайного восстановления серверной базы из резервной копии для другой базы. При попытке восстановить базу из чужой резервной копии MS SQL Server выдаст следующую ошибку:

Нюансы для 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-копии через обновлятор (перед опасными операциями с базой), не боясь испортить основную схему резервного копирования.

Нюансы для PostgreSQL

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

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

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

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

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

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

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

Сам же сервер PostgreSQL на компьютере обновлятора работать не обязан, если только этот компьютер сам не является сервером СУБД.

Чтобы отключить работу сервера СУБД после его установки, зайдите в оснастку "Службы" и отключите там запуск службы PostgreSQL, например, "postgresql-1с-9.6".

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

Для корректного отображения кириллицы в сообщениях от СУБД нужно настроить сервер так,  чтобы он отдавал их в кодировке Windows-1251 или Utf-8.

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

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

SET lc_messages TO 'en_US.UTF-8';

Подробнее здесь.

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

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

Шаг 1

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

Шаг 2

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

Шаг 3

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

Шаг 4

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

Шаг 5

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

Шаг 6

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

Шаг 7

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

Шаг 8

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

Шаг 9

Обновлятор вновь создаёт базу в кластере 1с и связывает её с рабочей базой %ИмяРабочейБазы% на сервере СУБД.

Шаг 10

Обновлятор удаляет исходную рабочую базу %ИмяРабочейБазы%__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с.

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

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

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

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



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

Нажмите одну из кнопок, чтобы поделиться:



Смещение периодов хранения резервных копий

  оглавление  Где указывается информация о сервере СУБД ?