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

Работающая на сервере база 1С требует регулярного резервного копирования, и способ копирования зависит от того, где физически хранятся данные. В клиент-серверном варианте информация находится в СУБД — чаще всего это MS SQL Server или PostgreSQL, а кластер 1С:Предприятия лишь обеспечивает доступ к ней. Поэтому «сделать копию базы на сервере» можно двумя принципиально разными путями: выгрузить данные в файл .dt через конфигуратор или создать резервную копию средствами самой СУБД.

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

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

Как понять, где хранится база и какой способ копирования выбрать

Сначала определите режим работы базы. Откройте конфигуратор или список баз в стартовом окне 1С и посмотрите строку подключения. Если указан сервер 1С:Предприятия и имя базы в кластере — это клиент-серверный вариант. Если указан путь к каталогу на диске — файловый вариант, и тогда копия делается простым копированием файла 1Cv8.1CD.

Для серверной базы уточните, какая СУБД используется. Это видно в свойствах информационной базы в консоли кластера 1С: там указан сервер баз данных, имя базы и тип СУБД. От этого зависит инструмент копирования: SQL Server Management Studio для MS SQL, pgAdmin или утилита pg_dump для PostgreSQL.

Копия через конфигуратор: выгрузка в файл .dt

Это самый доступный способ, не требующий прав на сервере СУБД. Запустите конфигуратор от имени пользователя с правами администратора базы и завершите работу всех пользователей: выгрузка требует монопольного доступа. Активные сеансы можно завершить через консоль кластера или попросить пользователей выйти.

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

1. 1
   Завершите сеансы пользователей и фоновые задания через консоль кластера
2. 2
   Откройте базу в конфигураторе с правами администратора
3. 3
   Выберите «Администрирование» — «Выгрузить информационную базу»
4. 4
   Укажите путь и имя файла .dt, дождитесь завершения
5. 5
   Проверьте размер файла и сохраните его в надёжное хранилище

Чтобы развернуть копию, создайте новую пустую базу в кластере, откройте её в конфигураторе и выполните «Администрирование» — «Загрузить информационную базу». После загрузки платформа предложит перезапустить конфигуратор. Этот же файл .dt подходит для переноса базы на другой сервер или даже в другую СУБД.

Резервная копия средствами MS SQL Server

Если база работает на MS SQL, штатный способ копирования — команда BACKUP DATABASE или графический интерфейс SQL Server Management Studio. Подключитесь к серверу СУБД, найдите нужную базу, щёлкните правой кнопкой и выберите «Задачи» — «Создать резервную копию». Укажите тип «Полная» и путь к файлу .bak.

Тот же результат даёт команда T-SQL, которую удобно включать в план обслуживания или запускать по расписанию через агент SQL Server:

BACKUP DATABASE [MyBase1C]
TO DISK = N'D:\Backups\MyBase1C_full.bak'
WITH FORMAT, COMPRESSION;

Для восстановления используется команда RESTORE DATABASE или соответствующий пункт меню в SSMS. Важно: восстановление поверх рабочей базы уничтожит текущие данные, поэтому для тестовой копии восстанавливайте бэкап под новым именем базы, а затем зарегистрируйте её в кластере 1С как отдельную информационную базу.

Резервная копия средствами PostgreSQL

Для баз на PostgreSQL стандартный инструмент — утилита pg_dump. Она создаёт логическую копию базы в виде SQL-скрипта или архива и может выполняться без остановки работы пользователей, поскольку делает согласованный снимок данных.

pg_dump -U postgres -F c -f /backups/mybase1c.dump mybase1c

Формат -F c (custom) поддерживает сжатие и выборочное восстановление через pg_restore. Для восстановления создайте пустую базу и выполните pg_restore с указанием файла копии. Убедитесь, что версия PostgreSQL при восстановлении не ниже версии, на которой создавалась копия, иначе возможны ошибки совместимости.

Альтернатива — физическое копирование каталога данных PostgreSQL, но оно требует остановки службы СУБД и применимо только для полного клонирования сервера. Для повседневных задач pg_dump удобнее и безопаснее.

Как создать тестовую копию базы на том же сервере

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

Порядок такой: сделайте бэкап рабочей базы средствами СУБД, восстановите его под новым именем (например, MyBase1C_test), затем в консоли кластера создайте новую информационную базу, указав эту копию. Либо используйте пару «выгрузка .dt — загрузка .dt» в новую пустую базу.

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

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

Созданная копия не гарантирует работоспособность, пока вы её не проверили. Минимальная проверка — открыть копию в режиме предприятия, убедиться, что справочники и документы на месте, сформировать типовой отчёт (например, оборотно-сальдовую ведомость) и сверить итоги с рабочей базой на дату копирования.

Отдельная ошибка — путать копию базы СУБД с резервной копией кластера 1С. Кластер хранит только список баз и настройки, сами данные находятся в СУБД. Поэтому бэкапить нужно именно базы данных, а не каталог srvinfo.

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

Разовая копия не заменяет регулярный бэкап. Для MS SQL настройте план обслуживания или задание агента SQL Server с ежедневным полным бэкапом и, при необходимости, копиями журнала транзакций. Для PostgreSQL используйте планировщик cron с вызовом pg_dump или специализированные инструменты вроде pgBackRest.

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

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