Не запускается файловая 1C. Файл базы данных поврежден. Ошибка данных crc #700961

Классика жанра. Вырубили свет и 1C перестала запускаться. Вводишь пароль. Висит окно запуска конфигурации с названием конфигурации и все. Попробовал сделать копию CD файла выдало - Ошибка данных crc. Сейчас прогоняю CHDDBF, но думаю без толку. Придется шаманить через Tool_1CD. Но как узнать имя поврежденной таблицы?   Какие еще есть способы ремонта базы?

Есть одно гарантированное - восстановление из бекапа

бэкап не предлагать?

Бэкап в данной ситуации поможет только в комплекте с машиной времени

Что за привычка писать не по вопросу. BackUP не слишком актуальный, мягко выражаясь. CHDBF покажет поврежденные таблицы

нет бекапа? Пусть забивают с бумажек, раз на сисадмине толковом сэкономили.

"Попробовал сделать копию CD файла выдало - Ошибка данных crc" А вот это интересно. Файл не копируется средствами ОС?

Попробуй подключить диск с базой к другому компу и скопировать на нём, чтобы исключить проблемы с контроллером и памятью. Если файл попал на бэдблок - прогони чекдиск с проверкой поверхности, тогда какие-то данные возможно пропадут, но файл прочитается. Далее - стандартное лечение 1с, сначала chddbfl, потом ТиИ.

почти. Делал crtl-c -> ctrl-v выдало эту ошибку. Запустил через батник на другой диск - сделал. Запустил на этой копии CHDBF и Повреждены данные таблицы 'FILES'. Восстановлено 14 из 14 записей.. Потеряно 5 значений полей неограниченной длины Повреждены данные таблицы '_SYSTEMSETTINGS'. Восстановлено 64 из 64 записей.. Потеряно 1 значений полей неограниченной длины Повреждены данные таблицы '_REFERENCE45'. Восстановлено 681 из 753 записей. Повреждены данные таблицы '_REFERENCE49'. Восстановлено 600 из 619 записей. Повреждены данные таблицы '_DOCUMENT111'. Восстановлено 539 из 571 записей.. Потеряно 8 значений полей неограниченной длины Повреждены данные таблицы '_DOCUMENT111_VT1582'. Восстановлено 20157 из 23554 записей. Повреждены данные таблицы '_DOCUMENT117'. Восстановлено 243 из 243 записей.. Потеряно 6 значений полей неограниченной длины Повреждена таблица размещения внутреннего файла <Данные таблицы '_DOCUMENT118_VT1987'> Повреждены данные таблицы '_DOCUMENT118_VT1987'. Восстановлено 0 из 1 записей. Повреждены данные таблицы '_DOCUMENT138'. Восстановлено 2610 из 2911 записей. Повреждены данные таблицы '_DOCUMENT138_VT2517'. Восстановлено 2612 из 2910 записей. Повреждены данные таблицы '_DOCUMENT149'. Восстановлено 38 из 38 записей.. Потеряно 6 значений полей неограниченной длины Повреждены данные таблицы '_DOCUMENT166'. Восстановлено 6286 из 7003 записей. Повреждены данные таблицы '_DOCUMENT168'. Восстановлено 488 из 554 записей.. Потеряно 2 значений полей неограниченной длины Повреждены данные таблицы '_DOCUMENT178'. Восстановлено 403 из 418 записей. Повреждены данные таблицы '_DOCUMENT186'. Восстановлено 370 из 402 записей. Повреждены данные таблицы '_DOCUMENT194'. Восстановлено 5970 из 6838 записей. Повреждены данные таблицы '_DOCUMENT195'. Восстановлено 2412 из 2880 записей.. Потеряно 7 значений полей неограниченной длины Повреждены данные таблицы '_DOCUMENT197'. Восстановлено 881 из 1019 записей. Повреждена таблица размещения внутреннего файла <Данные таблицы '_DOCUMENT202'> Повреждены данные таблицы '_DOCUMENT202'. Восстановлено 0 из 9747 записей. Повреждены данные таблицы '_DOCUMENT204'. Восстановлено 5471 из 6311 записей.. Потеряно 3 значений полей неограниченной длины Повреждены данные таблицы '_DOCUMENT209'. Восстановлено 5963 из 7137 записей.. Потеряно 22 значений полей неограниченной длины Повреждена таблица размещения внутреннего файла <Данные таблицы '_DOCUMENT211'> Повреждена таблица размещения внутреннего файла <Данные неограниченной длины таблицы '_DOCUMENT211'> Повреждены данные таблицы '_DOCUMENT211'. Восстановлено 17101 из 27139 записей. Повреждена таблица размещения внутреннего файла <Данные таблицы '_DOCUMENT211_VT5114'> Повреждены данные таблицы '_DOCUMENT211_VT5114'. Восстановлено 0 из 196416 записей. Повреждены данные таблицы '_DOCUMENT218'. Восстановлено 1393 из 1537 записей.. Потеряно 10 значений полей неограниченной длины Повреждены данные таблицы '_DOCUMENT219'. Восстановлено 172 из 304 записей. Повреждены данные таблицы '_DOCUMENT232'. Восстановлено 1652 из 1863 записей. Повреждены данные таблицы '_DOCUMENT236'. Восстановлено 35 из 38 записей. Повреждена таблица размещения внутреннего файла <Данные таблицы '_DOCUMENTJOURNAL6165'> Повреждены данные таблицы '_DOCUMENTJOURNAL6165'. Восстановлено 56885 из 65709 записей.. Потеряно 26 значений полей неограниченной длины Повреждены данные таблицы '_DOCUMENTJOURNAL6199'. Восстановлено 11425 из 13450 записей.. Потеряно 1 значений полей неограниченной длины Повреждены данные таблицы '_DOCUMENTJOURNAL6215'. Восстановлено 9275 из 10757 записей. Повреждены данные таблицы '_DOCUMENTJOURNAL6232'. Восстановлено 40848 из 46537 записей.. Потеряно 39 значений полей неограниченной длины Повреждены данные таблицы '_DOCUMENTJOURNAL6245'. Восстановлено 1653 из 1863 записей. Повреждены данные таблицы '_INFORG6491'. Восстановлено 102 из 102 записей.. Потеряно 1 значений полей неограниченной длины Повреждены данные таблицы '_INFORG6553'. Восстановлено 564 из 615 записей. Повреждены данные таблицы '_INFORGCHNGR6575'. Восстановлено 556 из 709 записей. Повреждена таблица размещения внутреннего файла <Данные таблицы '_INFORG6679'> Повреждены данные таблицы '_INFORG6679'. Восстановлено 0 из 11 записей. Повреждены данные таблицы '_INFORG6852'. Восстановлено 49434 из 49512 записей. Повреждены данные таблицы '_INFORGCHNGR6860'. Восстановлено 49518 из 49598 записей. Повреждена таблица размещения внутреннего файла <Данные таблицы '_INFORG6886'> Повреждены данные таблицы '_INFORG6886'. Восстановлено 195650 из 220778 записей. Повреждена таблица размещения внутреннего файла <Данные таблицы '_INFORG7113'> Повреждены данные таблицы '_INFORG7113'. Восстановлено 0 из 19146 записей. Поврежден заголовок внутреннего файла <Описание таблицы ''> Вопрос насколько высоки шансы поднятия базы с такими повреждениями?

на съемном HDD тоже можно прогнать проверку дисков?

[ насколько высоки шансы поднятия базы с такими повреждениями] база поднимется, но в ней не будет части документов и их ТЧ, разрушения мозаичные и польза от этой базы = 0

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

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

Я бы всё-таки попробовал скопировать на другом компе.. есть риск, что просто что-то с контроллером ЖД.

да у вас батенька HDD того... если всё-же каким-то боком сделали копию базы - может какую утилиту на HDD напустить?

согласен. Надо в начале определить что за таблицы повреждены. Если критичные, то смысла нет. Если я разверну конфу того же релиза у себя, то имена таблиц будут совпадать? Например, таблица _INFORG7113 будет у меня ТЧ Товары Реализации и в поврежденной тоже ТЧ Товары Реализации или может оказаться другой (например от каких-нибудь возвратов)?

может быть. Тем более что внешний USB диск.

Ну по идее должны совпадать. Имена же таблицам не хаотично присваиваются.

это в 77 они совпали бы. Тут гарантий никаких.

Исходный жесткий диск с базой - usb? Офигеть. Возможность подключить его к компу напрямую есть? Попробуй скопировать еще раз там.

ага. А еще работают по сети

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

И кстати, я же говорю - есть шанс что диск в порядке. Попробуйте всё-таки вынуть его из usb-коробки, и скопировать данные обычным интерфейсом sata на другом компьютере.

[Надо в начале определить что за таблицы повреждены] метод глобального контекста в 8.2 лет 5 как это умеет

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

а какие утилиты для HDD посоветуйте?

и чем скопировать данные с диска?

если при обычном копировании вылетает Ошибка данных crc?

проверьте заодно и копию базы

чем? ТиИ?

Сначала сделайте акронисом образ диска, чтобы "не навредить", далее этот образ разверните на новый пустой. И уже с ним экспериментируйте.

Если погас свет, то немедленно выключаем машину. Сначала проверку диска (chkdsk) Потом chkdbf И только потом ТИИ. Если ошибка CRC при копировании, то сектор файла вылетел на диске (хорошо, если только один). Информация в нём "коту под хвост" - и молите бога, чтобы это был не заголовок размещения таблиц (хотя, в этом случае, BackUp может и помочь).

NTFS?

хотя наверное в любом случае вряд-ли что-то лучше chkdsk...

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

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

к своему огромному удивлению базу удалось восстановить. Причем мало кровью. Что было сделано: 1) Скопирован файл с помощью DurableCopy . Было потеряно несколько байт. 2) Прогнано через CHDBF. Выдало что сколько-то таблиц FILES повреждено и в итоге база запустилась...

Копировали через usb или напрямую?

через USB. Диск вроде не разборный был

Кошмар.. надеюсь, больше такого не повторится?) Базу на usb-диске хранить - редкостное извращение..

Достаточно 1 повреждения в нужном месте - и не такое будет. Вот оно, следствие тройной упаковки...

В смысле упаковки? Данные в 1cd не сжаты, это по сути "виртуальный диск" со своими файлами, так что потеря какого-то блока приведет к тому же, к чему приводит потеря сектора на обычном диске...

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

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

Там по цепочке может пойти якобы некорректность из-за якобы пересечения цепочек. Никогда что-ли FAT не восстанавливал? Т.е., реально поврежден только один файл, но из-за того, что программа восстановления не догадалась об этом - из-за этого повреждения она посчитала некорректной структуру других файлов (хотя они вполне нормальные).

В теории такое возможно, но крайне маловероятно при однократном сбое записи. А вот если диск сыпется или интерфейс передает данные криво - тогда и будет в данных каша. С usb-коробкой это наиболее вероятно.

если это действительно "файловая система" - раздел размещения файлов должен быть продублирован.

.2 старые бэкапы у него есть (как понял с той-же структурой данных), так что это тоже решаемо.

1. Дык и на форуме не каждый раз пишут о подобном, пора бы уже и такому случиться ;) 2. Честно говоря, я еще ни разу не встречался с битыми данными, переданными через USB (а у меня таких дисков с десяток, и пользую я их лет 8 как минимум). Причем с плохими проводами встречался - и даже в этом случае девайс либо отваливается из системы, либо тормозит, но данные передает корректно. А вот с дешевыми NAS'ами такое было - при записи случайным образом искажались 1-2 байта на примерно 1 Гб записанных данных. Подключал его же по USB (в этом случае полностью отключался процессор NAS'а и HDD включался через мост SATA-USB напрямую) - все четко и без ошибок.

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

Это было бы "вполне возможно" на доисторических моделях ЖД, в которых блок головок перемещался шаговым двигателем. Помню такие 40-мегабайтные винчестеры на 286 компах. Там нужна была обязательная парковка перед выключением, соответствующую команду выводили в меню нортон коммандера. На 386 с 120-меговыми дисками уже магнитные головки позиционировались катушкой, и парковались автоматически под действием сил пружин.

"...и парковались автоматически под действием сил пружин." бу-га-га

Что не так?

не так - "под действием сил пружин"

Почему бы и нет? Это простой и дешевый способ убрать головки при отключении магнитного поля катушки позиционера..

Производители думают и делают иначе.

Ну какая в принципе разница.. если им проще дернуть привод запасенной в конденсаторе энергией в зону парковки при снижении напряжения питания ниже порогового - результат тот же.