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

Копия серверной базы 1С нужна в трёх типовых ситуациях: перед обновлением конфигурации, для создания тестовой среды и как резервная копия на случай сбоя. В отличие от файловой базы, которую можно скопировать одним файлом, серверная база хранится в СУБД (MS SQL Server, PostgreSQL, Oracle), а связь с ней описана в кластере серверов 1С — поэтому простое копирование файлов данных недостаточно и часто опасно.

Существует три рабочих способа: выгрузка в файл .dt через конфигуратор, резервная копия средствами самой СУБД и комбинированный вариант, когда дамп SQL разворачивается под новым именем для тестовой базы. У каждого способа свои ограничения по объёму, скорости и полноте данных.

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

Что нужно подготовить перед копированием

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

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

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

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

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

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

Ограничения способа: на базах десятков гигабайт выгрузка может занимать часы, а загрузка — ещё дольше. Файл .dt не подходит для ежедневного регламентного резервного копирования больших баз. Также при выгрузке теряются некоторые настройки, хранящиеся вне базы (например, параметры кластера).

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

Способ 2: резервная копия средствами СУБД

Для серверных баз основной и рекомендуемый способ копирования — штатный backup в СУБД. Он выполняется быстро, не требует монопольного доступа (копия согласована на момент времени) и подходит для автоматизации по расписанию.

MS SQL Server

В SQL Server Management Studio найдите базу, щёлкните правой кнопкой → «Tasks» → «Back Up», выберите тип Full и путь к файлу .bak. Альтернатива — команда T-SQL:

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

Опция COMPRESSION уменьшает размер файла, CHECKSUM позволяет проверить целостность копии. Убедитесь, что модель восстановления базы и ваша стратегия копий согласованы: при модели Full без регулярного копирования журнала транзакций файл журнала будет расти и может занять весь диск.

PostgreSQL

Для PostgreSQL используется утилита pg_dump. Выполняйте её от имени пользователя с правами на базу:

pg_dump -U postgres -Fc -f /backup/mybase1c.dump mybase1c

Формат -Fc (custom) сжимает данные и позволяет восстанавливать выборочно через pg_restore. Для восстановления в новую базу сначала создайте пустую базу с тем же владельцем, затем выполните pg_restore.

Создание тестовой копии базы

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

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

Проверка результата

Сам факт создания файла копии не гарантирует, что копия рабочая. Для .dt минимальная проверка — тестовая загрузка в пустую файловую или серверную базу и запуск конфигуратора без ошибок. Для SQL-копий полезно периодически выполнять контрольное восстановление на отдельную базу: только так можно убедиться, что бэкап реально разворачивается.

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

Типичные ошибки и ограничения

Самая частая ошибка — восстановление дампа поверх рабочей базы из-за невнимательного выбора целевой базы в SSMS или pg_restore. Вторая по распространённости — создание тестовой копии без отключения фоновых заданий, после чего из копии уходят реальные письма и обмены. Третья — хранение копий на том же диске и даже на том же сервере, где лежит сама база: при отказе диска теряется и база, и копия.

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

Часто задаваемые вопросы