Перенос 1С на другой сервер: база — это десять процентов работы

Приветствую вас, коллеги!

Тема прикладная. Она для тех, кто по итогам диагностики или роста решил менять сервер - и теперь думает, как перенести туда 1С.

Сразу главная мысль, ради которой стоит читать дальше: сам перенос базы - это процентов десять всей работы. Остальные девяносто - это то, что живет вокруг базы и переезжает отдельно, причем каждое своим способом.

Именно из этих девяноста процентов и складываются истории про "переехали в выходные, а в понедельник ничего не работает".

Разбираемся))

Почему переезды идут не по плану

Начну с наблюдения.

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

А в понедельник выясняется, что:

• 1С не запускается, потому что лицензия не активируется на новом железе;
• ночью не сделался бэкап, потому что задание в планировщике осталось на старом сервере;
• не ушли документы по ЭДО, потому что настройки обмена не перенесли;
• кассы не видят базу;
• половина пользователей не может подключиться, потому что у них в списке баз старый адрес;
• внешняя обработка, которой пользуется бухгалтерия, лежала в папке на старом сервере.

База при этом переехала прекрасно. Она целая, данные на месте, все корректно. Просто вокруг нее было еще двенадцать вещей, и про них не подумали.

Поэтому дальше я разберу именно это окружение, а не копирование файлов.

Начинать надо не с базы, а с лицензий

Вот самое важное практическое правило. Первый шаг переезда - выяснить, чем у вас лицензирована 1С. До планирования, до выбора выходных, до всего.

Потому что вариантов два, и они принципиально разные по сложности.

Программная лицензия. Файл, привязанный к параметрам компьютера. При смене железа может не активироваться - и это основной источник проблем при переезде.

Аппаратный ключ HASP. Физическая железка в USB-порту. Переставляется свободно.

Если у вас HASP - выдохните, эта часть переезда у вас простая. Если программная - читайте следующие два раздела внимательно, там лежит главная мина.

Программная лицензия: к чему она привязана

Разберу механику, потому что она объясняет, почему лицензия "слетает" в самых неожиданных случаях.

Программная лицензия - это защищенный файл, привязанный к набору параметров машины. Среди них:

• версия операционной системы и дата ее установки;
• серийный номер процессора;
• идентификаторы материнской платы;
• MAC-адрес сетевой карты;
• параметры жесткого диска.

Что приводит к потере активации:

• замена материнской платы - практически гарантированно;
• переустановка или обновление операционной системы;
• смена процессора или диска;
• обновление BIOS;
• и вот это неочевидное: переименование компьютера в доменной сети.

Последний пункт стоит выделить. Человек не менял железо, не переустанавливал систему - просто переименовал сервер, чтобы название было понятнее. И лицензия слетела.

А теперь правило, которое проще всех этих списков. Привязка смотрит не на любое изменение, а на убыль и замену. Добавление устройств и рост объема оперативной памяти не анализируются вообще: поставили вторую планку, добавили второй диск - лицензия этого не заметит.

Но у правила есть оборотная сторона, и она неочевидная: память нельзя уменьшать. Ниже того объема, что был на момент активации, - и лицензия слетит. На переезде это ловит там, где планки из старого сервера раскидывают по двум машинам, и на одной из них памяти оказывается меньше, чем было.

Практический вывод для переезда: новый сервер - это новая материнская плата, новый процессор, новый MAC-адрес и новая установка системы. То есть все параметры привязки меняются сразу. Лицензию придется восстанавливать, и это не исключение, а норма.

Резервных пин-кодов конечное число. И их могли уже потратить

Вот главная мина, и про нее надо знать заранее.

Восстановление программной лицензии делается резервным пин-кодом. Они идут в комплекте с лицензией - не один, а несколько; для поставок платформы 8.3 обычно называют пять. И вот ключевое:

Каждый пин-код используется ровно один раз.

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

А теперь про то, почему это важно именно для вас.

Если 1С у вас стоит не первый год, вполне возможно, что часть пин-кодов уже потратили, а то и все. При переустановке Windows. При замене диска. При том самом переименовании сервера. Причем делал это, скорее всего, не вы, и никаких записей об этом не осталось.

Поэтому выяснять надо не «есть ли у меня резервный пин-код», а сколько их осталось. Это разные вопросы, и второй - правильный.

Что делать, если пин-коды закончились. Обращаться в 1С - письмом на адрес поддержки по лицензированию, с регистрационным номером продукта, наименованием организации и ИНН, и с объяснением причины.

Отвечают обычно в течение одного-трех рабочих дней.

И вот из этого следует главное для планирования. Если вы переезжаете в субботу, а пин-код окажется потраченным - вы получите ответ от 1С не раньше вторника. И до вторника ваша 1С не работает.

Поэтому порядок такой:

За неделю-две до переезда выясните, какая у вас лицензия и сколько резервных пин-кодов осталось неиспользованными. Найдите документы. Если не находятся - обращайтесь в 1С заранее, а не в момент переезда.

Это тот самый случай, когда двадцать минут подготовки экономят три дня простоя.

HASP: почему с ним спокойнее

Для сравнения - как это выглядит с аппаратным ключом.

HASP - физический USB-ключ. Есть локальные, есть серверные для сетевого использования. Привязки к железу нет никакой: ключ можно переставить в другой компьютер, и все работает.

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

Но и у HASP есть своя цена:

Ключ можно потерять или сломать. Это физический предмет в USB-порту, и он не вечный. Замена заказывается в 1С, занимает недели и стоит денег.

Ключ надо физически иметь. Если сервер переезжает в дата-центр или вы берете сервер в аренду - ключ надо как-то туда доставить, и это отдельный вопрос.

На виртуальных серверах с USB бывает сложно. Не всегда есть способ подключить физическую железку.

Поэтому универсального "лучше" здесь нет. Просто знайте, что у вас, и планируйте соответственно.

Что живет вокруг базы и переезжает отдельно

Тот самый список на девяносто процентов работы. Забирайте целиком, он полезнее всей остальной статьи.

Лицензии - серверная и клиентские. Про них выше. И отдельно: деактивируйте лицензии на старом сервере, если это предусмотрено вашей схемой. Иначе бывает, что на новом активировать уже нельзя.

Настройки кластера серверов 1С - рабочие процессы, требования назначения функциональности, параметры. На новом сервере это надо воспроизвести, само не переедет.

Регламентные задания. Живут в базе, но их состояние и расписание стоит проверить после переезда. Классика: после переноса все задания запустились одновременно, и сервер лег.

Расширения конфигурации. Проверить, что подключились и работают.

Внешние обработки и отчеты. Вот это забывают чаще всего. Они лежат файлами - в папке на сервере, в общем каталоге, иногда просто на рабочем столе у главбуха. Найти все и перенести.

Публикация на веб-сервере, если база опубликована. Веб-сервер, настройки публикации, сертификат для защищенного соединения - все заново.

Настройки ЭДО и обменов. Подключения к оператору, настройки обмена с Честным знаком, с банком, с кассами, с маркетплейсами. Каждое отдельно.

Сертификаты и криптопровайдер. Подписи должны работать на новом сервере: установленный криптопровайдер, сертификаты в хранилище, драйверы токенов.

Подключенное оборудование. Сканеры, кассы, принтеры этикеток, весы. Настройки подключения торгового оборудования - отдельная работа, и проверять надо каждую единицу.

Задания планировщика операционной системы. Прежде всего - бэкапы. Скрипты живут на сервере, а не в базе, и про них забывают в половине переездов. Именно так и получается, что месяц никто не делает копии.

Учетные записи служб и права. Под какой учеткой работает сервер 1С, какие у нее права на каталоги и на СУБД.

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

Пути подключения у пользователей. В списке баз у каждого прописан адрес старого сервера. Либо меняете централизованно, либо каждому руками. Это надо запланировать, а не обнаружить в понедельник.

COM-компоненты и внешние библиотеки, если конфигурация их использует. Под Windows это отдельная установка и регистрация.

Четырнадцать пунктов. Ни один из них не переезжает сам вместе с базой.

Порядок переезда с минимальным простоем

Схема, которая дает переключение за час-два вместо выходных.

Шаг 1. Подготовка, за неделю. Лицензии - какие, есть ли пин-коды. Инвентаризация того списка из четырнадцати пунктов применительно к вам. Что есть, чего нет.

Шаг 2. Поднять новый сервер полностью. Платформа 1С версии не ниже текущей, СУБД, криптопровайдер, веб-сервер если нужен, драйверы оборудования. Все, кроме данных.

Шаг 3. Перенести тестовую копию базы. Не рабочую. Копию.

Шаг 4. Проверить все на копии. Лицензия активировалась? Расширения работают? ЭДО подключается? Оборудование видно? Печатные формы печатаются? Вот здесь вы найдете все проблемы - в спокойном режиме, при работающем старом сервере.

Шаг 5. Исправить найденное. Столько времени, сколько нужно. Никто не ждет.

Шаг 6. Дождаться окна и перенести свежую копию. Вот только теперь, когда все проверено, делаете актуальную копию и переносите. Пользователей отключаете на это время.

Шаг 7. Переключить клиентов. Пути в списке баз.

Шаг 8. Не выключать старый сервер. Минимум неделю пусть стоит, выключенный от пользователей, но целый. Это ваш путь отката.

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

Переносить рабочую базу сразу, без прогона на копии, - это и есть та самая история про понедельник.

Почему выгрузка в .dt — плохой способ для большой базы

Технический момент, который экономит часы простоя.

Привычный способ перенести базу - выгрузить в файл .dt через конфигуратор и загрузить на новом месте. Работает, все так делают.

Но для клиент-серверной базы это медленно. Выгрузка требует монопольного режима, занимает много времени, и загрузка на новом месте тоже небыстрая. На большой базе это часы, а иногда и больше.

Штатные средства СУБД быстрее в разы. Для MS SQL - восстановление из резервной копии базы данных. Для PostgreSQL - выгрузка и восстановление штатными утилитами. По разным оценкам, разница в скорости на больших базах кратная.

И второе, о чем я писал раньше: выгрузка в .dt не считается полноценной резервной копией. Если в базе есть нарушения целостности, часть данных может не выгрузиться - и вы узнаете об этом при загрузке, когда пути назад уже мало.

Практический вывод: .dt хорош как способ перенести небольшую базу. Для большой клиент-серверной базы - средства СУБД.

Что проверить после переключения

Список на первый час после переезда. По порядку.

Первое: заходит ли пользователь. Самый простой тест, и он проверяет лицензии и подключение сразу.

Второе: проводится ли документ. Возьмите типовой документ и проведите. Это проверяет права на СУБД и работу базы.

Третье: печатается ли печатная форма. Проверяет внешние компоненты и настройки печати.

Четвертое: работают ли обмены. Отправьте один документ по ЭДО. Дождитесь, что ушел.

Пятое: видно ли оборудование. Сканер, касса, принтер этикеток - каждое проверить физически.

Шестое: прошел ли бэкап. Вот это проверяете на следующее утро - обязательно. Задание в планировщике должно быть на новом сервере и должно отработать.

Седьмое: как себя ведут регламентные задания. Посмотрите в течение дня, не запустилось ли все одновременно.

И на неделю - наблюдение. Что-то всплывет. Что-то работало через старый сервер способом, о котором никто не знал.

Чек-лист перед переездом

Шесть вопросов. Если хотя бы на один нет ответа - переезд пока не готов.

1. Чем лицензирована 1С - программная или HASP? Если программная, сколько резервных пин-кодов осталось неиспользованными?
2. Собран ли список окружения - все четырнадцать пунктов применительно к вам?
3. Найдены ли все внешние обработки и известно ли, где они лежат?
4. Прогонялась ли копия на новом сервере со всеми проверками?
5. Как будут переключаться пути у пользователей - централизованно или руками?
6. Остается ли старый сервер целым хотя бы на неделю?

Первый пункт - самый срочный. Именно он определяет, будет ли у вас простой на три дня или на час.

Если переезжать некому

Как вы помните, я айти-специалист: собираю и настраиваю серверы, веду 1С для организаций.

Чем помогаем:

• разбираемся с лицензиями до переезда - что у вас, сколько пин-кодов осталось, что делать, если закончились;
• собираем список окружения - все, что живет вокруг базы и переедет отдельно;
• поднимаем и настраиваем новый сервер под вашу нагрузку;
• прогоняем копию и находим проблемы заранее, при работающем старом сервере;
• переносим базу средствами СУБД, а не через .dt, если база большая;
• переключаем пользователей и проверяем все по списку после переключения;
• сдаем в аренду серверы с поддержкой - тогда переезд и его сопровождение наша работа целиком.

Подробнее про обслуживание: 1c.akernel.ru/services/it-podderzhka

А если переезжаете сами - начните с лицензии. Выясните сегодня, чем лицензирована ваша 1С и сколько резервных пин-кодов осталось. Это двадцать минут, и это единственный пункт, который может превратить часовой переезд в трехдневный простой)

Читайте также: Какой сервер нужен под 1С, 1С тормозит: диагностика за 30 минут, Ваш бэкап 1С точно рабочий? и Переезжать ли с MS SQL на PostgreSQL.

Сведения о привязке программной лицензии и о восстановлении по резервному пин-коду приведены по открытым материалам на сентябрь 2026 года. Вопросы лицензирования решайте с вашим партнером 1С.