Короткий ответ

Перенос Accounting — это не «скопировать MDF». Для SQL: backup/restore (или detach/attach по процедуре) с WITH MOVE, создание login и ALTER USER ... WITH LOGIN, прав db_owner на базе без sysadmin, правка строки СУБД в кластере. Для кластера 8.3: тот же релиз платформы, перенос/активация лицензий на новый SRV-1C, порты, список баз. Файловую копируйте только консистентно. Пользователей пускайте, когда смоук пройден на новом контуре, DNS/ярлыки смотрят туда.

Симптомы и как отличить

Типичные провалы переноса:

  • 1С открывается, «лицензия не обнаружена»;
  • 18456, orphaned 1c_accounting;
  • клиенты на старый SRV-1C;
  • restore 3156.

Это не обновление конфигурации — хотя копию перед переносом делайте так же, как к обновлению.

Возможные причины поломки при переезде

  1. Забыли лицензии HASP/программные.
  2. SID login не совпал.
  3. Пути дисков другие.
  4. Другая сборка 8.3.
  5. Два кластера на одну SQL-базу на время «плавного» перехода.
  6. Firewall 1433/1540 на новой VLAN.

Диагностика исходного контура

Зафиксируйте:

  • сборка 8.3, порт агента, путь srvinfo;
  • SQL: @@VERSION, пути файлов Accounting, recovery, login 1С;
  • HASP где, nethasp, файлы программных лицензий (не копировать вслепую);
  • строка инфобазы: Srvr, Ref, сервер СУБД SQL01, имя БД.
SELECT name, physical_name FROM sys.master_files WHERE database_id = DB_ID(N'Accounting');
SELECT name FROM sys.server_principals WHERE name LIKE N'%1c%';

Сеть до нового хоста: 1540/1541, 1433.

Решение

Сценарий A. SQL на новый SQL01, кластер тот же SRV-1C

  1. Full backup (+ log), цепочка.
  2. Restore на новый экземпляр с MOVE, не поверх прод.
  3. Создать login, сопоставить user (права).
  4. В свойствах инфобазы 1С — новый сервер СУБД. Окно: сеансы off, финальный log, restore хвоста, переключение.
  5. Старый SQL — не сносить, пока день не прожит.
ALTER USER [1c_accounting] WITH LOGIN = [1c_accounting];

Сценарий B. Новый кластер SRV-1C

Поставьте ту же 8.3, зарегистрируйте инфобазу на уже перенесённый SQL (или наоборот, документируйте порядок). Перенесите лицензии штатно: ключ USB / активация программных на новом железе, nethasp на новое имя. Проверьте лицензию до массового пуска.

Обновите ibases.v8i / DNS SRV-1C. Не держите два живых кластера с одной Accounting.

Сценарий C. Файловая → SQL

Выгрузка/загрузка или штатный «конвертировать в клиент-сервер» по документации 8.3 на копии. Пользователи off. После — SQL backup сразу. Лицензии сервера 1С и SQL-доступ.

Сценарий D. Detach/attach

Только после копии, служба не пишет, файлы согласованы. На целевом — права службы SQL на новые пути. Ошибка 5120 — ACL. Предпочтительнее backup/restore: меньше сюрпризов с путями.

Сценарий E. Смена имени базы

Ref в кластере и имя SQL могут различаться. Обновите оба сознательно. Ярлыки пользователей.

Контур cutover: DNS, лицензии, два кластера

Переключение лучше в DNS: SRV-1C / SQL01 как CNAME/A на новые IP после смоука, с коротким TTL заранее. Ярлыки с IP придётся бегать по ПК.

Лицензии: USB-ключ переезжает физически в окно; программные — активация на новом железе до пуска всех, иначе утро без входа. Не оставляйте ключ в старом корпусе «на всякий случай параллельно» — часть клиентов найдёт старый HASP, часть новый, счётчики поедут. Один сервер лицензий.

SQL logins: скрипт CREATE LOGIN ... WITH SID = 0x... (тот же SID, что на источнике) упрощает user mapping. Либо SID-копия, либо ALTER USER. Проверьте агентские jobs, если они смотрят в Accounting.

Пока старый SRV-1C жив, снимите с него инфобазу или службу агента после cutover, чтобы никто не писал в «почти тот же» SQL. Два кластера — самый дорогой способ порчи регистров.

Файлы web default.vrd: новый srvr. Сертификат HTTPS на новое имя.

Смоук: вход, проведение, печать, загрузка банка на тестовом контуре обмена, backup job. Только потом объявляйте склад.

Откат переноса: вернуть DNS/строки на старый контур, который вы не сносили в первую ночь. Снос источника через сутки-двое, когда есть успешный backup на новом месте и день работы без сюрпризов.

Как проверить, что проблема устранена

  • Вход 1С под обычной учёткой, проведение, журнал.
  • sqlcmd с нового SRV-1C на новый SQL01.
  • Лицензии: несколько одновременных сеансов.
  • Backup job на новом SQL зелёный.
  • DNS/список баз не указывает на выключенный хост.
  • Старый контур выключен или infobase запрещена, не пишет.

Если не помогло

  • Только лицензия — ключ/пин, не повторный restore.
  • Только 18456 — SID/пароль.
  • Медленно после переноса — диск/память нового хоста, замер.
  • Веб-публикация — переиздать default.vrd на новый srv.

Профилактика

  • Имена DNS, не IP в строках.
  • Документ SID/login, портов, лицензий.
  • Тренировочный перенос на копии раз в год.
  • Не хранить единственный ключ в старом сервере, который вывозят.

Cutover-чеклист: backup источника, restore/MOVE на цель, login+SID, права без sysadmin, платформа 8.3 совпадает, лицензии активированы на новом SRV-1C, порты 1540/1433 с клиентов и между ролями, DNS TTL уменьшен заранее, ibases.v8i и публикация смотрят на новое имя, обмен на копии выключен, смоук, backup job на новом SQL, старый кластер не пишет. Два дня старый контур выключен, но не уничтожен. Не копируйте живой MDF. Не клонируйте VM с программной лицензией как способ переноса ключа. Не оставляйте тестовую копию с прод-паролями в той же сети, что банк-клиент.

FAQ

Можно ли перенести только MDF без log?

Нет как штатный метод. Нужен LDF или salvage с потерей — это авария, не миграция.

Версия SQL 2019 → 2022.

Restore вверх обычно ок. План совместимости, тест 1С. Обратно — нет.

Кластер 1С переехать без SQL.

Да: новая регистрация инфобазы на ту же БД, лицензии, cutover сеансов. Не два агента.

Нужно ли переносить журнал регистрации 1С?

Отдельные файлы/таблица — по вашей настройке. Для SQL часто в базе; уйдёт вместе с restore. Для файлового журнала на диске кластера — скопируйте, если нужен.

Пользователи в кэше старого сервера.

Новый кэш на клиентах нормален. Список баз обновить обязательно, иначе «перенесли, а все на старом».