Восстановление базы 1С Бухгалтерия после сбоя

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

Восстановление базы 1С — это не одна кнопка, а лесенка от безопасного к радикальному. Сначала то, что ничего не ломает (копия, перезапуск, снятие блокировки), и только потом исправление структуры данных, которое меняет саму базу.

С чего начать: быстрая диагностика симптома

Прежде чем что-то «лечить», поймите, что именно сломалось. От этого зависит метод.

Соотнесите симптом с вероятной причиной и первым действием:

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

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

Проверка файла базы утилитой chdbfl

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

Порядок:

1. Убедитесь, что из базы вышли все пользователи, включая фоновые задания.
2. Сделайте копию файла 1Cv8.1CD в отдельную папку.
3. Запустите chdbfl.exe из каталога установки платформы — папка bin внутри каталога версии, например C:\Program Files\1cv8\8.3.XX.XXXX\bin\chdbfl.exe.
4. В поле «Имя файла БД» укажите путь к 1Cv8.1CD.
5. Поставьте флажок «Исправлять обнаруженные ошибки» и нажмите «Выполнить».

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

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

Тестирование и исправление информационной базы

Это основной штатный механизм лечения. Работает и для файловой, и для клиент-серверной базы.

1. Откройте базу в режиме Конфигуратор.
2. Меню Администрирование → Тестирование и исправление.
3. Отметьте нужные проверки и выберите режим действий.

Что означают галочки:

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

Не надо включать всё подряд. Под типовые ситуации работают разные наборы:

• После обрыва связи или аварийного завершения — реиндексация плюс проверка логической целостности. Этого хватает в большинстве случаев.
• Неверные остатки, съехавшие итоги — пересчёт итогов и проверка ссылочной целостности. Реструктуризация тут не нужна.
• Тяжёлое повреждение, база не открывается даже после chdbfl — полный набор с реструктуризацией. Это самое долгое и самое радикальное.

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

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

Откат из резервной копии

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

Файловая база. Вариантов два:

• Если копия — это просто файл 1Cv8.1CD: закройте базу у всех, замените текущий файл резервным.
• Если копия сделана выгрузкой (.dt): в конфигураторе Администрирование → Загрузить информационную базу и укажите файл выгрузки.

Клиент-серверная база . Восстановление штатно идёт через СУБД:

• MS SQL — восстановление из .bak средствами SQL Server.
• PostgreSQL — восстановление из дампа pg_restore.

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

Автоматические копии 1С делает сама, если включено в Администрирование → Поддержка и обслуживание (в режиме «Предприятие») — проверьте, где они лежат, там может оказаться свежий архив.

Если копия устарела, а в поломанной базе были свежие документы, учтите: автоматически «долить» новые данные из одной базы в другую 1С не умеет. Либо вы вытаскиваете документы из сломанной базы (если она хоть как-то открывается) и вводите их в восстановленную вручную, либо миритесь с потерей за период между копией и сбоем. Поэтому ценность копии измеряется её свежестью — суточная копия ограничивает потери одним днём.

Снятие блокировок и очистка кэша

Частый сценарий: база цела, но не пускает — «Конфликт блокировок» или бесконечное «Соединение с информационной базой». Повреждения тут нет, мешают застрявшие сеансы или служебные файлы.

Файл блокировки файловой базы. В папке базы рядом с 1Cv8.1CD появляется файл 1Cv8.1CL — это блокировки сеансов. Если программа аварийно завершилась, файл мог «залипнуть».

1. Убедитесь, что в базе реально никого нет (не просто «вроде вышли»).
2. Закройте все окна 1С на всех машинах.
3. Удалите файл 1Cv8.1CL.

Кэш клиента. Если база тормозит, глючит интерфейс или «не подхватываются» обновления, помогает очистка кэша. Кэш каждого пользователя лежит в профиле: %LOCALAPPDATA%\1C\1cv8 — закройте 1С и удалите подкаталоги кэша. База при этом не затрагивается, кэш пересоберётся при следующем запуске.

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

Восстановление клиент-серверной базы

В клиент-серверном варианте добавляется слой кластера серверов, и часть действий идёт не через конфигуратор, а через администрирование кластера.

Снять сеансы. Застрявших пользователей закрывают через консоль администрирования серверов 1С или утилитой rac. Посмотреть список сеансов — rac session list, параметры смотрите в rac help. Завершение сеанса — крайняя мера: предупредите людей, незавершённые операции оборвутся.

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

Остановка сервиса. Перезапуск службы «Агент сервера 1С» (ragent) сбрасывает зависшие рабочие процессы, но оборвёт сеансы всех баз кластера, а не только проблемной. Делайте это в окно, когда никто не работает , и только если точечно снять сеансы не вышло.

Физическую целостность базы данных в клиент-серверном варианте проверяют средствами СУБД: для MS SQL — DBCC CHECKDB, для PostgreSQL — штатные проверки и логи. Это зона администратора сервера; если доступа нет — восстанавливайте из копии.

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

Как предотвратить повторные сбои

Большинство «восстановлений» не понадобилось бы при настроенных копиях и обслуживании. Минимальный набор, который закрывает почти все аварии:

Регулярные копии — главное. Файловую базу разумно копировать ежедневно, а перед обновлением релиза — обязательно и отдельно. Бесперебойник на сервере снимает самую частую причину повреждений — обрыв питания посреди записи.

Для клиент-серверной базы регламентное обслуживание СУБД (переиндексация, обновление статистики) настраивается на стороне SQL и снимает деградацию производительности, из-за которой базу «идут восстанавливать», хотя она не сломана, а просто не обслуживалась.

Частые вопросы по восстановлению базы