|
|
Регистрация | Правила форума | FAQ форума | Справка | Пользователи | Поиск | Сообщения за день | Все разделы прочитаны |
Накопители (HDD, SSD, CD, DVD, Flash и др. ) Обменяемся опытом работы с накопителями (HDD, CD/DVD, Flash и т.д.) |
|
Опции темы | Опции просмотра |
01.03.2018, 23:52 | #32 |
THG Russia Forum Team
Эксперт клуба THG | HDD/SSD |
9285,
какая такая?
__________________
Всему свое время и каждому свой час! Хочешь жить - умей вертеться! Методика тестирования носителей информации. Новый раздел на форуме - Обустройство дома, ремонт и строительство. В ЛС помощь не оказываю, для этого есть форум! |
02.03.2018, 00:26 | #34 |
THG Russia Forum Team
Эксперт клуба THG | HDD/SSD |
9285,
а как оно в русской версии переведено.
__________________
Всему свое время и каждому свой час! Хочешь жить - умей вертеться! Методика тестирования носителей информации. Новый раздел на форуме - Обустройство дома, ремонт и строительство. В ЛС помощь не оказываю, для этого есть форум! |
02.03.2018, 01:20 | #35 | |||
Нарушил правила
|
Wu-Tang
Ну так это от переводчика зависит. Может стоит просто заглянуть в расширенные настройки виртуального диска и посмотреть что там есть? Добавлено через 16 минут VBDUnit Давай, для начала разберёмся со сборкой. Ты собрал массив из секторов обоих дисков. Но дело в том что, в конце первого диска (и в начале второго) имеется служебная инфа, которая не относится к самому динамическому диску и вот она и произвела смещение. Давай сделаем сборку ещё раз и немного по другому - соберём только том NTFS. Или можешь просто скорректировать имеющуюся. В качестве первой части выбираешь сектора Drive3 (*) начиная с сектора 264192, число секторов - 5860265984 Вторая часть - Drive1, начиная с сектора 262178, число секторов - 5860268032 Первым выбираешь диск (*) номерацию дисков использую со скриншота твоей сборки Добавлено через 20 минут Дальше открываешь том - бутсектор у него будет уже в 0-вом секторе, т.к. его использовали в качестве начала. Если в root и далее не отображаются какие то папки (файлы), то можно сделать виртуальную реконструкцию. Ну а далее пробуй восстанавливать то, что ране было "битым". Можно использовать и другие манипуляции. Например - работа с картой кластеров и просмотр что содержится в кластерах далее 732533248-го. Или даже не восстанавливая файл можно сразу определить есть ли его содержимое (или часть) на втором диске. Для этого в контекстном меню требуемого файла выбрать "Открыть файл MFT", после чего в самой записи (в нижнем правом окне) найти атрибут 80h $DATA , выделить его и раскрыть его, нажав пробел. После этого пролистать данные до места где значения будут в три столбца. вот в этих столбцах смотреть значение relc - это номер стартового кластера. Если он больше вышенаписанного, то это область второй части массива. Добавлено через 5 минут И ещё один "финт ушами" - при наличии достаточного места на другом носителе. Собрать массив только вместо второй части выбрать пустышку с тем же размером в секторах (можно и больше). После этого начать восстанавливать данные. Когда будет произведена попытка восстановления из области второй части, будет предупреждение об этом и предложение назначить таким файлам атрибут скрытого. Ну а потом смотрим у каких файлов такие атрибуты. |
|||
02.03.2018, 06:24 | #36 |
THG Russia Forum Team
Эксперт клуба THG | HDD/SSD |
__________________
Всему свое время и каждому свой час! Хочешь жить - умей вертеться! Методика тестирования носителей информации. Новый раздел на форуме - Обустройство дома, ремонт и строительство. В ЛС помощь не оказываю, для этого есть форум! |
17.03.2018, 15:13 | #37 | |||
Нарушил правила
|
VBDUnit
попробовал разобраться во всей этой конструкции и понял ... что ничего не понял. Всё достаточно запутано и нет нормального описания всему этому клубку. Даже то, что давал раньше имеет в описании или пробелы или знаки вопроса. Часть понял по эмпирическим тестам, но не факт что в другой комбинации эти эмпирические выводы будут актуальны. К тому же, нет нормальных диагностических утилит. Единственная известная ldmdump слишком стара и не понимает ни огромных обьёмов, и уж тем более новую конструкцию используемую при GPT разметке при которой блок данных находится не в конце диска а в начале. Вот и получается что есть несколько ошибок, но даже исправив их ничего не меняется и можно лишь гадать где какой то байт не такой, или не то соответствие. Последнее наглядно можно увидеть изменив значение завершённой транзакции в блоке VMDK. Насколько понял, её значение равно максимальному из имеющихся. Если значение будет меньше (например не 5 а 4), то конструкция становится недопустимой, если больше - то всё нормально. И в том варианте что я предлагал (удалить-создать) тоже есть нюансы, при невыполнении котрых можно поиметь проблему при восстановлении по месту. В общем, наиболее оптимально (разумно) - собрать массив как написал выше и восстановить данные на другие носители. И впредь не связываться с динамикой или делать бэкапы метаданных - вообще и до всевозможных изменений. |
|||
14.07.2018, 21:56 | #38 | ||
Старожил
|
Сработало! вроде бы Я сделал вот это
Цитата:
1) 9285, огромнейшее тебе спасибо, ты помог мне решить практически невыполнимую для меня задачу. Скажи, как я могу тебя отблагодарить? 2) Можешь ли поделиться, как ты определил вот эти числа? Цитата:
PS. Сорян что пропал надолго |
||
14.07.2018, 22:24 | #39 | |||
Нарушил правила
|
Да, это прописывается в записях LDM - в #13 есть скриншот, на котором присутствуют все эти значения.
В качестве благодарности принимается твой отчёт. Тем более что, как писал ранее, именно разбор твоего случая подтолкнул к изучению всей этой конструкции. И хотя, теоретически и после проведения экспериментов, я понимал что должно сработать, но подтверждение всё таки лучше. Если бы не пропал надолго, то я всё таки смог бы дать инструкции по восстановлению массива по месту. А так, сразу не написал, теперь уже подзабылось. Если будет желание провести эксперимент - маякни; но тогда уже тебе прийдётся немного подождать. PS. Если всё таки хочется отблагодарить реально - окажи помощь кому посчитаешь нужным и какой хочешь суммой на сайте worldvita.ru Последний раз редактировалось 9285, 14.07.2018 в 22:29. |
|||
15.07.2018, 17:24 | #40 | |||
Старожил
|
Думаю, можно в DMDE собрать массив JBOD:
зная общее количество секторов в 6Тб массиве (диск1+диск2), зная реальное положение копии бутсектора в конце второго диска, посчитать примерное место "склейки" дисков в массив, потом проверять восстановлением файлов из кластеров второго диска - правильно ли они восстановлены. Остаётся проблема нахождения ТОЧНОГО места склейки (где конец данных на первом диске и где их начало на втором), но думаю, что это тоже можно вычислить по содержимому секторов. Даже если сразу не получится, потери там не очень большие. В итоге, в DMDE собрать виртуальный JBOD - и с него скопировать нужное на свободные места. P.S. я опоздал Последний раз редактировалось kickman, 15.07.2018 в 17:27. |
|||
17.07.2018, 16:31 | #42 | |
Старожил
|
Цитата:
Последний раз редактировалось VBDUnit, 17.07.2018 в 16:37. |
|
Здесь присутствуют: 1 (пользователей: 0 , гостей: 1) | |
Опции темы | |
Опции просмотра | |
|
|
Справочник словарей | ||
Словари русского языка - www.gramota.ru | Яndex - Словари | Википедия - ru.wikipedia.org |
|
|
|