Как правильно восстановить базу 1С

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

Ключевое правило: любое восстановление начинается с создания копии текущего состояния базы, даже если она не открывается. Файл 1Cv8.1CD файловой базы или резервная копия SQL-базы — это последняя точка отката, и её нельзя терять. Только после этого можно применять штатные средства: загрузку из dt, восстановление из бэкапа СУБД или утилиту chdbfl.exe.

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

Как определить тип базы и характер повреждения

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

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

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

Первое действие — скопировать текущее состояние базы. Для файловой базы скопируйте весь каталог с файлом 1Cv8.1CD в отдельное место. Для клиент-серверной сделайте бэкап средствами СУБД, даже если база частично недоступна — штатные инструменты SQL-сервера часто позволяют снять копию с повреждённой базы.

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

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

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

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

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

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

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

Восстановление файловой базы из копии файла 1Cv8.1CD

Если резервное копирование выполнялось простым копированием каталога базы, восстановление сводится к обратному действию: закройте все сеансы, замените текущий файл 1Cv8.1CD файлом из копии и откройте базу. Путь к базе в списке информационных баз менять не нужно, если каталог остался тем же.

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

Если файл повреждён: утилита chdbfl.exe

Для физически повреждённых файловых баз в составе платформы поставляется утилита chdbfl.exe из каталога bin установленной платформы. Она проверяет физическую целостность файла 1Cv8.1CD и может исправлять ошибки структуры. Запускайте её только на копии файла: отметьте опцию исправления ошибок, дождитесь результата и затем попробуйте открыть базу.

После chdbfl.exe рекомендуется выполнить «Тестирование и исправление» в конфигураторе (меню «Администрирование») с проверкой логической и ссылочной целостности. Учтите: исправление может удалить записи, которые не удалось восстановить, поэтому сверка ключевых данных после процедуры обязательна.

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

В клиент-серверном варианте основной инструмент резервного копирования — штатные средства СУБД. Для MS SQL Server восстановление выполняется через SQL Server Management Studio: правый клик по узлу «Databases» → «Restore Database», выбор устройства с файлом bak и запуск восстановления. При восстановлении поверх существующей базы потребуется опция замены (WITH REPLACE) и отключение активных соединений.

Для PostgreSQL используется связка pg_dump/pg_restore: восстановление выполняется командой pg_restore с указанием целевой базы. Перед восстановлением базу обычно пересоздают пустой с тем же владельцем и параметрами, что требует 1С.

pg_restore -U postgres -d db_name --clean --if-exists /backup/db_backup.dump

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

Проверка базы после восстановления

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

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

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

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

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

Как организовать резервное копирование, чтобы восстановление было простым

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

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

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