1с обновлятор настройка резервного копирования

Обновлено: 04.07.2024

Выковал я из стали BAT-файл, да вооружил им Шедулер серверный. А файл тот был следующего содержания:

BASE_NAME - Имя базы данных, используется в наименовании лог-файлов и файлов резервных копий.

CONNECT_STR - строка подключения к информационной базе. В случае файлового варианта должна выглядить так "File=""D:\1C_Base\МояБазаДанных"";" (обратите внимание на двойные кавычки). Для клиент-серверного варината "Srvr=""ИмяСервера"";Ref=""МояБазаДанных"";".

USER_NAME и USER_PWD - Соответственно логин и пароль пользователя под которым делается обновление. Полные права давать не обязательно, в типовых конфигурациях достаточно права администрирования.

START_FILE - Путь к программе 1С:Предприятие. Следует обратить внимание на то, что нужно обращаться к конкретному релизу (например, "C:\Program Files (x86)\1cv82\8.2.19.90\bin\1cv8.exe"), а не к файлу запускатору ("C:\Program Files (x86)\1cv82\common\1cestart.exe"). Дело в том, что этот файл запускает еще один новый процесс, а сам закрывается. В этом случае BAT-файл не будет дожидаться завершения каждого отдельного действия и запустить несколько версий 1С одновременно.

BACKUP_DIR - Путь для резервных копий. Имена файлов генерируются как ИмяБазыДанных_Год-Месяц-Число.

CF_DIR - Путь к файлу обновления 1Cv8.cf. Если файл в указанной директории есть, то начинается обновление, если нет - работа BAT-файла завершается.

LOG_DIR - Путь где будут храниться лог-файлы. Имена файлов генерируются как Год-Месяц-Число_ИмяБазыДанных.

Прошу прощения за английские слова. Проблема в том, что BAT-файл должен быть в кодировке 866 OEM, а лог программа 1С пишет в 1251 ANSI.

Итак, что делает скрипт.

1. Проверяет наличие файла обновления по указанному пути. Если файла нет, то скрипт завершается.

2. Убивает зависшие процессы: tskill *1cv8* /a /v

3. Завершает работу всех пользователей и блокирует базу для входа.

4. Если в текущую дату еще не делалась резерваная копия, то делает выгрузку данных.

5. Обновляет конфигурацию.

6. Обновляет информационную базы.

7. Разблокирует базу для входа пользователей.

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

Количество копий, которое оставляет обновлятор после архивации очень гибко настраивается.

Настройки на уровне программы

Для этого заходим в дополнительные настройки программы, закладка "Архивация баз":

Дневные копии

Вот здесь настраивается количество дневных копий:

Важные пояснения. Дневные копии чистятся в разрезе меток архивации. Метки означают цель создания архива: архивация, перед обновлением, после обновления, перед опасной операцией.

Таким образом, если вы задали единое количество архивов 2, то это значит, что обновлятор будет хранить:

2 последние копии с меткой [архивация]
2 последние копии с меткой [перед обновлением]
2 последние копии с меткой [после обновления] (такой вид архива включается отдельно в дополнительных настройках)
2 последние копии с меткой [перед опасной операцией] (такой вид архива создаётся, к примеру, перед тестированием и исправлением базы)

При этом вы можете настроить отдельное количество хранимых архивов в разрезе каждой из меток, например, вот так:

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

Давайте представим, что у нас бывает 2 вида архивации: просто архивация (с меткой [архивация]), которую мы запускаем каждый день и архивация, которая делается 1 раз в неделю перед непосредственным обновлением базы (с меткой [перед обновлением]).

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

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

Обычно для метки [архивация] ставят столько копий, сколько нужно хранить архивов, а для всех остальных меток ставят по единичке.

Внимание. При необходимости вы можете зайти в дополнительные настройки программы, закладка "Системные настройки", раздел "Разное" и установить здесь опцию "Использовать единую метку архивации". Обязательно ознакомьтесь с подсказкой к этой опции справа от неё.

Периодические копии

А вот здесь количество периодических копий:

Важное пояснение.

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

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

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

Учитывайте, что даже если архив называется 2016.03.zip - это ещё не означает, что он был создан в последний день марта.

Это только означает, что в нём содержится наиболее поздняя из копий, созданных в марте 2016 года.

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

Архивы занимают своё место в периоде по мере их удаления из ежедневных или других периодических копий.

К примеру, возможна такая ситуация. Пусть мы храним 4 недельные и 2 месячные копии. Тогда, если мы зайдём в архивы, скажем, 5 февраля, то мы не обнаружим в папке "Последние копии на конец месяца" копии на конец января. И это не ошибка, так как эта копия будет всё ещё лежать в недельных копиях (как четвёртая неделя января). Вот когда эту недельную копию вытеснят другие копии - она и переместится в месячные.

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

Аналогично, если у вас нет ограничения на хранение дневных копий - нет никакого смысла настраивать периодические архивы, так как у вас не будут удаляться дневные копии.

Облака и дополнительные папки

Кроме того все эти параметры переопределяются на уровне дополнительных папок и облаков:

Настройки на уровне конкретных баз

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

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

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

В этой статье мы рассмотрим пошаговую инструкцию для:

регистрации в сервисе Яндекс.Облако
создания объектного S3-хранилища
добавления созданного хранилища в обновлятор
сколько это всё будет стоить

Мы рассмотрим все шаги на примере сервиса Яндекс.Облако, но все действия выполняются аналогично и в других сервисах, предоставляющих объектные S3-хранилища, например, в:

Зачем всё это

1. Заводим учётную запись в Яндексе: ссылка (при этом нужно обязательно сделать привязку к мобильному телефону).

2. Переходим в консоль сервиса Яндекс.Облако: ссылка.

3. Создаём платежный аккаунт для активации пробного периода: ссылка.

Создание объектного хранилища

В консоли управления (слева) выбираем пункт "Object Storage":

В открывшемся разделе нажимаем кнопку "Создать бакет" (бакет - это от английского слова Bucket, ведро):

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

Итак, имя объектного хранилища у нас уже есть (в моём случае это sdf58sdf8756sdf), осталось настроить логин и пароль для доступа к нему.

Для этого снова переходим в консоль управления облаком. На главной странице консоли отображены наши ресурсы.

Делаем двойной щелчок на каталоге default:

В открывшемся каталоге на панеле слева выбираем пункт "Сервисные аккаунты":

В открывшемся разделе нажимаем кнопку "Создать сервисный аккаунт":

У сервисного аккаунта, который будет использоваться для закачивания резервных копий в хранилище должна быть роль "editor".

Сервисный аккаунт создан, двойным щелчком открываем его редактирование:

Находим (справа сверху) и нажимаем кнопку "Создать новый ключ":

Из выпавшего меню выбираем "Создать статический ключ доступа":

Нажимаем "Создать" и получаем пару идентификатор ключа и секретный ключ:

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

Итак у нас есть (у вас будут свои значения):

имя бакета sdf58sdf8756sdf
идентификатор ключа: 6kPOhyk25aqrsGTc6ewx
секретный ключ: YqHOQvDMPNZ7y93qfr1FcbZzrO-Rzl8yWqOGptoj

Добавление созданного хранилища в обновлятор

В поле тип выбираем "Amazon S3".

Ставим необходимое количество одновременных загрузок (в случае с сервисом Яндекс.Облако не нужно бояться ограничений со стороны Яндекса).

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

В поле Bucket name указываем имя нашего бакета (у меня это sdf58sdf8756sdf).

В поле Access Key ID указываем идентификатор ключа (у меня это 6kPOhyk25aqrsGTc6ewx).

В поле Secret Access Key указываем секретный ключ (у меня это YqHOQvDMPNZ7y93qfr1FcbZzrO-Rzl8yWqOGptoj).

Итого имеем следующие настройки облака:

Внимание. Галку "После передачи файла в облако скачивать его обратно. " можно не устанавливать, так как обновлятор после загрузки запрашивает у облака контрольную сумму загруженного файла и сравнивает её с контрольной суммой локального файла.

Сохраняем облако и делаем проверку настроек:

Всё в полном порядке:

Добавление созданного хранилища в Cyberduck

Для удобной работы с ваших хранилищем вне обновлятора я рекомендую бесплатную утилиту Cyberduck.

После запуска утилиты нажимаем кнопку "Новое подключение":

Заполняем настройки облака:

Получится вот так:

Готово. Нажимаем "Подключиться."

Сколько это будет всё будет стоить

Посмотреть наши затраты можно в разделе облака Биллинг.

Тарификация идёт поминутно, поэтому если мы к примеру зальём в хранилище террабайт на пол часа, а затем удалим его, то заплатим мы в итоге только:

за одну операцию put (если мы залили этот террабайт 1 файлом)
за 30 минут использования 1 террабайта хранилища

Для холодного типа хранилища в данный момент (16.10.2019) действуют следующие расценки:

0,6712 рубля за хранение 1 гигабайта (в месяц)
за 1000 операций PUT, POST 0,7424 рубля (то есть 0.0007424 рубля за 1 операцию)
за 10000 операций GET, HEAD 0,6102 ₽ (то есть 0.00006102 рубля за 1 операцию)

Одна PUT операция - это помещение 1 файла в хранилище.

POST операция - это, например, удаление 1 файла из хранилища.

GET операция - это скачивание 1 файла из хранилища.

HEAD операция - это, например, получение информации об объекте, хранящемся в хранилище.

Внимание. Получается за операцию закачивания 1 файла мы заплатим 0.00006102 рубля, за операцию скачивания 1 файла мы заплатим 0.0007424 рубля.

Итого (не будем учитывать операции, как мы видим они в нашем случае копеечные) непрерывное хранение 1 терабайта резервных копий в хранилище Яндекс.Облака в месяц обойдётся нам в 1024 * 0.6712

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

Начиная с версии от 15 марта 2016 года в обновляторе появилась возможность делать резервное копирование для баз даже, если не найдено обновлений.

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

Для пользователей, которые всё же хотят, чтобы резервная копия базы создавалась при каждой попытке обновления базы инструкция ниже.

Переходим на закладку "Настройки программы" кнопка "Дополнительные настройки":

Здесь переходим на закладку "Обновление баз" и устанавливаем галку "Создавать резервную копию даже если не было обновлений":

Но что делать, если у нас есть доработанные базы, которые обновляем вручную? Как сделать так, чтобы обновлятор делал их резервную копию, но не пытался обновлять?

Очень просто. Заходим в свойства такой базы.

. и устанавливаем здесь галку "Эта база здесь только для архивации":

Всё. Эта база не будет обновляться, но будет участвовать в цикле обновления и соответственно архивироваться.

Осталось настроить обновление баз по расписанию и отправку отчётов на почту (статья).

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

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