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

Код типа: 128,  файл: 1421.
Не удается найти дочерний frs 0x722e с номером последовательности 0x7.
Атрибуты с одинаковыми типами кодов 0x80, но различными вхождениями тегов
0x0 и 0x0 имеют have несмежные VCN-номера 0x6dc80 и 0x755c0
соответственно в файле 0x58d.
Атрибут типа 0x80 и вхождение тега 0x0 в файле 0x58d
имеет длину 0x95108000 вместо 0x79140000.
Удаление поврежденного элемента списка атрибутов.
Код типа: 128,  файл: 1421.
Невозможно определить местонахождение атрибута с тегом вхождения 0x0
и ссылкой на сегмент 0x3000000000599. Ожидаемый тип атрибута 0x80.
Удаление поврежденной записи атрибута (128, "")
из сегмента 1433 записи о файле.
Ошибка чтения с кодом состояния 0xc000009c в смещении данных 0xc05e9c00 для 0x400 Байт.
Элемент индекса кодов объекта 0x19 указывает на файл 0x18a1,
но в этом файле отсутствует основной сегмент записи файла.
Удаление элемента индекса $O файла 25.
Элемент 1Cv8JobScheduler индекса $I30 в файле 0xc71 указывает на неиспользуемый файл 0xca5.                                                                                  
Удаление элемента 1Cv8JobScheduler из индекса $I30 файла 3185.
Замена плохих кластеров в журнале.
Добавление 53 поврежденных кластеров в файл поврежденных кластеров.
Исправление ошибок в атрибуте DATA основной таблицы файлов.
В рисунке основной таблицы файлов обнаружено свободное место,
помеченное как выделенное.
Исправление ошибок в битовой карте тома.

после чего естественно база 1с в чистом виде стала весить 0гб. но удалось выдернуть базу с последней датой изменения 27.07.19 но она как я понял сильно повреждена, в что написал chdbfl^
Повреждены данные таблицы 'CONFIG'. Восстановлено 40903 из 42509 записей.. Потеряно 25 значений полей неограниченной длины
Повреждены данные таблицы '_DOCUMENT10914'. Восстановлено 15 из 16 записей.
Повреждены данные таблицы '_DOCUMENT124_VT2479'. Восстановлено 30 из 32 записей.
Повреждены данные таблицы '_DOCUMENT185'. Восстановлено 390 из 406 записей.
Повреждены данные таблицы '_DOCUMENT193'. Восстановлено 0 из 1 записей.
Повреждены данные таблицы '_DOCUMENT197'. Восстановлено 340 из 348 записей.
Повреждены данные таблицы '_DOCUMENT197_VT5057'. Восстановлено 309 из 317 записей.
Повреждены данные таблицы '_DOCUMENT212'. Восстановлено 1048 из 1099 записей.
Повреждены данные таблицы '_DOCUMENT217'. Восстановлено 353 из 370 записей.
Повреждены данные таблицы '_DOCUMENT217_VT5714'. Восстановлено 1660 из 1713 записей.
Повреждены данные таблицы '_DOCUMENTJOURNAL27519'. Восстановлено 1444 из 1512 записей.
Повреждены данные таблицы '_DOCUMENTJOURNAL27535'. Восстановлено 788 из 793 записей.
Повреждены данные таблицы '_DOCUMENTJOURNAL6172'. Восстановлено 2270 из 2380 записей.
Повреждены данные таблицы '_SYSTEMSETTINGS'. Восстановлено 665 из 694 записей.. Потеряно 2 значений полей неограниченной длины
Повреждены данные таблицы '_COMMONSETTINGS'. Восстановлено 114 из 120 записей.. Потеряно 1 значений полей неограниченной длины
Повреждены данные таблицы '_INFORG9224'. Восстановлено 2274 из 2380 записей.
Повреждены данные таблицы '_INFORG22965'. Восстановлено 644 из 676 записей.
Повреждены данные таблицы '_INFORG30621'. Восстановлено 6024 из 6586 записей.
Повреждены данные таблицы '_INFORG33042'. Восстановлено 5 из 5 записей.. Потеряно 2 значений полей неограниченной длины
Повреждены данные таблицы '_ACCUMRG7770'. Восстановлено 264 из 280 записей.
Повреждены данные таблицы '_REFERENCE34'. Восстановлено 195 из 201 записей.
Повреждены данные таблицы '_REFERENCE10827'. Восстановлено 4291 из 4295 записей.
Повреждены данные таблицы '_REFERENCE47'. Восстановлено 338 из 342 записей.
Повреждены данные таблицы '_REFERENCE47_VT17787'. Восстановлено 518 из 519 записей.. Потеряно 2 значений полей неограниченной длины
Повреждены данные таблицы '_REFERENCE56'. Восстановлено 2566 из 2599 записей.
Повреждены данные таблицы '_USERSWORKHISTORY'. Восстановлено 558 из 558 записей.. Потеряно 96 значений полей неограниченной длины
Повреждены данные таблицы '_ACCRG475'. Восстановлено 2570 из 2690 записей.

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

В Tool_1cd например при сохранении конфигурации или экспорте в xml пишет "Несовпадение длины Blob-поля, указанного в записи, с длиной практически прочитанных данных"

С restoration-base-1c8-master не разобрался да и я так понял для версии "Бухгалтерия предприятия, редакция 3.0 (3.0.67.38)"

С редактированием HEX и структурой 1cd  у меня туго...
Все записей смещены, например в рабочей копии запись "{"ru_RU"..." находится на смещении "266b8200" а в восстановленной "25abc200"
первая запись "IBVERSION" в рабочей 3ec400d в мертвой 3ec200d
а записи "{"IBVERSION",0,{"Fields"," на равном смещении
в некоторых таблицах размеры файлов записей, blob-файла, файла индексов значения разные, причем в мертвой базе значение меньше, если в ней больше данных значит и размер должен быть больше, не?
а также в строчках {"Files",550,551,75967} для всех (а может и не всех) таблиц все значения меньше на единицу.

Может кто подсказать хотябы куда капать? 3 месяца вроде немного но всеравно документов много.

Это ИБП выдал скачок?

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

(0) путь дорога тебе в контору, которая данные с трупов вытягивает.
И бабло с собой бери. И много.

И ИМХО лучше сам не ковыряйся, а доверь дело профи

(4) не надо тиражировать свою беспомощность, можно попробовать, хотя ТС надо явно "тикать", я так понимаю ни бэкапов ни рейда, если останешься - будет наука.

Да скорее всего ибп выдал скачок.
Рейда нет, называется "собери самолет из говна и палок за 10 тр".

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

Такто акты накладные восстановил из банковских выписки. Есть конечно все счета и те в пдф, заводить их сомнительное удовольствие. вот и хотелось бы вывести данные из мертвой базы.

(3) Плюс тыща. В дисках горит электроника, данные на блинах никуда не делись, и их восстановят с вероятностью 99%.

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

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

А есть зависимость небольшой перегруз 220 и небольшие изменения в БД. Большой перегрух, соответственно больше таблиц БД задействовано в неисправности? ;)
Даже бытовой NAS QNAP D2, например, который питается от +12В спас бы ситуацию с бэкапами. А если к нему прикупить бесперебойник 12-вольтовый, то он будет живучее бесперебойника на 220В.

(10) есть зависимость сколько длились скачи и где находились головы винта и куда они прыгали

О, а вы рисковый

(11) Читайте что ТС писал. Побилась файловая система, после чекдиска файл рабочей базы обнулился, и пришлось вытащить с диска с помощью какой-то рековерялки файл, похожий на файл базы. Естественно, битый. Отношения к скачкам напряжения это повреждение не имеет. По сути, единственное, что произошло - разрушение ФС вследствие внезапного отключения.

И тестовой БД не осталось? :)

(5) Какую беспомощность, ты бредишь?
Дохнет как правило контроллер при данных вводных, чем быстрее принесешь профи и чем меньше будешь с ним работать - тем болше шансов получить инфу.

(15) +100500 Я бы таким "не беспомощным" экспериментаторам руки отрубал. После их колхозных попыток, как правило, данные потеряны окончательно.

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

(17) Это да. Но если у ТС в серваке погорела часть винтов, то несгоревшие могут быть донорами. Обычно ставят одинаковые.

(0) Добрый день. Согласна с palsergeich, нужно обратится в контору которая восстанавливает данные, потратьте время на поиски профи, чем пытаться самостоятельно что-то восстановить.

(0) помню, что еще в 90х в требованиях безопасности данных необходимо было писать бэкапы на ленту - каждый день на новую. Ленты должны храниться в других помещениях в бронированном сейфе, чтобы в случае пожара, взрыва, данные были целы.

+(20) *каждый день = каждый день недели

(20) бекапы на ленту до сих пор делают там, где есть критичные данные

(20) ну и кто это делал, мегазаводы? Стримаки стоили кучу денег и сейчас также. Картриджи тоже недешевые.

(23) люди работают головой, а не жабой

(23) обычный пивзавод, правда в собственности иностранцев

(20) Требования безопасности - палка о двух концах. Чем более надежно хранятся данные в смысле защиты от утери - тем сложнее их защитить от утечки. Всё зависит от того, на что нацелена политика ИТ-службы, не надежность или на конфиденциальность.

Орфографическая ошибка забавная...
кАпать вместо кОпать.

(0) " а диска с данными вроде запускается с глюками и при запуске автоматом запустил chkdsk примерно со следующим логом: " - надеюсь, образ диска снят перед этим экспериментом? Или всё решили угробить окончательно?

у ЖКХ, я так понял проблема у нинх, объем базы невелик, и записать бэкап раз в месяц на 2 разные флешки - не проблема

(29) восстанавливай им майскую копию, и пусть ручками фигачат первичку за 2 месяца

(30) +100
В любом случае работать с бэкапа, а то, что удалось восстановить, использовать как справочный источник данных.

(16) это твой личный опыт? у меня десятки удачных примеров спасения данных, после форматирования и т.п. Обращался в контору (кстати хорошую, но дорого) была муха цеце на сигейте, надо было паять - лень было, если ты не совсем долбоящер, умеющий писать только в 1с и только по ТЗ, то ничего сложного в этом нет.

Так и делаем, работаем с бэкапа.
В Тольятти сложно с восстановлением с блинов.
Нет диски разные "...из говна и палок за 10 т.р." 1. системный ssd kingston 60gb, 2. файловый wd750. 3. резервные копии samsung ide 80gb

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

(32) мой личный. Форматирование, сбой ФС да вытаскивал.
Сбой контроллера только через контору.
Да дорого, но быстро и круто сделали.

(33) Отправьте курьерской службой в МСК или лично, все решается

я не 1сник. админ. в 1с ковыряюсь так интереса ради и опыта. Я тоже восстанавливал данные с форматированных дисков и да же ОСь в рабочем виде, и не раз. Но тут первый раз. Хард с нестабильными секторами система решила что нужнен chkdsk и не замитил при запуске, косяк да знаю, всякое бывает, ну что теперь делать плакать изза неопытности или невнимательности? можно отправить в мск, да круто можно и так, указывать на ошибки тоже прикольно. А сказать о возможности восстановление данных из файла?

(33) Егорка сто шестьдесят три..., теперь ты будешь делать бекапы на другой источник.., тем более ты Одмин

(36) хрен знает что там перелопатилось, первым делом дамп нужно было снять.., а теперь, ну хз...

(35) все понятно личная заинтересованность
(36) нет слов, какой ты админ... даже я занимаюсь фигней иногда, но это верх непрофессионализма

(39) ОМГ какая личная заинтересованность?
Да мне вообще пофиг.
Просто в МСК контор больше

Может и буду а может смотря сколько заплатят или выделят средств на железо (бывают такие жадные люди).
(39) а сколько времени прошло с момента как вы стали профессионалом?

(40) ой сорри адресовано не мне, приношу извинения

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

(43) мне или кажется или не вникаете в написанное? вы для организации оборудование за свои деньги покупаете?

(44) Это для того что бы Вы ощутили всю глубину этих глубин...
а так да, (43) как старпер, причитает и причитает..., самоутверждается, что есть кто-то косячнее его

(43) У них "резервные копии samsung ide 80gb " - какие рейды вообще? :)

(45) видишь суслика

(45) точнее не скажешь, про глубину, человек как себя админом может называть? винду 7-ю умеет переустановить?, я честно про себя написал в карточке, но базы не фигачил, а вот восстанавливал часто, мне самоутверждаться за счет пионеров незачем, а вот "науки юношей питают", я ж не со зла

egor163, для желающих повозиться самостоятельно путь всегда один: сделать копию данных и "капать" её всеми возможными средствами. Каких-то более чудодейственных механизмов, чем те, что перечислены в (0) не существует. Сразу откинь идею самостоятельно довести файл данных до нужной кондиции. Скорее это будет какой-то остов базы или вообще пустая конфа, куда каким-то образом будут добавлять те обрывки данных, которые удастся заметить в пациенте.

Не понятной осталась фраза "С restoration-base-1c8-master не разобрался да и я так понял для версии "Бухгалтерия предприятия, редакция 3.0 (3.0.67.38)".