Как перенести базу 1С на новый сервер без потери данных и простоев
Перенос базы 1С на новый сервер — задача, где цена ошибки выше стоимости железа: одна потерянная транзакция за день вызовет хвост проблем на квартал. Подходов к миграции три, и они отличаются по времени, риску и сложности.
Перенос базы 1С 8.3 через DT-файл подходит для маленьких баз и плановой замены, прямое копирование на уровне СУБД — для типичных переездов с минимальным простоем в часах, а репликация — для тех, кому нужно уложиться в 5–15 минут окна обслуживания. Дальше разберем, когда какой способ применять, как делать перенос базы 1с сервер за сервер с минимальным простоем и что обязательно проверить после переключения.
Когда нужен перенос базы 1С на новый сервер
Самая частая причина — устаревшее железо. БД, которую пять лет назад заводили под десять пользователей, дорастает до сорока, и старое железо перестает справляться. Платить за «новый сервер» в этом сценарии дешевле, чем оптимизировать запросы и переписывать кэширование на старом.
Вторая причина — импортозамещение и переход на отечественные движки: Postgres Pro, Astra Linux, российское железо вместо санкционно проблемных моделей. Под такие проекты сразу планируют импортозамещение серверов и пересборку инфраструктуры на одно окно.
Третья причина — консолидация. Когда в группе компаний накопилось пять отдельных баз 1С на пяти разных серверах, собрать их в один кластер на одной мощной машине: проще обслуживать, дешевле резервировать, лицензии используются эффективнее. Перенос баз данных 1С при консолидации делают поочередно — в несколько итераций с отдельным согласованным окном обслуживания на каждую базу.
Подготовка к переносу: что сделать до старта
Любая успешная миграция начинается не с команды на копирование, а с аудита. Нужно знать точный размер информационной БД (вместе с журналом регистрации), список регламентных заданий и обменов с другими системами, объем кастомных доработок и список интеграций по COM-соединениям. Это критичный шаг: чем больше неучтенных интеграций всплывет уже после переключения, тем длиннее будет хвост откатов.
Полный бэкап и тестовое восстановление
Перед стартом обязательно делается полный бэкап — свежий, за минуты до старта. Бэкап без тестового восстановления — это вера, а не страховка. Поэтому отдельный шаг — поднять восстановленную копию на тестовом стенде. Если в чек-лист бэкапов входят инкременты, проверяется и накат инкрементов поверх полной копии.
Целевая машина готовится заранее: платформа 1С 8.3.20+ (понижать нельзя), нужная СУБД, сетевые роли, мониторинг. Под рабочую нагрузку сразу взять сервер для 1С с запасом по памяти и процессору на пару лет вперед. Параллельно с подготовкой железа согласовывается окно обслуживания — это формальный шаг, но без него любой инцидент превращается в скандал: пользователи должны быть в курсе, когда система будет недоступна и сколько это продлится.
Способ 1: выгрузка-загрузка через DT-файл
DT-файл — это «чемодан с вещами»: удобно перевезти БД любого вида (файловую, клиент-серверную, на разных СУБД), но для тяжелого багажа этот чемодан становится неподъемным. Метод оправдан для баз до 50 ГБ и в сценариях, где допустим простой в 4–24 часа. На больших базах DT-файл часто упирается в тайм-аут реструктуризации или не загружается из-за ограничений старых платформ.
Процедура простая. На исходной машине в конфигураторе делается выгрузка через «Администрирование → Выгрузить информационную базу». Архив сжимается в 3–10 раз. Файл переносится на целевую машину, где создается пустая информационная база с теми же параметрами, и в нее идет загрузка через тот же пункт меню. После платформа запускает реструктуризацию таблиц — самый долгий этап. Метод подойдет, если нужен «перенос базы 1С в другую базу» с одновременной сменой типа СУБД, например с MS SQL на PostgreSQL.
Способ 2: прямое копирование базы данных СУБД (перенос базы 1с sql)
Для БД от 50 ГБ и для сценариев, где нужен относительно короткий простой (от 30 минут до 2 часов), правильный метод — прямое копирование на уровне базы данных, без участия платформы 1С. В MS SQL Server это команды BACKUP DATABASE на исходной машине и RESTORE на целевом: при работе на NVMe типовая миграция базы на 100 ГБ занимает 30–90 минут. В PostgreSQL похожую задачу делает связка pg_dump -Fc на источнике и pg_restore на целевом узле; здесь те же 100 ГБ — это 1–3 часа в зависимости от компрессии и числа процессорных ядер.
Преимущество: данные переносятся точно, без зависимости от особенностей платформы и тайм-аутов конфигуратора. После завершения копирования БД подключается к кластеру 1С через консоль администрирования: указывается новый адрес сервера баз данных, параметры подключения, имя информационной БД — и все, пользователи могут начинать работу. Этот же метод используют, когда «перенос базы 1С на другой компьютер» означает переезд на ту же СУБД, но на свежее железо: данные едут как есть, никакая реструктуризация не нужна.
Способ 3: минимальный простой через репликацию
Если бизнес не может позволить себе простой даже в час, единственный подходящий метод — настроенная заранее репликация между старым и новым узлом СУБД. Для MS SQL это AlwaysOn Availability Groups в Enterprise-редакции, для PostgreSQL и Postgres Pro — потоковая репликация с Patroni и кворумом etcd.
Идея простая: пока на старой машине идет работа, на новом параллельно поддерживается актуальная копия БД. В момент переключения остается только остановить запись, дождаться финального sync (1–10 минут) и переключить клиентов на новый сервер.
Окно обслуживания и финальное переключение
При репликационном переключении окно обслуживания сокращается до 5–15 минут — за это время делается финальный sync, проверяются контрольные суммы и кластер 1С перенаправляется на новую СУБД. Под такую схему сразу планируют отказоустойчивый сервер, чтобы и после миграции остаться с правильной архитектурой высокой доступности.
Метод сложный в настройке и требует Enterprise-лицензий MS SQL или грамотно собранного кластера PostgreSQL, поэтому оправдан только там, где простой дорогой: розница в пиковые часы, банковский фронт, кассы с непрерывным обслуживанием.
Проверка после переноса: что протестировать обязательно
После миграции нельзя сразу пускать пользователей — сначала нужна проверка. Считается контрольная сумма БД (это умеет консоль администрирования 1С), число документов, число записей в основных регистрах накопления и сведений.
Для файловой базы целостность отдельно проверяется утилитой chdbfl.exe — это самостоятельное приложение из папки bin платформы 1С (например, C:\Program Files\1cv8\8.3.x\bin\chdbfl.exe), запускается напрямую, а не через конфигуратор. Не путайте ее с режимом «Тестирование и исправление» в конфигураторе: ТиИ работает с уже загруженной базой и решает другие задачи (пересчет итогов, реиндексация), а chdbfl.exe проверяет физическую целостность файла 1Cv8.1CD.
Если хотя бы один счетчик не сошелся — переключение откатывается, причина ищется на исходной базе, миграция повторяется. Это и есть то самое тестирование, которое часто пропускают в спешке и потом неделю расследуют, куда делись «пять тысяч проведенных документов за прошлый понедельник».
Дальше идут тестовые операции: пробное проведение типового документа (приход, расход, акт сверки), формирование основных отчетов (оборотно-сальдовая, движения по счету), запуск регламентных заданий вручную, проверка обменов с внешними системами. На этой стадии часто всплывают мелкие проблемы: COM-соединения смотрят на старый адрес, пути к внешним файлам поменялись, в обменах захардкожены имена узлов.
Если что-то критичное не работает — выполняется откат на исходную БД (она остается включенной, но без записи) и расследование причин. Плановое окно обслуживания согласуется с бизнесом заранее; фактическое время переключения для типовой миграции — 2–4 часа с учетом проверок и контрольных сумм. Сутки в качестве RTO имеет смысл закладывать только под крупные базы от 1 ТБ или сложные сценарии с одновременной сменой СУБД.
Сравнительная таблица: три способа переноса базы 1С
Чтобы было проще выбрать метод под свой объем и допустимый простой, параметры собрали в таблице.
Из таблицы видна логика. До 50 ГБ и для плановых окон — DT-выгрузка. Для рабочих БД от 50 ГБ до пары терабайт с окном 1–2 часа — копирование на уровне СУБД. Для критичных систем — репликация с подготовленным кластером.
Заключение
Перенос базы 1С на новый сервер — управляемая задача. DT-выгрузка для маленьких ИБ и смены движка, копирование на уровне СУБД для типовых случаев, репликация для критичных систем. Чек-лист: аудит, бэкап с тестом, подготовка целевого узла, окно обслуживания, контрольные суммы и план отката. Следующий шаг — собрать чек-лист и под него выбирать метод.
Часто задаваемые вопросы о переносе базы 1С на новый сервер
Сколько времени занимает перенос базы 1С?
Зависит от метода и размера БД. DT-выгрузка для 50 ГБ — 4–8 часов, для 100 ГБ — 12–24. Прямое копирование 100 ГБ — 30–90 минут на MS SQL и 1–3 часа на PostgreSQL. Репликационное переключение — 5–15 минут на финальный sync.
Можно ли перенести базу без остановки работы пользователей?
Полностью без остановки — нет, финальное переключение требует короткой паузы. Но через репликацию пауза сокращается до 5–15 минут, и большинство пользователей ее не замечают.
Можно ли при переносе сменить СУБД (например, MS SQL на PostgreSQL)?
Можно, но только через DT-выгрузку. Прямое копирование между разными типами СУБД не работает — формат файлов несовместим. В большинстве проектов импортозамещения именно так и поступают: выгружают DT с MS SQL и загружают на свежий PostgreSQL.
Что делать с лицензиями 1С при смене сервера?
Программная лицензия привязана к hardware ID и потребует повторной активации на новом узле. Аппаратный ключ HASP физически переносится со старой машины на новую. Клиентские лицензии при смене узла сохраняют свою привязку и переактивации не требуют. До запуска проекта провести аудит ИТ-инфраструктуры, чтобы зафиксировать список текущих лицензий и план их миграции.
