Старая СУБД запускается каждое утро, пользователи входят в 1С, резервное копирование не присылает ошибок. Поэтому обновление снова переносится на следующий квартал.
В 2025 году Saritasa опросила 504 ИТ-специалиста из США. Устаревшее ПО использовали 62% их организаций. Половина опрошенных откладывала модернизацию потому, что действующая система продолжала работать. Опрос касается всего ПО, а не только СУБД и не российского бизнеса.
Для администратора 1С вопрос звучит уже: можно ли оставить текущую СУБД или пора готовить переход. Возраст версии здесь не главный критерий. Надо проверить поддержку, исправления безопасности, совместимость с 1С и восстановление резервной копии.
Работающая СУБД может остаться без исправлений
Запуск службы подтверждает лишь одно: СУБД смогла стартовать в текущем окружении. Он ничего не говорит о поддержке производителя и доступности исправлений.
Это различие видно в отчёте Счётной палаты США GAO. Ведомство изучило 69 устаревших федеральных систем и выделило 11 систем, которым модернизация нужнее остальных.
У четырёх из этих систем осталось неподдерживаемое оборудование или ПО. Семь работали с известными уязвимостями. Эти пропорции нельзя переносить на серверы 1С, но признаки риска совпадают: поддержка закончилась, уязвимость известна, исправления нет.
Проверку стоит начинать не с даты выпуска, а с четырёх вопросов.
| Признак | Что проверить у себя | Решение |
|---|---|---|
| Производитель поддерживает версию | Найдите текущую версию СУБД и сверьте её с политикой жизненного цикла производителя | Оставьте версию под наблюдением, если поддержка действует и обновления доступны |
| Для найденной уязвимости выходит исправление | Сопоставьте версию СУБД с бюллетенями производителя и установленными обновлениями | Готовьте переход, если исправление для вашей ветки уже не выпускают |
| Платформа 1С работает с целевой СУБД | Сверьте версии платформы, сервера 1С, клиента и СУБД до тестового перехода | Сначала устраните разъезд компонентов, затем повторите проверку |
| Резервная копия разворачивается отдельно | Восстановите копию на тестовом контуре и подключите к ней 1С | Не назначайте рабочее обновление, пока восстановление не пройдёт полностью |
Вывод: возраст версии сам по себе ничего не решает. Граница проходит по поддержке, неисправленным уязвимостям и проверенному пути перехода.
Версия может быть старой, но ещё получать исправления. Тогда срочный переход без подготовки добавит риска и не устранит конкретную угрозу.
Обратная ситуация опаснее. СУБД работает, но производитель уже не исправляет её ветку. Отсутствие сбоев за прошлый месяц не меняет статус поддержки.
Перед решением соберите карту окружения
Обновление СУБД затрагивает не один установочный пакет. Рядом работают платформа 1С, серверные службы, драйверы, задания резервного копирования и средства наблюдения.
Не пытайтесь вспомнить состав системы по памяти. Запишите версии компонентов, способ подключения и порядок запуска служб. Отдельно отметьте внешние обмены и задания, которые обращаются к базе без участия пользователя.
В эту карту входят только проверяемые сведения:
- версия и редакция СУБД;
- версия сервера 1С;
- версии клиентов на рабочих местах;
- расположение резервных копий;
- задания обслуживания и обмена;
- учётная запись службы СУБД;
- способ подключения тестового контура.
Такой список нужен не ради документа. По нему вы поймёте, что именно должно заработать после пробного перехода.
Если клиент и сервер 1С расходятся по сборкам, сначала устраните это расхождение. Порядок проверки описан в материале о том, как привести версии клиента и сервера 1С к одной сборке.
Не добавляйте обновление СУБД к уже сломанному окружению. Иначе после сбоя придётся разделять две причины: прежнюю ошибку и результат перехода.
Обновление тормозит страх остановить работу
В опросе Saritasa бюджет назвали препятствием 44% участников. Ещё 38% опасались нарушить работу, а 35% — потерять данные при переносе.
Выборка не описывает российские небольшие компании. В ней 47% респондентов работали в организациях от тысячи сотрудников, а 65% представляли технологическую отрасль. Эти данные показывают не частоту проблемы у владельцев 1С, а типичные причины откладывания.
Страх простоя нельзя убрать обещанием, что обновление пройдёт штатно. Его снимает пробный переход, который не затрагивает рабочую базу.
Everconnect Data Systems делит модернизацию СУБД на семь этапов: оценка, исправление проблем, тестирование, планирование переноса, проверка вне продакшена, рабочий переход и последующая настройка. Это методика компании, которая занимается SQL Server, а не инструкция производителя 1С.
Для вашей системы полезен сам порядок. Сначала выясните зависимости, затем исправьте найденные проблемы. После этого повторите переход на копии и только потом назначайте рабочее окно.
Кнопка обновления в этом порядке стоит ближе к концу. Если нажать её первой, команда узнает о несовместимости уже во время простоя.
Пробный переход должен закончиться решением
Тестовый контур нужен не для отчёта «обновление запустилось». Он должен ответить, можно ли повторить тот же порядок на рабочей системе и вернуть её при ошибке.
Начните с резервной копии средствами вашей СУБД. Разверните её отдельно: на другой машине, экземпляре или изолированном тестовом контуре. Рабочую базу не заменяйте.
После восстановления подключите тестовую базу к 1С. Проверьте вход, чтение данных и те операции, без которых компания не начнёт рабочий день.
Состав проверки зависит от конфигурации. Для одной компании критичен обмен с интернет-магазином, для другой — загрузка банковской выписки. Запишите эти операции до перехода, а не после первой жалобы.
| Этап | Какой результат нужен | Условие перехода дальше |
|---|---|---|
| Инвентаризация версий и зависимостей | Зафиксированы СУБД, сервер и клиенты 1С, задания, обмены и способ отката | У каждого компонента известны текущая и целевая версии |
| Восстановление резервной копии отдельно | Тестовая база открывается без замены рабочего экземпляра | Известно, где лежит копия и кто подтвердил её восстановление |
| Пробное обновление СУБД | Обновление повторяется по записанному порядку без ручных догадок | Все команды, файлы и учётные записи перечислены в плане |
| Подключение 1С | Сервер 1С подключается к тестовой базе, клиенты входят | Нет расхождения версий и ошибок соединения |
| Проверка рабочих операций | Выполнены заранее выбранные операции, задания и обмены | Ответственный сотрудник подтвердил результат проверки |
| Репетиция отката | Команда вернула тестовый контур к исходному состоянию | Понятны момент остановки и порядок обратного перехода |
Вывод: тест закончен лишь тогда, когда команда получила решение — переходить, исправлять ошибку или оставаться на текущей версии.
Не оценивайте пробу по одной зелёной строке установщика. Обновление может завершиться, а 1С не подключится к базе из-за окружения или версий компонентов.
Если переход оборвался на изменении структуры базы, не повторяйте его на рабочем экземпляре. Используйте порядок разбора сорванного обновления на сохранённой базе и устраняйте причину на копии.
После исправления начните репетицию заново. Иначе вы проверите продолжение повреждённого сценария, а не воспроизводимый переход.
Решение зависит от поддержки и результата репетиции
Для решения достаточно двух осей. Первая — состояние текущей версии. Вторая — результат пробного перехода.
Если производитель поддерживает ветку и выпускает нужные исправления, версию можно оставить. Запишите дату следующей проверки и событие, после которого вернётесь к вопросу.
Таким событием может стать окончание поддержки, обязательное обновление платформы 1С или найденная уязвимость без исправления. Выберите проверяемый признак, а не формулировку «когда появится время».
Неподдерживаемая ветка требует плана перехода. То же относится к версии с известной уязвимостью, для которой производитель уже не выпускает исправление.
Однако назначать рабочее окно рано, если репетиция не прошла. Сначала устраните ошибку на тестовом контуре и повторите весь порядок.
Поддерживаемая версия с неудачной репетицией остаётся под наблюдением. Команда получает время исправить тестовый сценарий без вмешательства в рабочую базу.
Неподдерживаемая версия с неудачной репетицией требует отдельного проекта. Здесь уже нельзя выбирать между «обновлять сегодня» и «ничего не делать». Надо временно снизить риск и подготовить воспроизводимый переход.
Если решение зависит от связки СУБД, платформы, обменов и серверной схемы, одной общей инструкции не хватит. После собственной инвентаризации можно заказать разбор маршрута обновления вашего контура 1С. Ссылка нужна не вместо проверки, а для системы с неочевидными зависимостями.
Откладывание не сохраняет исходную цену проекта
В 2019 году GAO выделило десять критических федеральных систем для модернизации. К февралю 2025 года ведомства завершили переход только для трёх.
GAO также пишет, что федеральные агентства тратят около 80% ИТ-бюджетов на работу и поддержку существующих систем. Это не модель бюджета небольшой компании с 1С. Масштаб и правила закупок несопоставимы.
Пример показывает другую зависимость: признанная необходимость перехода ещё не означает, что он состоится. Без срока, ответственного и критерия готовности проект остаётся в очереди.
За время ожидания меняется окружение. Обновляется платформа 1С, уходят сотрудники, теряются записи о настройках. Каждое такое изменение добавляет неизвестную в будущую репетицию.
Поэтому после решения «пока оставляем» назначьте следующую проверку. Зафиксируйте версию СУБД, срок поддержки и результат последнего восстановления копии.
После решения «переходим» назначьте не только дату работ. Укажите условия допуска: восстановление прошло, тестовый переход повторён, операции проверены, откат отрепетирован.
Правило решения на сегодня
Не обновляйте СУБД сразу на рабочей базе. Но и не оставляйте её только потому, что служба запускается.
Сегодня достаточно четырёх действий:
- Проверьте поддержку текущей версии и доступность исправлений.
- Восстановите свежую резервную копию отдельно от рабочей базы.
- Повторите обновление и подключение 1С на тестовом контуре.
- Запишите условие допуска к переходу и критерий отката.
Если все четыре пункта выполнены, назначайте рабочее окно. Если репетиция завершилась ошибкой, исправляйте её на копии и не трогайте продакшен.
Главный порог прост: пока обновление нельзя воспроизвести вне рабочей базы, компания к переходу не готова. Купленные лицензии и выбранная дата этого не меняют.