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

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

Главное правило: восстановление всегда выполняется в копию, а не поверх рабочей базы. Если что-то пойдёт не так, у вас останется исходная база и возможность повторить попытку. Перед началом убедитесь, что у вас есть права администратора, свободное место на диске (не менее 2–3 объёмов файла бэкапа) и сам файл резервной копии открывается без ошибок.

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

Определите тип бэкапа и формат базы

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

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

Для файловой базы резервной копией может быть и просто скопированный файл 1Cv8.1CD из каталога базы. Это допустимый способ, но только если на момент копирования с базой никто не работал — иначе файл может оказаться в несогласованном состоянии.

Подготовка перед восстановлением

Завершите все сеансы пользователей в целевой базе: восстановление подразумевает монопольный доступ. В файловом варианте достаточно попросить пользователей выйти, в клиент-серверном — заблокируйте регламентные задания и соединения через консоль кластера.

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

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

Восстановление файловой базы из файла .dt

Это самый распространённый сценарий для небольших организаций. Порядок действий одинаков для большинства типовых конфигураций.

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

Если бэкап представляет собой не .dt, а скопированный файл 1Cv8.1CD, восстановление ещё проще: создайте пустой каталог, поместите туда файл 1Cv8.1CD и добавьте этот каталог в список информационных баз через кнопку «Добавить» в окне запуска.

После загрузки .dt список пользователей восстанавливается вместе с базой. Если вы не помните пароли — войдите в конфигуратор (он не требует пароля, если в выгрузке не установлен пароль администратора) и задайте новые пароли в разделе «Администрирование → Пользователи».

Восстановление клиент-серверной базы из бэкапа СУБД

Для баз на MS SQL Server или PostgreSQL штатный способ резервного копирования — средства СУБД, а восстановление выполняется в два этапа: сначала база данных в СУБД, затем её регистрация в кластере 1С.

Восстановление в MS SQL Server

Откройте SQL Server Management Studio, подключитесь к серверу и восстановите бэкап в новую базу данных: правый клик по «Базы данных» → «Восстановить базу данных» → источник «Устройство» → укажите файл .bak. В поле «База данных назначения» введите новое имя — не перезаписывайте существующую базу. На вкладке «Параметры» при необходимости скорректируйте пути к файлам данных и журнала.

Восстановление в PostgreSQL

Для дампа, созданного через pg_dump, сначала создайте пустую базу данных с владельцем, под которым работает сервер 1С, затем выполните восстановление командой:

psql -U postgres -d new_base_name -f /path/to/backup.sql

Для дампов в формате custom используется утилита pg_restore с аналогичными параметрами. Учтите, что PostgreSQL для 1С обычно развёрнут из специальной сборки — восстанавливать дамп нужно в экземпляр той же сборки.

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

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

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

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

Если отчёты показывают битые ссылки вида «Объект не найден», запустите «Тестирование и исправление» информационной базы в конфигураторе (меню «Администрирование») с включёнными проверками ссылочной целостности. Процедуру выполняйте в монопольном режиме и только после того, как сделана копия восстановленной базы.

Отдельно проверьте настройки, которые не хранятся в .dt или могут сбиться при переносе: пути к каталогам обмена, подключение к ЭДО, параметры почты, настройки резервного копирования самой базы.

Типичные ошибки при восстановлении

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

Когда восстановление лучше доверить специалисту

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

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

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