Переход сервера 1С на новую операционную систему: порядок действий
Содержание
Модернизация ОС для 1С — это перевод сервера, где работает платформа 1С:Предприятие, на поддерживаемую версию операционной системы: чаще всего с устаревшей Windows Server на актуальную, реже — переезд на Linux. Операционная система здесь ниже платформы: от её версии зависит, запустится ли вообще нужный релиз сервера 1С и будут ли закрыты уязвимости.
Речь не про обновление конфигурации («Бухгалтерия», ЗУП) и не про обновление самой платформы — это разные слои, которые часто путают. Ниже — чем они отличаются, что проверить до переезда, как перенести сервер на новую ОС без потери баз и что перенастроить в кластере после миграции.
Смена ОС на боевом сервере останавливает работу всех пользователей. Планируйте окно на выходные или ночь и заранее предупредите бухгалтерию.
Зачем серверу 1С актуальная операционная система
Каждый релиз платформы имеет свои системные требования — список ОС, на которых он официально работает. Старые версии Windows Server из этого списка со временем выпадают: установщик сервера 1С на них либо не ставится, либо агент сервера не стартует как служба.
Причин держать ОС в актуальном состоянии несколько:
- 🔐 Безопасность. После окончания поддержки Windows перестаёт получать патчи. Сервер с бухгалтерскими базами на таком узле — прямая мишень для шифровальщиков.
- ⚡ Производительность. Новые версии ОС лучше работают с современным железом, многоядерными процессорами и большими объёмами RAM, которые любит сервер 1С.
- 🧩 Совместимость. Свежие релизы платформы тестируются на актуальных ОС. На снятой с поддержки системе вы остаётесь на старом релизе и не можете обновить конфигурацию , если она требует более новую платформу.
- 🗄 СУБД. Новые версии MS SQL Server и PostgreSQL тоже требуют актуальной ОС. Модернизация часто идёт в связке «ОС + СУБД + платформа».
Отдельно про разрядность: сервер 1С:Предприятия ставится в 64-разрядном варианте, и ОС тоже должна быть 64-битной. Это давно норма, но на старых виртуалках ещё встречаются 32-битные системы — их переносят на 64 бита.
Типичный повод для модернизации — связка причин сразу. Например, вышел из поддержки Windows Server, одновременно бухгалтерия требует обновить конфигурацию до релиза, которому нужна более новая платформа, а новая платформа официально не тестировалась на старой ОС. Разматывать такой клубок приходится снизу вверх: сначала ОС, потом СУБД и платформа, в конце конфигурация.
Чем смена ОС отличается от обновления платформы и конфигурации
Три уровня обновлений живут независимо, и модернизация ОС касается только нижнего:
| Что обновляем | Что это | Как выполняется |
|---|---|---|
| Операционная система | Windows Server / Linux под сервером | Средствами ОС или переездом на новый сервер |
| Платформа 1С | Технологическое ядро (сервер + клиент) | Установщиком новой версии платформы |
| Конфигурация | Прикладное решение (учёт, зарплата) | Через Конфигурация → Поддержка → Обновить |
Логика такая: сначала должна быть подходящая ОС, на неё ставится совместимая платформа, и уже на платформе работает конфигурация, которую обновляют отдельно.
Перед сменой ОС посмотрите системные требования того релиза платформы, который планируете использовать после миграции. Новая ОС не должна оказаться «слишком новой» для вашего текущего релиза сервера — тогда сначала поднимают платформу, потом переезжают.
Что проверить и подготовить до перехода на новую ОС
Главное правило — ничего не удалять на старом сервере, пока новый не проверен в бою. Переезд делают так, чтобы к старой конфигурации можно было вернуться.
Разберитесь с составом инфраструктуры. Сервер 1С почти никогда не стоит в одиночку — рядом СУБД (MS SQL или PostgreSQL), иногда сервер лицензирования, веб-сервер для публикации баз. Для каждого компонента отдельно проверьте, поддерживает ли его новая ОС.
Соберите исходные данные со старого сервера:
- номер релиза платформы (его видно в
racили в свойствах службы агента); - список информационных баз кластера и строки подключения к СУБД;
- каталог данных кластера (
srvinfo) — там лежит реестр кластера; - параметры служб: порты, учётная запись, под которой работает агент сервера.
Обязательно сделайте резервные копии всех баз средствами СУБД (а не выгрузку в .dt для крупных баз) и копию каталога srvinfo. Без этого откат невозможен.
Проверьте лицензирование. Если используются программные лицензии сервера, они привязаны к характеристикам машины. Смена ОС, а тем более переезд на новое железо, может потребовать переполучения или переноса лицензии. Аппаратный ключ HASP просто переставляется на новый сервер, но нужны драйверы под новую ОС.
Обновление ОС поверх или переезд на новый сервер
До начала работ выбирают стратегию. Вариантов два, и они сильно различаются по риску.
Обновление «поверх» (in-place). ОС обновляется на той же машине, платформа и базы остаются на месте. Быстро и без переноса данных, но сбой в процессе может оставить сервер нерабочим, а откат к прежней версии ОС штатными средствами чаще всего невозможен.
Переезд на новый сервер. Поднимается чистая машина с актуальной ОС, на неё переносятся СУБД, платформа и базы. Дольше и требует второго сервера, зато старая машина остаётся целой — если что-то пойдёт не так, пользователей возвращают на неё за минуты.
| Критерий | Обновление поверх | Переезд на новый сервер |
|---|---|---|
| Скорость | Быстрее | Дольше |
| Возможность отката | Почти нет | Есть, старый сервер цел |
| Риск для боевых баз | Высокий | Низкий |
| Нужен второй сервер | Нет | Да |
| Когда подходит | Тестовые стенды, некритичные базы | Продуктивные базы бухгалтерии |
Для боевого сервера с рабочими базами выбирают переезд. In-place оправдан на тестовых стендах и там, где простой не критичен, а запасного железа нет.
Как перевести сервер 1С на новую ОС: порядок действий
Ниже — последовательность для переезда на новый сервер как наиболее безопасного варианта.
- Поднимите новую машину с актуальной ОС, установите все обновления безопасности.
- Остановите на старом сервере службу агента 1С и службу СУБД, чтобы базы не менялись. Это оборвёт все сеансы — делайте в согласованное окно.
- Сделайте финальные резервные копии баз и скопируйте каталог
srvinfo. - Установите на новый сервер СУБД той версии, что поддерживает новая ОС, и восстановите базы из копий.
- Установите сервер 1С:Предприятия (компонента «Сервер 1С:Предприятия» в инсталляторе). Берите тот же номер релиза, что был на старом сервере, либо не ниже него.
- Зарегистрируйте и запустите службу агента сервера. Инсталлятор предлагает создать службу автоматически; при ручной настройке указывают каталог данных кластера.
- Проверьте, что служба стартовала и кластер поднялся — консолью
racили консолью администрирования.
Если переносите вместе с данными кластера каталог srvinfo со старого сервера, информационные базы «подхватятся» в кластере автоматически — не придётся добавлять каждую вручную. Это удобно при большом числе баз.
Когда сервер поднят, не удаляйте старую машину. Дайте пользователям поработать несколько дней, последите за журналом регистрации и технологическим журналом. Только убедившись, что всё стабильно, выводите старый сервер из эксплуатации.
Что настроить в кластере серверов после переезда
После установки сервера на новой ОС кластер нужно привести в рабочее состояние — на новой машине он создаётся с настройками по умолчанию.
Строки подключения к СУБД. Если адрес сервера СУБД сменился (новое имя машины или IP), откройте свойства каждой информационной базы в консоли администрирования и поправьте сервер баз данных. Иначе база не откроется — агент не найдёт СУБД.
Порты и брандмауэр. Сервер 1С по умолчанию использует порт агента 1540, порт менеджера кластера 1541 и диапазон портов рабочих процессов 1560-1591. На новой ОС брандмауэр их закрывает — откройте эти порты для подключений клиентов, иначе пользователи получат ошибку соединения.
Параметры кластера. Если на старом сервере были настроены рабочие серверы, требования назначения функциональности, допустимый объём памяти рабочих процессов — задайте их заново через консоль администрирования или командами rac. Эти настройки не переносятся вместе с базами.
Полезные команды консоли rac для проверки:
rac cluster list
rac infobase summary list --cluster=<идентификатор кластера>
rac session list --cluster=<идентификатор кластера>
Первой командой получаете идентификатор (UUID) кластера, его подставляете в остальные. Если сомневаетесь в наборе параметров команды — вызовите rac help, выдумывать ключи не нужно.
Публикация баз на веб-сервере. Если базы публиковались для тонкого клиента , веб-клиента или мобильного доступа через IIS или Apache, веб-сервер на новой ОС настраивается заново, и публикации создаются повторно — они тоже не переезжают сами. Проверьте и внешние адреса: если клиенты ходили на базу по доменному имени или через проброс порта, после смены сервера адрес мог поменяться, и ярлыки на рабочих местах придётся обновить.
Проверка после настройки. Прежде чем пускать всех пользователей, зайдите в каждую базу сами: откройте, выполните несколько типовых операций, проведите тестовый документ. Отдельно проверьте обмены и интеграции, если они были, — внешние подключения после смены ОС и адресов часто отваливаются первыми.
Антивирус. На свежей ОС антивирус включён по умолчанию и проверяет всё подряд. Каталоги баз СУБД, каталог данных кластера srvinfo и рабочие каталоги сервера 1С добавляют в исключения — иначе постоянное сканирование файлов блокировок и временных файлов резко тормозит работу и изредка приводит к ошибкам доступа. Это одна из самых частых причин «после переезда всё стало медленно».
После переезда проверьте регламентные задания. При смене сервера расписания сохраняются в базе, но убедитесь, что они не задублировались, если старый сервер ещё работает параллельно. Два агента, работающих с одной базой одновременно, — источник трудноуловимых сбоев, поэтому старый сервер отключают от боевых баз, как только новый принят в эксплуатацию.
Частые ошибки после смены ОС и как их устранить
Большинство проблем после модернизации ОС — это незакрытые порты, несовпадение версий или забытая настройка подключения к СУБД.
Отдельно про монопольный доступ: он нужен не «всегда при обновлении», а только для операций, меняющих структуру, — реструктуризации при обновлении конфигурации, загрузки .dt, тестирования и исправления базы. Для планового обновления релиза платформы монополия не требуется.
Если после переезда база работает медленнее, чем на старом сервере, в первую очередь смотрите не на 1С, а на СУБД: план обслуживания индексов, объём памяти под MS SQL или настройки PostgreSQL часто сбрасываются на новой машине к значениям по умолчанию.