Обновление 1С через копию: когда подмена базы безопаснее штатной
Что значит «обновление через копию»
Идея простая: вместо того, чтобы блокировать боевую базу на много часов и накатывать на неё новую конфигурацию, мы поднимаем её копию на отдельном сервере (или хотя бы в отдельном кластере), обновляем уже её, и в выбранное короткое окно меняем рабочую базу на обновлённую копию. Пользователи весь день работают как обычно, ИТ-служба параллельно занимается обновлением — никто никому не мешает.
Подход не штатный в смысле «нажми одну кнопку», но и не экзотика: для баз размером в десятки–сотни ГБ это стандартная практика админов, которые однажды уже остались с пользователями на линии в три часа ночи.
Когда копия выгоднее штатного обновления
| Параметр базы | Штатное обновление | Обновление через копию |
|---|---|---|
| Размер до 20 ГБ | Уложится в ночное окно, риск низкий | Накладные расходы не оправданы |
| Размер 50–200 ГБ | Окно растёт, реструктуризация непредсказуема | Заметный выигрыш по простою |
| Большой релиз с реструктуризацией | Часы недоступности, частичный откат болезненный | Окно простоя сводится к времени переключения |
| Жёсткие SLA, круглосуточная работа | Окна нет, нужно делить пользователей по сменам | Единственный реалистичный путь |
Базовый сценарий
Подготовка копии
Снимаем актуальную резервную копию боевой базы и поднимаем её рядом — на отдельной информационной базе с другим именем. Важно: не работаем с копией под продакшн-учётной записью, разводим креденшалы, чтобы никто случайно не ушёл на копию из рабочего клиента.
Обновление в копии
На копии накатываем новую версию конфигурации поставщика и проходим стандартный цикл: тестирование и исправление, обновление информационной базы, регламентные операции после обновления (пересчёт итогов, обновление полнотекстового поиска, переиндексация). Пользователи всё это время работают в боевой базе и понятия не имеют, что админ потеет.
// Простой контроль: какая база сейчас перед нами
// Печатаем в самом начале сеанса (например, при старте РИБ-узла)
Сообщить("База: " + СтрокаСоединенияИнформационнойБазы());
Сообщить("Сервер: " + ИмяКомпьютера());Такая пара строк, выведенная в журнал регистрации или окно сообщений при старте, дешёво страхует от классической ошибки «накатил на ту базу».
Перенос накопленных изменений
Самый деликатный шаг. С момента снятия копии и до момента переключения пользователи продолжают работать в боевой базе. Эти изменения нужно перенести в обновлённую копию. Варианты — от простого к сложному:
- Самый дешёвый: запланировать переключение на короткое окно без активности (ночь, выходные) — тогда дельта минимальна, и часть смены через ручные правки решается за минуты.
- Через выгрузку/загрузку отдельных видов документов и справочников за период между снятием копии и переключением.
- Через распределённую информационную базу: на время обновления копия становится узлом РИБ, после обновления дельта проигрывается через стандартный механизм обмена.
Переключение
В выбранное окно: блокируем сеансы в боевой базе, окончательно выгребаем дельту, останавливаем фоновые задания, переименовываем боевую базу (например, в «архив-до-обновления»), переименовываем обновлённую копию в имя боевой. Пользователи на следующее утро подключаются к тем же привычным иконкам.
Не выбрасывайте старую боевую базу сразу. Оставьте её под отдельным именем хотя бы на неделю — это ваш «золотой откат». Если в новой обнаружится скрытая проблема, у вас есть актуальный снимок до обновления, а не недельной давности резерв.
Чек-лист подготовки
- Согласовать с бизнесом окно переключения. Уточнить: точно ли никто не закрывает квартал именно в эту субботу.
- Снять полную резервную копию боевой базы. Проверить, что копия восстанавливается на тестовом сервере.
- Поднять копию на отдельном сервере или в отдельном кластере. Развести учётные записи администратора и пользователей.
- Накатить новую версию конфигурации в копии, выполнить тестирование и исправление, регламентные операции после обновления.
- Прогнать дымовой сценарий: проведение типового документа, формирование отчёта, обмен с маркетплейсом. Зафиксировать, что обновлённая копия работает.
- Согласовать с пользователями способ переноса дельты: окно без активности или временный обмен через РИБ.
- В окне переключения: блокировка сеансов, выгрузка дельты, остановка фоновых заданий, переименование баз.
- После переключения: оставить старую базу под архивным именем на 5–7 дней, мониторить логи и обращения.
Типичные ошибки
- Не развели учётные записи. Пользователь в понедельник утром заходит «как обычно», попадает на старую базу-архив, проводит документы. К вечеру обнаруживается расхождение, и приходится переносить уже его правки. Решение — на старой базе при следующем заходе показать заблокированное сообщение или закрыть к ней доступ полностью.
- Не сняли копию прямо перед переключением. Снятая копия трёхдневной давности и обновлённая в ней конфигурация — это нормально. Но боевую базу нужно перерезервировать прямо перед переключением, иначе при необходимости отката вы потеряете несколько рабочих дней.
- Забыли про регламентные задания. На обновлённой копии расписание регламентных заданий может быть включено. Если копия и боевая база какое-то время живут параллельно, оба экземпляра шлют исходящие письма, ходят к маркетплейсам, делают выгрузки. Перед запуском копии в продакшен — пройтись по расписанию и проверить, что чужие задания отключены.
- Не подготовили обратный путь. Старую базу удалили сразу после переключения. Через сутки нашли проблему, которую на стенде не воспроизвели. Откат теперь — только из вчерашнего резерва, без актуальных рабочих данных. Старую базу храним под архивным именем минимум неделю.
- Дельта собрана «на глазок». Полагаемся на то, что в окне переключения пользователи ничего не делают. В реальности кто-то всегда что-то делает — менеджер дописывает документ, бухгалтер закрывает день. Дельту нужно собирать явно: журнал регистрации по периоду, отбор по видам объектов, перенос.
Перейти в каталог решений →