← На главную

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

Опасно ли тестирование без создания бэкапа?

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

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

1. Запись во временные структуры и служебные заголовки. При проверке логической и физической целостности платформа 1С активно создает временные таблицы и перестраивает индексы. В файловом режиме (файл 1Cv8.1CD) это влечет за собой физическую перезапись блоков на диске. Если в этот момент произойдет сбой (аварийное завершение платформы, выключение питания, нехватка оперативной памяти), структура файла останется в некорректном состоянии.
2. Фиксация событий в журнале регистрации. Любые действия и обнаруженные ошибки во время тестирования записываются платформой в журнал регистрации (файлы 1Cv8.lgd или 1Cv8.lgf). Таким образом, физические операции записи происходят гарантированно.
3. Сбои при обработке поврежденных элементов. Если в базе уже присутствует сбойный объект (например, с ошибкой формата потока), столкновение с ним в процессе анализа может вызвать критическое падение платформы 1С. Известны случаи, когда после незапланированного завершения аварийного процесса размер файловой базы сокращался с нескольких гигабайт до сотен килобайт.
4. Аппаратные сбои дисковой системы. При интенсивном считывании данных во время проверки нестабильные секторы диска (Bad-блоки) могут окончательно выйти из строя, что приведет к нечитаемости файла базы данных.
5. Разрастание транзакционных журналов и переполнение памяти. В клиент-серверном режиме процедура создает огромную нагрузку на СУБД, приводя к быстрому росту журналов транзакций (например, LDF-файлов в MS SQL или WAL в PostgreSQL), а также интенсивному заполнению каталога временных файлов ОС (%TEMP%). Нехватка места на диске завершит процесс ошибкой.

Безопасная последовательность диагностики базы 1С

Чтобы минимизировать риски и гарантировать сохранность данных, проанализируем и применим следующий проверенный алгоритм проведения диагностики:

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

   Перед диагностикой рекомендуется очистить кэш 1С на рабочем месте, удалив содержимое каталогов %AppData%\1C\1Cv8 и %LocalAppData%\1C\1Cv8. Часто именно поврежденный кэш провоцирует ложные сбои структуры и ошибки формата потока.

3. Проверка утилитой physical целостности (для файловых баз):

   Перед запуском штатного тестирования через Конфигуратор выполним проверку утилитой chdbfl.exe (она находится в папке bin установленной платформы). Утилита проверяет целостность заголовков и таблиц файла базы на физическом уровне.

4. Запуск проверки на тестовом контуре:

   Самым безопасным решением является разворачивание резервной копии на отдельном ПК или тестовом сервере и выполнение полного тестирования именно на ней. Рабочая база при этом продолжает функционировать без рисков и простоев.

Альтернативные способы проверки

В клиент-серверном варианте работы диагностику структуры данных часто эффективнее и безопаснее начинать средствами самой СУБД. Посмотрим на основные инструменты:

• В MS SQL Server используем команду DBCC CHECKDB для проверки логической и физической целостности базы данных до запуска внутренних регламентов 1С.
• В PostgreSQL применяем утилиты vacuumdb и reindexdb для обслуживания и проверки таблиц.
• Для автоматизации процедуры во внерабочее время можно использовать запуск Конфигуратора через командную строку с параметром /IBCheckAndRepair -TestOnly.

Резюме: Никогда не пренебрегайте бэкапом. Попытка сэкономить несколько минут на создании копии перед запуском режима «Только тестирование» может привести к полной потере рабочей информационной базы.