Windows Server 2012 R2 без поддержки: куда переезжать 1С и файловому серверу

За последний год я поднял, наверное, восьмой или девятый сервер на Windows Server 2012 R2 у новых клиентов. Каждый раз одна и та же картина: старый добрый сервер тянет 1С и общие папки, работает без нареканий, а поддержка у него закончилась ещё в октябре 2023-го. Владелец узнаёт об этом от меня, а не от Microsoft — вот в чём беда. Разберу конкретно: что с этим делать, куда переезжать и сколько это будет стоить.

Почему это не «пугалка для галочки»

Расширенная поддержка Windows Server 2012 R2 закончилась 10 октября 2023 года. Всё, финал. Обновлений безопасности больше нет, если только вы не купили ESU — а этой опции для 2012 R2 уже тоже нет, срок вышел. То есть каждая новая уязвимость, найденная в системе, остаётся дырой навсегда.

Звучит абстрактно, пока не увидишь конкретный кейс. У одного клиента из сферы оптовой торговли шифровальщик зашёл именно через сервер на 2012 R2 — не через почту, не через фишинг, а через открытый наружу RDP на непропатченной системе. Три дня простоя, база 1С восстанавливалась из бэкапа недельной давности, потеряли часть накладных. Обошлось это дороже, чем стоила бы вся миграция раза в три.

И это не единичная история. Если у вас в сети висит сервер без поддержки, страховая при инциденте с шифровальщиком имеет полное право отказать в выплате — формально это уже не «должная осмотрительность». Я видел такой отказ своими глазами в переписке с одной страховой компанией.

Что реально сломается, если тянуть до последнего

Сама ОС не перестанет работать в один день — это не лицензионный ключ с датой отключения. Проблема в другом: экосистема вокруг неё постепенно вымирает. Новые версии 1С:Предприятие всё требовательнее к платформе. Уже сейчас свежие релизы платформы 8.3.2x официально не тестируются под 2012 R2, а через год-два просто перестанут запускаться.

КриптоПро CSP — отдельная больная тема. Для сдачи отчётности, работы с ЭДО и УКЭП нужны свежие версии крипто-провайдера, а они всё чаще требуют минимум Windows Server 2016. У клиента из бухгалтерской сферы в марте была ситуация: обновили КриптоПро под требование банка, а старая версия слетела и не встала обратно — три дня без возможности подписать платёжки.

Плюс железо. Серверы, купленные под 2012 R2, — это обычно 2013-2015 год выпуска. RAID-контроллеры, диски, блоки питания — всё это уже выработало ресурс. Миграция ОС без замены железа — это откладывание одной проблемы ради того, чтобы упереться в другую, буквально через полгода.

Инвентаризация: с чего реально начинать

Прежде чем куда-то переезжать, я всегда делаю снимок текущего состояния. Занимает день-полтора, но экономит недели на этапе миграции. Смотрю: версию платформы 1С и релиз конфигурации, тип СУБД (файловая база или SQL Server, и если SQL — какая редакция и версия), состав ролей на сервере (это ещё и контроллер домена, или чистый файловый/1С-сервер), объём данных на файловых шарах, количество и структуру пользователей и групп в правах NTFS.

Отдельно проверяю лицензии. У половины клиентов SQL Server стоит либо Express (лимит 10 ГБ на базу — а база 1С уже 40 ГБ), либо вообще без документов на лицензию, потому что «так исторически сложилось» ещё с прошлого админа. Это надо решать до миграции, а не после.

И последнее — железо сервера. Если это физическая машина старше 6-7 лет, разговор сразу смещается в сторону виртуализации или облака, а не «поставим новую ОС на тот же корпус».

Куда переезжать: три реалистичных маршрута

Первый вариант, самый предсказуемый — Windows Server 2022 Standard (или уже 2025, если хотите с запасом на будущее). Знакомая экосистема, привычное администрирование, всё совместимо с 1С и КриптоПро без сюрпризов. Лицензия Standard с 16 ядрами обойдётся примерно в 130-160 тысяч рублей плюс клиентские CAL — по 1000-1500 рублей за пользователя. Для компании на 20-25 рабочих мест итог получается в районе 180-220 тысяч только на лицензии.

Второй вариант — перенос сервера 1С на Linux (обычно Astra Linux или Debian) с PostgreSQL вместо MS SQL. Экономия на лицензиях серьёзная — PostgreSQL бесплатный, Linux-дистрибутив российской разработки тоже часто дешевле пакета Windows+SQL. Но есть нюанс: не любая конфигурация 1С одинаково хорошо ведёт себя на PostgreSQL, особенно самописные доработки с прямыми SQL-запросами. У одного производственного клиента переезд на PostgreSQL сэкономил 340 тысяч на лицензиях, но потребовал три недели доработки отчётов, которые раньше использовали специфичный T-SQL синтаксис.

Третий маршрут — облако. Поднять сервер 1С в облачном 1С:Фреш или у хостера с почасовой оплатой виртуальной машины. Для файлового сервера — облачное хранилище с синхронизацией или NAS вместо выделенного Windows-сервера под общие папки. Плюс — не надо думать про железо вообще, минус — ежемесячный платёж вместо разовой покупки, и для компаний с медленным интернетом в офисе это может быть больным местом при работе с толстым клиентом 1С.

Как переносить сервер 1С без остановки продаж

Первым делом поднимаю новый сервер параллельно со старым — не трогая продакшн. На новой машине или виртуалке разворачиваю целевую ОС, СУБД, платформу 1С той же версии, что и на старом сервере. Это критично: сначала переносим «один в один», модернизацию платформы делаем отдельным шагом уже после того, как всё стабильно заработало.

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

Сама миграция «на боевую» происходит в пятницу вечером или в выходные. Финальная синхронизация базы, переключение клиентов на новый адрес сервера (через ярлыки или список баз 1С, если пользователей немного — вручную за 15 минут), контрольный запуск в понедельник утром вместе с ключевыми сотрудниками. Старый сервер не выключаю сразу — держу в режиме «холодного резерва» минимум две недели.

Файловый сервер: тут другая логика

С файлами всё проще технически, но муторнее по правам доступа. Обычно за годы работы на 2012 R2 права NTFS на шарах превращаются в археологический памятник — группы, которые никто не помнит зачем создавал, доступ у уволенных сотрудников, дублирующиеся разрешения. Миграцию использую как повод почистить: выгружаю дерево папок с текущими ACL, сверяю с актуальным штатным расписанием, пересобираю группы безопасности по отделам.

Технически перенос делаю через robocopy с ключами /COPYALL /MIR /ZB — сохраняет владельца, атрибуты, права и время создания файлов, догоняет инкрементально без повторного копирования всего объёма. Для 300-400 ГБ типичной небольшой компании (юрфирма, клиника, малое производство) первый полный прогон занимает ночь, финальная синхронизация перед переключением — минут 20-30.

Если сервер совмещал роль DFS или был точкой входа для резервного копирования Veeam — это тоже переносим отдельным пунктом, до переключения пользователей, а не после. Забыть про Veeam и вспомнить о нём через месяц, когда бэкапы тихо не делались, — классика жанра, видел трижды за последний год.

Сроки, бюджет и что чаще всего идёт не так

Для компании на 20-30 рабочих мест с одним сервером 1С и одним файловым сервером на том же или соседнем железе весь проект — от инвентаризации до полного отключения старой системы — занимает обычно 3-4 недели. Из них собственно «даунтайм», когда сотрудники не могут работать, — от 2 до 6 часов, если всё спланировано правильно, и делается это в нерабочее время.

Бюджет складывается из трёх частей: лицензии (ОС, СУБД, CAL) — от 150 до 400 тысяч рублей в зависимости от маршрута; железо, если сервер старше 6 лет — от 250 тысяч за нормальную конфигурацию с RAID и резервным питанием; и работы по переносу — обычно 60-120 тысяч рублей для проекта такого масштаба, в зависимости от количества доработок в 1С.

Что чаще всего идёт не так — недооценка кастомных доработок в 1С. Клиент говорит «у нас типовая конфигурация», а на деле там пять внешних обработок для маркетплейса, самописный обмен с сайтом и отчёт, который дергает СУБД напрямую. Всё это всплывает не на этапе планирования, а в процессе тестового переноса — и хорошо, если на этом этапе, а не в первый рабочий день после миграции.

Частые вопросы

Можно ли просто обновить Windows Server 2012 R2 до 2019 или 2022 in-place, без переноса на новый сервер?
Технически Microsoft разрешает апгрейд только через одну версию за раз (2012 R2 → 2016 → 2019), и на старом железе это часто упирается в драйверы и совместимость контроллеров. На практике я почти никогда так не делаю — слишком высок риск получить систему с накопившимся мусором от прошлой ОС. Параллельный перенос на новый сервер безопаснее и позволяет откатиться в любой момент.

У нас слабое железо, обновлять его дорого. Что делать с 1С в таком случае?
Здесь разумно смотреть в сторону облака — либо готового решения вроде 1С:Фреш, либо аренды виртуального сервера у хостера с оплатой по факту использования. Это снимает вопрос капитальных затрат на железо и перекладывает его в операционные расходы, что часто удобнее для небольшой компании.

Сколько по времени сотрудники не смогут работать во время миграции?
При нормальной подготовке — от 2 до 6 часов, и планируется это на вечер пятницы или выходные. Всё, что можно сделать заранее (развёртывание новой системы, тестовый перенос базы, проверка обработок), делается без остановки текущей работы. Реальный простой — это только финальная синхронизация и переключение пользователей.

Нужно ли переходить сразу и на новую версию платформы 1С, и на новую ОС одновременно?
Я настоятельно не советую совмещать эти шаги. Сначала переносим текущую версию платформы на новую ОС один в один, убеждаемся, что всё работает стабильно хотя бы пару недель, и только потом планируем обновление самой конфигурации 1С отдельным проектом. Совмещение двух изменений сразу сильно усложняет диагностику, если что-то пойдёт не так.