Восстановление базы данных 1С после сбоя или ошибки

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

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

С чего начать: определите вариант базы и характер сбоя

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

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

Клиент-серверная база хранится в СУБД (MS SQL Server или PostgreSQL), а в строке запуска указаны имя сервера 1С и имя информационной базы на сервере СУБД. Резервные копии такой базы делают средствами СУБД, а не просто копированием папки.

Теперь — что именно произошло. Это определяет метод:

• 🧱 Не открывается, ошибки «формат потока», «страница … не найдена в таблице», вылеты — похоже на физическое повреждение файла или таблиц. Нужна проверка и починка (chdbfl для файловой, средства СУБД — для серверной).
• 📉 База открывается, но данные неверны: задвоились документы, слетели остатки, кто-то провёл лишнее — это логическая проблема. Поможет восстановление из копии на момент ДО ошибки либо ручная правка.
• 💾 Пропал файл базы, сбой диска, случайно удалили — только восстановление из резервной копии.

Краткая карта методов — что к чему применяют:

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

Файл .dt — это полная выгрузка информационной базы (данные + конфигурация) в один архив. Самый надёжный способ вернуть файловую базу на момент создания копии.

Порядок загрузки:

1. Закройте все сеансы 1С:Предприятия, работающие с этой базой. Загрузка требует монопольного доступа — при открытых сеансах платформа выдаст ошибку.
2. Запустите базу в режиме Конфигуратор (в окне запуска выберите базу → кнопка Конфигуратор).
3. Меню Администрирование → Загрузить информационную базу….
4. Укажите файл .dt и подтвердите. Платформа предупредит, что текущие данные будут полностью заменены.
5. Дождитесь окончания. После загрузки Конфигуратор предложит перезапуститься — согласитесь.

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

Если базу нужно поднять «с нуля» из .dt (например, на другом компьютере): в окне запуска Добавить → Создание новой информационной базы → Создание информационной базы без конфигурации…, укажите пустой каталог, а затем в Конфигураторе загрузите в неё .dt.

Когда вместо .dt проще копия папки. В файловом варианте полноценная резервная копия — это и просто копия всего каталога базы (при закрытых сеансах). Чтобы восстановиться, подкладываете сохранённую папку на место текущей. Способ быстрый, но копировать 1Cv8.1CD на ходу, при работающих пользователях, нельзя — получите нерабочий файл.

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

Если база живёт в MS SQL Server или PostgreSQL, восстанавливать её нужно средствами самой СУБД — это быстрее и надёжнее .dt на больших объёмах.

MS SQL Server:

1. Через консоль администрирования серверов 1С завершите сеансы с базой или заблокируйте вход новых пользователей.
2. В SQL Server Management Studio правой кнопкой на базе → Restore Database… (или восстановление в новую базу из файла .bak).
3. Укажите файл резервной копии .bak и целевую базу. Для перезаписи существующей включите опцию перезаписи в параметрах восстановления.
4. После восстановления проверьте, что информационная база 1С по-прежнему указывает на эту базу СУБД.

PostgreSQL:

• Если копия делалась через pg_dump в дамп, восстанавливаете командой pg_restore (для формата custom) либо psql (для простого SQL-дампа) в заранее созданную пустую базу.
• Имена команд и ключи зависят от версии и формата дампа — сверяйтесь со штатной справкой pg_restore --help, конкретные параметры не выдумывайте.

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

Альтернатива — .dt и для серверной базы. Выгрузка/загрузка .dt работает и в клиент-серверном варианте (тот же пункт Конфигуратора). Но на базе в десятки гигабайт это долго и тяжело; бэкап средствами СУБД предпочтительнее. .dt для серверной базы удобен для переноса на другой сервер или в файловый вариант.

Разбор по журналу регистрации: что и когда сломалось

Журнал регистрации сам по себе ничего не откатывает — это лог событий. Но он незаменим, чтобы понять, ЧТО произошло и выбрать правильную точку восстановления.

Открывается журнал в режиме 1С:Предприятие: раздел настроек и администрирования, пункт Журнал регистрации. В Конфигураторе — меню Администрирование → Журнал регистрации.

Что он даёт при восстановлении:

• 🔎 Время сбоя или ошибочного действия. Отфильтруйте журнал по дате, пользователю, виду события (например, изменение данных, проведение). Увидите, когда именно внесли лишнее — и поймёте, копия на какой момент нужна.
• 👤 Кто и что менял. По конкретному документу видно, кто его провёл или удалил и когда. Это помогает решить, восстанавливать всю базу или исправить точечно.
• 🧭 Выбор стратегии. Если ошибка затронула один-два документа, часто дешевле поправить их вручную, чем откатывать всю базу из копии и терять свежую работу остальных.

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

Проверка и починка повреждённого файла: chdbfl и тестирование

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

Шаг 1. Утилита chdbfl.exe (только файловый вариант). Это штатная утилита платформы для проверки и исправления файла 1Cv8.1CD.

1. Закройте все сеансы с базой.
2. Сделайте копию файла 1Cv8.1CD — проверка с исправлением меняет файл.
3. Запустите chdbfl.exe из каталога bin установленной платформы (папка вида C:\Program Files\1cv8\<номер версии>\bin).
4. Укажите путь к файлу 1Cv8.1CD, включите флажок исправления обнаруженных ошибок, нажмите «Выполнить».

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

Шаг 2. Тестирование и исправление (Конфигуратор). Это проверка логической целостности: ссылочная целостность, пересчёт итогов, реиндексация таблиц.

1. Войдите в Конфигуратор (нужен монопольный доступ — сеансы закрыть).
2. Меню Администрирование → Тестирование и исправление….
3. Отметьте нужные проверки. По умолчанию подходят реиндексация, проверка логической целостности и пересчёт итогов.
4. Выберите режим: сначала безопаснее «только тестирование» — посмотреть отчёт, затем «тестирование и исправление».
5. Запустите и дождитесь завершения; на крупной базе это может занять часы.

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

Настройка регламентного резервного копирования

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

Файловая база, типовая конфигурация (БП 3.0, ЗУП 3.1 и др.). В самой программе есть встроенный механизм: Администрирование → Обслуживание → Резервное копирование и восстановление. Там задаётся расписание автоматического создания копий и хранится список, из которого можно восстановиться обратно.

Файловая база без встроенного механизма. Копируйте каталог базы по расписанию (скриптом или средствами ОС) при закрытых сеансах, либо выгружайте .dt регулярно.

Клиент-серверная база. Настраивается на стороне СУБД:

• MS SQL Server — план обслуживания (Maintenance Plan) с регулярным полным бэкапом и, при необходимости, резервным копированием журнала транзакций.
• PostgreSQL — регулярный pg_dump по расписанию (cron/планировщик) с выгрузкой в надёжное хранилище.

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

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