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

Потребность скопировать базу 1С с сервера возникает при переезде на новое оборудование, создании резервной копии перед обновлением, развёртывании тестовой среды или передаче данных разработчику. Способ копирования зависит от того, как развёрнута база: в файловом варианте на сетевом ресурсе или в клиент-серверном на MS SQL Server, PostgreSQL, Oracle.

Главный принцип — копия должна быть консистентной: в момент создания в базе не должно быть активных транзакций, иначе копия может оказаться повреждённой или содержать «обрезанные» документы. Поэтому перед копированием пользователей либо выгоняют из базы, либо используют методы, корректно работающие с «горячими» данными.

Ниже разобраны все рабочие варианты: от простейшего копирования файла до бэкапа СУБД, а также проверка результата и типичные ошибки, из-за которых копия оказывается непригодной.

Определяем, как развёрнута база: файловая или клиент-серверная

Прежде чем копировать, нужно понять тип базы. Откройте список информационных баз в окне запуска 1С, выделите нужную базу и нажмите «Изменить». В параметрах будет указан либо путь к каталогу (например, \\SERVER\Base\Trade) — это файловая база, либо имя сервера 1С и имя базы в кластере — это клиент-серверный вариант.

Также тип базы виден в конфигураторе: меню «Администрирование» → «Параметры информационной базы» покажет строку подключения. Для файловой базы она начинается с File=, для серверной — с Srvr= и Ref=.

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

Способ 1. Выгрузка базы в файл .dt через конфигуратор

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

Порядок действий: запустите конфигуратор под пользователем с полными правами, завершите работу всех пользователей (Администрирование → Поддержка и обслуживание → Блокировка работы пользователей), затем откройте «Администрирование» → «Выгрузить информационную базу» и укажите путь к файлу .dt. Для больших баз процесс занимает от десятков минут до нескольких часов.

Загрузка копии на новом месте выполняется зеркально: создаётся пустая база, в конфигураторе выбирается «Загрузить информационную базу» и указывается файл .dt. После загрузки база полностью идентична исходной на момент выгрузки.

1. 1
   Завершите сеансы пользователей и установите блокировку работы
2. 2
   Откройте конфигуратор с полными правами
3. 3
   Администрирование → Выгрузить информационную базу → укажите файл .dt
4. 4
   Дождитесь завершения и проверьте размер файла
5. 5
   На новом сервере создайте пустую базу и выполните «Загрузить информационную базу»

Способ 2. Копирование файловой базы

Если база файловая и лежит на сервере в общей папке, достаточно скопировать весь каталог базы. Ключевой файл — 1Cv8.1CD, в нём хранятся все данные. Рядом могут быть служебные файлы и папки (например, с журналом регистрации), их тоже стоит забрать.

Обязательное условие — в момент копирования никто не должен работать с базой. Файл 1Cv8.1CD, скопированный при открытых сеансах, почти гарантированно окажется повреждённым: 1С держит часть данных в памяти и сбрасывает их на диск не мгновенно. Признак «горячего» копирования — наличие рядом файла блокировок 1Cv8.1CL.

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

# Копирование файловой базы (после завершения всех сеансов)
Copy-Item "\\SERVER\Bases\Trade" "D:\Backup\Trade_$(Get-Date -Format yyyy-MM-dd)" -Recurse

Способ 3. Копирование серверной базы средствами СУБД

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

MS SQL Server

Откройте SQL Server Management Studio, найдите базу, щелчок правой кнопкой → Tasks → Back Up. Тип — Full, укажите файл назначения .bak. Для восстановления на другом сервере используется Tasks → Restore → Database с указанием файла .bak. После восстановления базу нужно зарегистрировать в кластере 1С через консоль администрирования серверов 1С.

PostgreSQL

Используется утилита pg_dump с правами владельца базы. Восстановление выполняется через pg_restore либо psql в зависимости от формата дампа. Важно: в 1С для PostgreSQL применяются специальные сборки (например, от Postgres Professional), и дамп желательно восстанавливать в ту же версию СУБД.

# Дамп базы PostgreSQL
pg_dump -U postgres -Fc -f /backup/trade_base.dump trade_base

# Восстановление на новом сервере
pg_restore -U postgres -d trade_base_copy /backup/trade_base.dump

Учтите ограничение: бэкап СУБД привязан к конкретной СУБД и её версии. Перенести базу с MS SQL на PostgreSQL через бэкап нельзя — для миграции между СУБД используется только выгрузка .dt.

Регистрация копии на сервере 1С и настройка доступа

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

Для тестовой копии обязательно дайте базе отличное имя (например, Trade_Test) и предупредите пользователей. Работа в копии, которую все считают рабочей базой, — частая причина потери данных: документы вводятся не туда, а потом обнаружить расхождение сложно.

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

Проверка результата и типичные ошибки

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

Дополнительно полезно выполнить «Тестирование и исправление» информационной базы (в конфигураторе, в режиме только проверки) — особенно для файловых копий, сделанных при возможной активности пользователей.

Регулярное копирование и автоматизация

Разовая копия решает задачу переезда, но для защиты данных нужен регулярный бэкап. Для серверных баз настройте план обслуживания в SQL Server (Maintenance Plan) или задание планировщика с pg_dump для PostgreSQL. Храните копии на отдельном носителе или другом сервере — бэкап на том же диске, что и база, не защищает от отказа оборудования.

Для файловых баз настройте ночное копирование каталога скриптом с предварительной проверкой отсутствия активных сеансов. Периодически делайте контрольное восстановление: бэкап, который ни разу не проверяли восстановлением, нельзя считать надёжным.

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