Как восстановить базу 1с

Обновлено: 07.07.2024

Эта статья является продолжением цикла статей «Первые шаги в 1С». В ней рассмотрены типовые приемы восстановления базы 1С на платформе «1С:Предприятие 8» после сбоев. Предполагается, что база работает в файловом режиме работы. Восстановление базы в клиент-серверном режиме работы не рассматривается, т.к. данный вопрос явно выходит за рамки “первых” шагов начинающего специалиста.

Материал статьи детально раскроет ответы на следующие вопросы:

  • Что нужно делать до начала всех работ по восстановлению? (копию, Карл!)
  • Какие тонкости есть при использовании утилиты проверки?
  • Какие средства для восстановления есть в конфигураторе?
  • Когда и зачем нужно делать выгрузку/загрузку в формат *.dt?
  • Если все вышеописанное не помогло, что можно еще попробовать?

Применимость

Статья написана для платформы «1С:Предприятие» версии 8.3.4.496, но не переживайте, если вы работаете с более старшей версией! Весь материал является абсолютно актуальным.

Как в 1С восстановить поврежденную базу «1С:Предприятие 8»

Порой для новичка данная задача кажется просто нереальной. Хотя, на самом деле, есть ряд нехитрых штатных средств тестирования баз 1С и приемов исправления возникающих ошибок.

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

Причины возникновения критических ошибок бывают разнообразными. Чаще всего проблемы возникают из-за сбоев электропитания.

С уверенностью можно сказать, что при клиент-серверном режиме работы база более устойчива к возникновению ошибок.

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

Итак, главное не пугаться и перед попыткой восстановления базы сделать ее копию.

Например, можно сначала скопировать всю папку, в которой размещена база, а затем в этой папке оставить только файл 1Cv8.1CD (файл базы) и папку 1Cv8Log (журнал регистрации событий).

Путь к информационной базе

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

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

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

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

Первым делом удалите все файлы и папки, которые в заданной директории окружают файл базы (1Cv8.1CD). Да, это некие служебные файлы, обеспечивающие полноценную работу, но точно отмечено, что иногда в работе этих файлов возникает некоторое рассогласование.

Ничего страшного не случится, потому что при очередном запуске базы все необходимые файлы будут созданы заново. С запуском мы пока повременим.

Теперь используем самое эффективное, но еще далеко не последнее, средство. В директории C:\Program Files\1cv82 (для платформы 8.3 – 1cv8)\(далее номер релиза платформы)\bin запустите утилиту chdbfl.exe.

Внимание! В каждом релизе платформы есть своя утилита chdbfl.exe. Целесообразно использовать утилиту из того релиза платформы, с которым использовалась данная база. В большинстве случаев – это последний установленный релиз платформы.

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

Однако рекомендуем идти сверху вниз (от старших релизов к младшим). В конечном итоге, первоначальная копия у Вас есть, и Вы всегда можете сделать еще одну копию и повторить весь цикл.

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

Утилита chdbfl.exe

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

Тестирование и исправление ошибок в конфигураторе

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

Параметры тестирования и исправления

Улучшение результатов тестирования при повторном использовании данного средства не отмечено.

Следует еще сказать о средстве проверки конфигурации. По опыту, ошибки, отмечаемые данным средством, не отличаются особой критичностью. Скорее они просто замедляют работу самой базы. Что, по сути, для баз размером свыше 4 Гб пользователем может расцениваться тоже как повреждение базы.

Проверка конфигурации

Настройки проверки конфигурации

В данной форме также без абсолютно четкого понимания никаких настроек менять не стоит.

Следует сказать еще об одном не совсем очевидном методе. Дело в том, что при выгрузке базы в файл с расширением dt существует крайне низкая вероятность, что загрузить его обратно не удастся.

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

Если после всех проведенных мероприятий и испытаний Вы обнаружили, что Ваша база остается поврежденной, то целесообразно использовать и это средство.

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

Выгрузить информационную базу в конфигураторе

Появится диалоговое окно, в котором нужно будет указать направление выгрузки. Название создаваемого файла можно использовать по умолчанию – 1Cv8.dt.

Следует отметить, что выгрузка также является одним из возможных методов копирования.

Путь выгрузки

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

В появившейся форме поменяйте настройку на Создание информационной базы без конфигурации и также нажмите на кнопку Далее. На последующих двух шагах определите имя базы и директорию (пустую), в которой она будет находится.

Дополнительные параметры можно не заполнять и нажать на кнопку Готово. Будет создана информационная база без конфигурации.

Информационная база без конфигурации

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

Загрузить информационную базу

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

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

Иногда помогает удаление базы из списка в окне информационных баз с последующим добавлением в список той же существующей информационной базы (восстановление пути к ней).

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

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

В следующей статье рассмотрим возможности по настройке списка информационных баз.


PDF-версия статьи для участников группы ВКонтакте

Статья в PDF-формате

👍 Смотрите как восстановить повреждённую или удалённую базу 1С (на примере «1С: Предприятие 8.3»). Что делать, если программа не запускается, сама закрывается или вылетает с ошибкой.

Продукты компании 1С являются таким же программным обеспечением, как и любое другое. Информация, которую пользователи вносят в свои базы данных сохраняется в файлах, из которых можно создавать резервные копии или восстанавливать в случае повреждения или удаления. Часто для этого достаточно встроенных в «1С: Предприятие» инструментов, но и о стороннем программном обеспечении также забывать не стоит. Поехали!

1:15 - Файлы базы данных 1С.

2:40 - Признаки и причины повреждения базы 1С.

3:25 - Создание и восстановление из резервной копии базы 1С.

4:22 - Восстановление повреждённой информационной базы 1С.

4:41 - Восстановление с помощью Конфигуратора.

5:13 - Восстановление с помощью chdbfl.exe.

6:36 - Восстановление с помощью НЕХ-редактора.

7:22 - Как восстановить удалённую информационную базу 1С.

Все описанные в данной статье способы восстановления базы данных 1С показаны на примере платформы «1С: Предприятие 8.3». Но эта информация также актуальна для других программ и конфигураций платформы.

• 1С: Зарплата и управление персоналом

• 1С: Управление торговлей

• 1С: Управление Холдингом

• 1С: Управление предприятием

• 1С: Предприятие. Управление производственным предприятием

• 1С: Комплексная автоматизация

• 1С: Управление небольшой фирмой

• 1С: Отчётность предпринимателя

• 1С: Платёжные документы

• 1С: Бухгалтерия государственного учреждения

• 1С: Зарплата и кадры бюджетного учреждения

• 1С: Свод отчётов

• 1С: Бюджетная отчётность

• 1С: Документооборот государственного учреждения

• 1С: Государственные и муниципальные закупки

• 1С: Бюджет поселения

• 1С: Бюджет муниципального образования

• 1С: Электронное обучение и пр.

На этом всё. Ставьте лайк и подписывайтесь на наш канал. Задавайте интересующие по видео вопросы в комментариях. Всем спасибо за просмотр. Всем пока.

С упрямой периодичностью на форумах по 1С появляются крики души "Помогите! Упала файловая база, бэкапов нет, что делать?". Лично я всегда при этом вспоминаю известную шутку "Админы делятся на два типа — тех, кто делает бэкапы, и тех, кто будет их делать". Но, отбросив шутки в сторону, постараемся серьёзно рассмотреть данную проблему, ведь ситуации бывают разные. Например, бэкапы делались на диск, на котором закончилось место, или бэкапы делались через выгрузку, и все такие выгрузки за последнее время оказались неработоспособны. К слову сказать, даже админы, считающие себя "бывалыми", прокалываются на подобных мелочах.

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

  1. Помимо настроенных автоматических ежедневных бэкапов, обязательно сделайте дополнительный бэкап перед такими критическими операциями, как обновление конфигурации, ТиИ, проверка базу с помощью chdbfl.exe и т.п.
  2. Делайте бэкап архивированием (копированием) файла 1Cv8.1CD, либо комбинируйте копирование с выгрузкой в .dt. Ни в коем случае не ограничивайте бэкап только выгрузкой в .dt, ведь наличие некоторых ошибок в файле 1Cv8.1CD может привести к тому, что в выгрузке будет отсутствовать часть информации, либо выгрузку вообще невозможно будет загрузить. И если с 1Cv8.1CD можно "поколдовать" и попытаться выудить нужные данные, то в случае полностью отсутствующих данных уже ничего не сделаешь.
  3. Процедуру создания бэкапа выполняйте в такой период, когда с базой не работают пользователи.
  4. Периодически проверяйте наличие свободного места на устройстве, куда настроено автоматическое создание бэкапов.
  5. Старайтесь размещать бэкапы не на том же компьютере, где расположена сама база, а на других компьютерах/хранилищах в локальной сети (например, если на компьютере испортится жёсткий диск, или проникнет вирус-шифровальщик, получим порушенные и базу, и бэкапы). Старайтесь также периодически размещать бэкапы на дополнительных (альтернативных) источниках, например, в облачном хранилище (dropbox, yandex disk и т.п.), или на флэшке.

Пример окошка с критической ошибкой

Первоначальные действия для диагностирования таких случаев должны быть такими:

Пример отказа chdbfl.exe реанимировать базу

  1. Обязательно делаем самый первоначальный бэкап нашей проблемной базы (до любых манипуляций с ней) копированием/архивированием файла 1Cv8.1CD, и убираем его в надёжное место, дабы случайно не повредить.
  2. Пробуем войти в базу под другими пользователями.
  3. Полностью очищаем кэш 1С (это можно сделать, например, простым удалением базы из списка, и добавлением её в список вновь, либо использовать утилиты типа //infostart.ru/public/90572/ , либо удалить вручную http://help1c.com/faq/view/1267.html ).
  4. Пробуем перенести файл базы на другой компьютер, и войти в базу там.
  5. Прибегаем к помощи утилиты chdbfl.exe из поставки 1С:Предприятие, с установленной галкой "Исправлять обнаруженные ошибки".
  6. Ещё можно попробовать открыть базу на более свежих релизах 1С, например, если работали на 8.2.15, то можно попробовать на 8.2.17.

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

Итак, Вы решили починить базу своими руками, и окунуться в самые дебри загадочного содержимого файла 1Cv8.1CD. Какие же полезные статьи и инструменты мы имеем на текущий день?

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

Реструктуризация

Незавершенная операция

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

Восстановление базы


Поиск по интернету привел к страницам с описанием данных проблем без наличия решения, однако вскоре были найдены две важные ссылки, которые явились отправной точной в восстановлении:

Шаг №2. Делаем выгрузку конфигурации при помощи утилиты Tool_1CD

Выгрузка конфигурации

Шаг №3. Анализируем структуру файла испорченной базы

Итак, как вам известно CD файл - это по сути хранилище файлов-таблиц. Открываем Hex редактор (например опенсорсный Лирическое отступление

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


Итак взглянем на таблицу из HEX редактора:

Основная таблица смещений

Upd 10/10/2012

Важное замечание awa :

1С обращается к таблицам по имени, и ей не важно, какая таблица находится в списке первой, какая второй и т.д. Просто при создании новой базы 1С создает нужные таблицы друг за другом в том порядке, в каком это создание написали программисты 1С. Поэтому всегда и получается, что CONFIG идет первой, CONFIGSAVE второй и т.д. Но если бы первой таблицей была бы какая-нибудь _REFERENCE152, а CONFIG была бы семнадцатой в списке, 1С спокойно бы работала с такой базой.


Шаг №4а. Загружаем в пустую конфигурацию выгруженную конфигурацию (извините за каламбур)

Загрузили. Записали. Смотрим в HEX-редакторе

Структура в другой платформе

Так-с, что-то не то, какая-то новая таблица добавилась. Отсюда вывод: Восстановление нужно делать на том же релизе платформы, что и испорченная база.

Шаг №5б. Загружаем в пустую конфигурацию выгруженную конфигурацию той же самой версии платформы

Рабочая конфигурация

Да-а, результат тоже не очень. Таблица CONFIG заканчивается по адресу 0x10FFF, судя по всему она не реструктуризирована. Ладно попробуем скопировать рабочую таблицу Tool_1CD в нерабочую базу. Выделяем блок в рабочей базе и копируем с замещением по адресу 0x5000 в испорченную базу:

Выделение блока

Открываем Tool_1CD, открываем испорченную базу, но увы Tool_1CD виснет при попытке посмотреть таблицу CONFIG. После нескольких не правильных шагов, мне пришла идея: а что если 1С структурирует таблицы при загрузке базы? Тогда остается сделать выгрузку и загрузку базы с рабочей конфигурацией.

Шаг №5в. Загружаем в пустую конфигурацию выгруженную конфигурацию той же самой версии платформы, делаем выгрузку и загрузку базы (не конфигурации!).

Посмотрим как сейчас выглядят смещения:

После выгрузки/загрузки

Уже лучше. Теперь CONFIGSAVE расположена по адресу 0x31FC000, что больше чем 0x31F1000. Как же скопировать больший блок таблицы CONFIG в рабочей базе на меньший блок в испорченной базе? Ответ прост: надо удалить метаданные в рабочей конфигурации, не влияющие на ее структуру: общие модули, картинки, отчеты, обработки и т.п. Нам важно запустить испорченную базу, конфигурацию мы потом восстановим.

Шаг 6. Итерация по удалению метаданных конфигурации, не влияющие на ее структуру, выгрузка и загрузка базы.

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

Удаление метаданных

Наконец-то: CONFIGSAVE начинается с 0x313B0000< 0x31F1000. Теперь выделяем блок 0x5000- x313AFFF в рабочей базе и в адрес 0x5000 в испорченной базы копируем с замещением

Копируем блок

Записываем. Открываем 1С. Отклично, все заработало.

Важное замечание awa

Как правило по смещению 0x4000, содержатся ссылки на файлы описания таблиц. А уже в файлах описания таблиц содержатся ссылки на таблицы записей, индексов и BLOB. В общем случае, если таблица CONFIG "начинается" с адреса 0x5000, а таблица CONFIGSAVE с адреса 0x31f1000 и нет никакой гарантии, что на промежутке от 0x5000 до 0x31f1000 не содержится ни одного блока, относящегося к любой другой таблице, помимо CONFIG. В большинстве случаев таблица CONFIG не фрагментирована, объясняется это, думаю, тем, что такое расположение файлов одной таблицы друг за другом, так, что вся таблица как бы находится в файле 1CD одним непрерывным куском, образуется в результате применения сжатия базы данных при тестировании и исправлении или при применении утилиты chdbfl.exe.

База загрузилась

Осталось только загрузить в базу рабочую конфигурацию, чтобы восстановить рабочую базу. Все, База восстановлена.

Читайте также: