Каждый специалист, работающий с платформой 1С:Предприятие 7.7, рано или поздно сталкивается со специфическими сбоями файловой СУБД. Особое место среди них занимают низкоуровневые ошибки СУБД CodeBase. Появление сообщений вида CODEBASE ERROR /// reading file, сопровождающихся кодами Error #: -70 или Error #: -10, способно парализовать работу всей организации.
В этой статье мы подробно разберем природу этих критических ошибок, проанализируем возможные причины их возникновения — от банального сбоя жесткого диска до атаки вируса-шифровальщика — и изучим пошаговые методики реанимации поврежденной информационной базы.
Платформа 1С 7.7 в файловом режиме использует движок стороннего разработчика — систему управления базами данных CodeBase от компании Sequiter Software. Вся база данных представляет собой набор файлов таблиц с расширением .DBF и соответствующих им индексных файлов с расширением .CDX. Ошибки с отрицательными индексами возвращаются непосредственно ядром этого движка при невозможности выполнить стандартные операции чтения/записи.
Рассмотрим две наиболее опасные ошибки:
1SUSERS.DBF, 1SSYSTEM.DBF или индексного файла), но получил отказ или некорректный ответ. Это свидетельствует либо о физическом повреждении носителя, либо о жесткой блокировке файла сторонним процессом, либо о разрушении внутренней структуры самого файла.1Cv7.dd (в SQL-версии — 1Cv7.dds) или файл метаданных 1Cv7.md. Без этих файлов СУБД не способна сопоставить физические DBF-таблицы с объектами конфигурации.Если при попытке запустить информационную базу или выполнить процедуру «Тестирование и исправление» в Конфигураторе система выдает список ошибок доступа к файлам (1SUSERS, 1SSYSTEM, 1SCONST и т.д.), выполним несколько последовательных диагностических шагов.
Обратим внимание на путь к файлам, указанный в ошибке. Наличие спецсимволов, кириллицы в "битой" кодировке (например, D:Data\7\LyЁюё\1SUSERS.DBF) часто становится причиной сбоя инициализации сессии. Платформа 1С 7.7 крайне чувствительна к длине путей и корректности символов.
Переместим каталог с базой данных в корень диска, используя короткое имя папки латиницей без пробелов (например, D:\DB77\). Перевыберем путь к базе в стартовом окне запуска 1С и попробуем открыть ее снова.
Очень часто файлы индексов повреждаются при аварийном завершении работы компьютера (отключение электропитания, зависание сессии). При этом СУБД теряет возможность ориентироваться в DBF-таблицах. Для устранения этой проблемы полностью удалим все индексные файлы. Платформа автоматически пересоздаст их при следующем монопольном запуске.
Для быстрой очистки каталога от индексов мы можем воспользоваться простым командным файлом. Создадим в блокноте текстовый документ, вставим в него следующий код, сохраним с расширением .bat в папке с базой данных и запустим:
@echo off
echo Удаление индексных файлов CDX...
del /f /q *.cdx
echo Индексы успешно удалены. Запустите 1С в монопольном режиме для переиндексации.
pause
Откроем каталог информационной базы в проводнике или любом файловом менеджере и внимательно изучим размеры основных файлов: 1Cv7.md, 1Cv7.dd, 1SUSERS.DBF, 1SSYSTEM.DBF.
Если размеры большинства ключевых DBF-файлов составляют ровно 1 КБ, а при попытке открыть их через специализированный DBF-просмотрщик (например, DBF Viewer) программа сообщает о невозможности прочитать заголовок — это главный признак необратимого повреждения данных или деструктивного вмешательства внешнего ПО.
Прежде чем переходить к худшему сценарию, проанализируем три технические причины, которые также могут вызывать ошибку Error #: -70:
1SBKTTL.DBF, проводок 1SENTRY.DBF или журнала документов 1SJOURN.DBF) приближается к отметке 2.14 ГБ, СУБД теряет способность читать новые записи в конце файла, возвращая ошибку чтения -70.Если перенос базы в другую директорию не помог, удаление CDX-файлов завершается ошибками доступа, а размер системных таблиц стал подозрительно мал — мы имеем дело с атакой вредоносного ПО (вируса-вымогателя).
Шифровальщики редко обрабатывают многогигабайтные базы данных целиком, поскольку этот процесс занимает много времени и перегружает процессор, выдавая присутствие вируса администратору. Вместо этого они используют алгоритм быстрого повреждения:
Обратите внимание, почему при этом базы 1С v8.3 (особенно клиент-серверные) могут продолжать работать в штатном режиме. Базы данных MS SQL Server или PostgreSQL надежно защищены процессами самих СУБД, которые монопольно удерживают файлы баз данных, не позволяя сторонним процессам шифровальщика получить к ним доступ на запись. Файловые же базы 1С 7.7, лежащие в общих сетевых папках со свободным доступом на чтение и запись для пользователей, становятся идеальной мишенью.
Если резервных копий (бэкапов) не оказалось, стандартное «Тестирование и исправление» запустить невозможно. Проанализируем профессиональные методы восстановления, которые используют системные администраторы для спасения уцелевшей информации.
Большинство шифровальщиков работают по принципу: создание зашифрованного дубликата файла -> удаление оригинального незашифрованного файла с диска. Физически сектора данных на жестком диске все еще хранят вашу базу данных, пока поверх них не были записаны новые файлы.
Важно: Немедленно прекратите любые операции записи на пострадавший диск! Не копируйте туда новые программы и не проводите тесты на нем.
.dbf и .md в исходной директории.Если на сервере или рабочей станции была активна служба теневого копирования томов, у нас есть высокие шансы восстановить базу в исходное состояние, даже если вирус пытался очистить снимки системы.
Попробуем извлечь файлы с помощью специализированной утилиты ShadowExplorer или через свойства папки с базой данных (вкладка «Предыдущие версии»). Также можно проверить статус теневых копий через командную строку от имени администратора:
vssadmin list shadows
Если в списке присутствуют снимки, созданные до момента атаки, мы можем принудительно восстановить из них каталог с базой данных.
В случаях, когда файлы зашифрованы частично (вирус повредил только первые несколько килобайт заголовка, но основной массив записей внутри DBF остался цел), структуру таблиц можно восстановить с помощью словаря данных 1Cv7.dd.
1Cv7.md (если он уцелел или был восстановлен).Если система выдает ошибку «Код: -10. Ошибка открытия словаря базы данных» (отсутствует или испорчен файл 1Cv7.dd), мы можем заставить Конфигуратор сгенерировать этот файл заново на основе метаданных:
NEW_STRU, скопируем файлы 1Cv7.md и 1Cv7.dd оттуда непосредственно в корневой каталог базы с заменой.1Cv7.dd.Для того чтобы обезопасить базу данных 1С 7.7 от разрушительных сбоев файловой системы и вирусных угроз в будущем, внедрим три простых правила: