proNovell

Привет всем!
Начал сыпаться диск. Проявлялось это тем, что при попытке записи на консоль сервера валились ошибки о невозможность записать FAT.
После этого диск автоматически размонтировался.

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

С тех пор прошло ~2 недели
Но вот на днях выяснилось, что не всю нужную инфу слили. Смонтировал том, начал копировать нужные файлы. На консоль сервера посыпались сообщения что-то типа "файл такой-то не может быть востановлен".
После чего том опять сам размонтировался.
Вечером перегрузил сервер, смонтировал том. При монтировании запустился vrepair, прогнал тест, обнаружил кучу ошибок, автоматически их исправил.
Теперь на томе полный бардак наступил. Все файлы лежат в одной куче. Большей части каталогов нет. Появилось много странных файлов с размером 4096Мб. Появились каталоги VR??????.LNG с различными файлами и такие же файлы с такими же именами.
Похоже посыпались блоки ФАТа и vrepair как смог восстановил его, а что не смог запихнул в vr*.lng.

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

Сервер NetWare 4.11 + SP9

С уважением

КУ??

PS.
А резервная копия?

Ку - видимо означает - все абзац, забирай что есть и радуйся, что хоть что-то удалось унести?

Резервную копию ищу. Том использовался для хранения разных старых документов и программ. Резервная копия делалась в какие-то стародавние времена. Есть шанс что я ее не найду.

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

Андрей Тр. aka RH писал(а):Ку ведет на ссылку, где уже обсуждалась подобная тема .. в которой, возможно, есть ссылки на другие подобные темы .. которые обычно находятся Поиском. В переводе с проновского означает "не ваш случай ?" и/или "а поиск пробовали ?" и/или "тема уже неоднократно обсуждалась, так что лень снова писать полноценный ответ".

Извиняюсь.

Собственно, я и начал с поиска. Ну чтож, продолжу.

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

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

Влад А.Сокол aka Akina писал(а):vrepair при массированных повреждениях (кои имели место) в общем разрушитель почти такой же, как и scandisk.

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

Спасибо за ответ. Хоть он и не радостный. Я тоже пришел к такому же выводу.
Посмотрел диск демкой OnTrack Data Recovery for Netware, ничего нового не увидел. Интересно, может ли эта утилита (нормальная версия) просканировать диск и попытаться найти мои файлы?

res писал(а):Интересно, может ли эта утилита (нормальная версия) просканировать диск и попытаться найти мои файлы?

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

В данном случае все файловые структуры в том виде, в котором имело смысл на них напускать эвристика, уже благополучно перезаписаны vrepair-ом, т.е. умерли безвозвратно. Единственное, что может быть найдено - это в незанятом пространстве могут оказаться элементы каталогов с записями о файлах (откуда файлы начинаются). Только это и сможет восстановить эвристик - и то при условии что файл не был фрагментирован и все потребное на него пространство на текущий момент не занято и в процессе работы vrepair (вернее, с момента удаления этого каталога, возможно vrepair-ом в процессе восстановления) не перезаписывалось, в противном случае в теле файла окажется мусор. Если же вы найдете эвристик, ищущий тела файлов по сигнатурам - его ждут те же самые трудности (да и есть ли такие под TFS/NSS?). Правда, он будет искать сигнатуры по всему незанятому пространству и, даже, возможно что пытаться отслеживать целостность структуры при сборке файла, но зато он ограничен поиском только известных ему форматов.

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

Влад А.Сокол aka Akina писал(а): А в общем дело настолько тухлое, что проще забы(и)ть...

Вот и я думал как-бы ето одной фразой выразить...

Влад А.Сокол aka Akina писал(а):Любая сканирующая программа сканирует то, что есть на диске. В простейшем случае - только файловые структуры (таблицы размещения и записи каталогов), в продвинутом - еще и незанятое телами файлов и каталогов пространство.
...

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