Классика жанра. Вырубили свет и 1C перестала запускаться.

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

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

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

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

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

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

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

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

(6) почти. Делал 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 записей.
Поврежден заголовок внутреннего файла <Описание таблицы ''>

Вопрос насколько высоки шансы поднятия базы с такими повреждениями?

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

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

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

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

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

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

(11) согласен. Надо в начале определить что за таблицы повреждены. Если критичные, то смысла нет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(28) чем? ТиИ?

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

Если погас свет, то немедленно выключаем машину.
Сначала проверку диска (chkdsk)
Потом chkdbf
И только потом ТИИ.

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

(25) NTFS?

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

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

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

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

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

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

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

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

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

(31) Ни в коем случае не запускать chkdsk - в ее задачу входит лишь приведение ФС в корректное состояние. Данные при этом она не очень-то и сохраняет. Как получится. Иногда портит безвозвратно.

(41) Дык представь, что мусор оказался на месте служебных структур 1CD. В данном случае надо разбирать 1CD по кусочкам - "на глаз" сопоставляя правильность служебных структур. И только потом уже натравливать утилиту по восстановлению.

(42) Судя по http://infostart.ru/public/19734/, там ничего хитрого, обычная по сути файловая система. Соответственно, испортив заголовочный блок, можно потерять всё, испортив блок описателя - можно потерять конкретный внутренний файл, испортив блок данных - можно потерять часть данных файла. Но так, чтобы один испорченный блок испортил данные сразу в нескольких файлов - не будет.

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

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

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

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

(45) 1. Дык и на форуме не каждый раз пишут о подобном, пора бы уже и такому случиться ;)

2. Честно говоря, я еще ни разу не встречался с битыми данными, переданными через USB (а у меня таких дисков с десяток, и пользую я их лет 8 как минимум). Причем с плохими проводами встречался - и даже в этом случае девайс либо отваливается из системы, либо тормозит, но данные передает корректно.

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

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

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

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

(51) Что не так?

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

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

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

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