Как восстановить копию базы 1С SQL

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

Принципиально важно понимать разницу между двумя форматами копий. Файл .dt — это выгрузка средствами конфигуратора, независимая от СУБД, но медленная на больших базах. SQL-бэкап (.bak в MS SQL или дамп pg_dump) — копия на уровне СУБД: восстанавливается быстро, но требует правильной привязки к серверу 1С после восстановления. В этой статье речь идёт именно о втором сценарии.

Перед началом работ убедитесь, что у вас есть: сам файл резервной копии, доступ к SQL Server с правами на создание и восстановление баз, доступ к консоли администрирования сервера 1С и окно времени, когда пользователи не работают с базой (для продуктивного восстановления). Для тестовой копии достаточно отдельного сервера или отдельного имени базы.

Подготовка: что проверить до восстановления

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

Второе — свободное место на диске. Восстановленная база займёт примерно столько же места, сколько занимала исходная, плюс потребуется место под журнал транзакций. Если бэкап сжатый, ориентируйтесь не на размер файла .bak, а на размер исходной базы. Недостаток места на этапе RESTORE — одна из самых частых причин сбоя.

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

Восстановление бэкапа в Microsoft SQL Server

Самый наглядный способ — графический интерфейс SQL Server Management Studio (SSMS). Подключитесь к серверу, щёлкните правой кнопкой по узлу «Базы данных», выберите «Восстановить базу данных». В качестве источника укажите «Устройство» и путь к файлу .bak. Если восстанавливаете под новым именем, впишите его в поле «Целевой объект — База данных».

На вкладке «Файлы» проверьте пути к файлам данных и журнала: по умолчанию SSMS подставляет пути, сохранённые в бэкапе, и они могут не существовать на целевом сервере. На вкладке «Параметры» при восстановлении поверх существующей базы включите флаг «Перезаписать существующую базу данных (WITH REPLACE)». Для базы, с которой работают пользователи, это действие необратимо — старые данные будут потеряны.

Быстрее и надёжнее для повторяющихся операций — скрипт T-SQL. Сначала узнайте логические имена файлов командой RESTORE FILELISTONLY, затем выполните RESTORE с параметрами MOVE:

RESTORE FILELISTONLY FROM DISK = N'D:\Backups\base_copy.bak';

RESTORE DATABASE [Trade_Test] FROM DISK = N'D:\Backups\base_copy.bak'
WITH MOVE N'Trade_Data' TO N'D:\SQLData\Trade_Test.mdf',
MOVE N'Trade_Log' TO N'D:\SQLData\Trade_Test.ldf',
REPLACE, RECOVERY;

Параметр RECOVERY переводит базу в рабочее состояние сразу после восстановления — для копии это то, что нужно. Вариант NORECOVERY оставляет базу в состоянии «восстанавливается» и применяется только при накатывании дополнительных журналов. Если после восстановления база осталась в статусе Restoring, выполните RESTORE DATABASE [имя] WITH RECOVERY.

Восстановление дампа PostgreSQL

Для баз 1С на PostgreSQL процедура отличается. Сначала создайте пустую базу данных с владельцем, под которым работает сервер 1С (обычно это пользователь, указанный при создании базы в кластере). Затем загрузите в неё дамп. Если дамп в текстовом формате (pg_dump без сжатия), используйте psql; если в каталоговом или custom-формате — pg_restore.

-- создание пустой базы
psql -U postgres -c "CREATE DATABASE trade_test OWNER usr1cv8;"

-- загрузка текстового дампа
psql -U postgres -d trade_test -f /backups/trade_dump.sql

-- либо загрузка custom-формата
pg_restore -U postgres -d trade_test /backups/trade_dump.dump

Учтите, что на Linux-сервере важны права на файлы и настройки доступа в pg_hba.conf: пользователь, от имени которого выполняется восстановление, должен иметь право подключения к серверу СУБД. Ошибки вида «permission denied» или «peer authentication failed» означают проблему с аутентификацией, а не с самим дампом.

Регистрация восстановленной базы в кластере 1С

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

Заполните параметры: имя базы в кластере (произвольное, понятное пользователям), тип СУБД, имя сервера баз данных, имя базы данных — точно такое, как вы указали при RESTORE, и учётные данные пользователя СУБД. После сохранения база появится в списке кластера.

Если база восстановлена как тестовая копия рабочей, после первого входа в конфигуратор или предприятие система выдаст предупреждение «Информационная база была перемещена или восстановлена из резервной копии». Для тестовой копии обязательно выберите вариант «Это копия информационной базы» — тогда 1С отключит выполнение регламентных заданий, синхронизацию данных и прочие механизмы, которые могли бы повторно отправить данные во внешние системы.

1. 1
   Проверьте версию СУБД и свободное место на целевом сервере
2. 2
   Восстановите бэкап средствами СУБД под новым именем базы
3. 3
   Убедитесь, что база в статусе Online (не Restoring, не Suspect)
4. 4
   Зарегистрируйте базу в консоли кластера 1С без флага создания новой БД
5. 5
   Войдите в базу и при вопросе о перемещении укажите «Это копия»
6. 6
   Проверьте открытие ключевых документов и отчётов

Проверка результата и контроль целостности

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

Для MS SQL полезно выполнить проверку целостности командой DBCC CHECKDB — на тестовой копии это безопасно и покажет физические и логические ошибки базы. На больших базах проверка занимает заметное время и нагружает диски, поэтому на продуктивном сервере её планируют на период минимальной нагрузки.

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

Контрольные точки

Как проверить результат

Статус базы в SSMS

Норма

Online, база доступна для запросов

Тревожный признак

Restoring, Suspect или Recovery Pending

Вход в 1С

Норма

База открывается, пользователи авторизуются

Тревожный признак

Ошибка «информационная база не обнаружена» — неверные параметры регистрации в кластере

Целостность данных

Норма

DBCC CHECKDB без ошибок, документы открываются

Тревожный признак

Ошибки целостности — бэкап или исходная база повреждены

Регламентные задания в копии

Норма

Заблокированы после выбора «Это копия»

Тревожный признак

Задания активны и могут отправить данные во внешние системы

Типичные ошибки и как их избежать

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

Отдельная группа ошибок — безопасность тестовых копий. Копия продуктивной базы содержит реальные данные контрагентов, сотрудников и проводки. Если оставить активными регламентные задания обмена, тестовая копия начнёт отправлять дубли документов в связанные системы. Всегда отвечайте «Это копия» при первом входе и проверяйте блокировку заданий в настройках.

Ограничения и альтернативные способы

SQL-бэкап не всегда оптимален. Если нужно перенести базу между разными СУБД (например, с MS SQL на PostgreSQL), единственный рабочий путь — выгрузка в .dt через конфигуратор и загрузка на новом месте. То же касается переноса между несовместимыми версиями SQL Server в сторону понижения.

Для регулярного создания тестовых копий имеет смысл автоматизировать процесс: скрипт RESTORE с MOVE плюс скрипт регистрации базы через rac/ras или вручную в консоли. Это сокращает рутину и снижает риск ошибки в параметрах. Для очень больших баз рассмотрите восстановление из снапшотов на уровне СХД, если инфраструктура это поддерживает, но такой способ требует согласования с администраторами виртуализации и хранения.

Способы восстановления копии

SQL-бэкап (.bak / pg_dump)

Быстро на больших базах, точная копия на момент бэкапа. Ограничение: та же СУБД и совместимая версия

Выгрузка .dt

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

Снапшот СХД/ВМ

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

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

Можно ли восстановить SQL-бэкап через конфигуратор 1С?

Нет. Конфигуратор работает только с файлами выгрузки .dt. Файл .bak восстанавливается исключительно средствами СУБД — через SSMS, T-SQL или аналогичные инструменты PostgreSQL, после чего база регистрируется в кластере 1С.

База восстановилась, но 1С пишет «информационная база не обнаружена». Что не так?

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

Как восстановить копию, не останавливая работу пользователей в рабочей базе?

Восстановите бэкап под новым именем базы на том же или другом сервере SQL — эта операция не затрагивает рабочую базу. Затем зарегистрируйте копию в кластере под отдельным именем. Пользователи рабочей базы ничего не заметят.

Что делать, если при восстановлении не хватает места на диске?

Освободите место, перенесите файлы данных на другой том через параметры MOVE в RESTORE или укажите другие пути в настройках файлов в SSMS. Узнать требуемый объём можно по размеру исходной базы, а не по размеру сжатого файла бэкапа.

Безопасно ли давать доступ к тестовой копии широкому кругу сотрудников?

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

Нужно ли после восстановления обновлять конфигурацию базы данных?

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