Проблема с составным томом - Страница 2

9285 · 10.05.2019, 19:40

В секторах, где ожидались записи MFT нет ничего подобного.
Не хочется думать о печальном, поэтому надо посмотреть что в этих же секторах на другом диске - возможно он является начальным. А можно и не смотреть а приступить к полному сканированию (с учётом написанного ранее).
в процессе скана делай промежуточные сохранения лога - и можешь выложить (в запакованном виде) таковой когда просканируется примерно 7000000 секторов.

vladimir87 · 11.05.2019, 11:06

Дампы второго во вложении, полный скан запустил.

vladimir87 · 11.05.2019, 13:18

Логи сюда не влезают, поэтому скинул на гугл диск.
https://drive.google.com/open?id=1E1...Ydvf8LYf0uPGhE

9285 · 11.05.2019, 20:55

vladimir87
Ок. Ситуация немного проясняется, но ещё не окончательно.
Выясняется что с памятью у тебя склероз, надеюсь что зрение в порядке.

Каким цветом были окрашены тома в диспетчере дисков винды?

vladimir87 · 12.05.2019, 09:51

Насколько я помню бирюзовый

9285 · 12.05.2019, 10:06

Когда вчера смотрел логи уже думал написать что ситуация швак, потому как в дампах не было нужного и в огромнейшем числе блоков не отслеживалась необходимая структура. Но в таких случаях не стоит торопиться с выводами, потому как всякое бывает - и это подтвердилось. Просмотр логов при разных сортировках позволил заметить чётко чередующиеся блоки по 64 записи, расположенных в секторах со значением в 2 раза меньше прописанного в 0-вой секторе. И стало понятно что у тебя ~~не закрытый перелом а открытый~~ использовался чередующийся том, у которого как раз бирюзовый цвет. Так что, со зрительной памятью у тебя всё нормально.

Добавлено через 12 минут

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

В данной ситуации можно попробовать воспользоваться функционалом автоматического определения RAID - такая функция есть в DMDE (насколько знаю - в R-studio). Если что - размер блока 64кб.

9285 · 12.05.2019, 17:05

До сих пор не смог понять откуда берётся смещение для в районе начала второго фрагмента, имеющееся и в смоделированной ситуации - но при этом прекрасно работает вполне логичная сборка массива.
Можешь и сам попробовать собрать и проверить.
На скриншоте изображено как собрать массив в DMDE.
Сначала указываешь тип массива и размер блока.
Потом плюсиком (отмечено зелёным) последовательно добавляешь два физических диска - первым тот, на котором есть том с меткой data.
Далее меняешь параметры (выделено оранжевым) каждого из диска - при данном типе массива достаточно сменить только стартовый сектор.
После этого можешь открыть найденный том и посмотреть что в нём, восстановить на другой носитель и проверить какие то файлы.

vladimir87 · 12.05.2019, 22:30

Цитата (9285) »

Можешь и сам попробовать собрать и проверить.
На скриншоте изображено как собрать массив в DMDE.

Сработало! Собрался RAID, данные на месте! Осталось их только восстановить на другие диски! Огромное тебе спасибо, как я могу тебя отблагодарить за помощь!?

9285 · 12.05.2019, 22:45

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

Метода восстановления по месту составных томов уже проверена, с чередующимися ещё не пробовал, хотя думаю что всё аналогично. Но одно дело делать это в смоделированной ситуации - совсем другое в реальности.

vladimir87 · 13.05.2019, 08:23

Не вопрос, давай проверим, к вечеру думаю R-studio закончит копирование на новые диски, и можно будет поэкспериментировать.

9285 · 13.05.2019, 10:57

В виду того, что написать надо не так уж мало - буду писать по частям.
Вступление
Технически, можно попробовать разобраться с самими записями LDM и что в них не так. Основная проблема в том, что нет достоверной (100% ной) информации о том, как устроено всё это. Разобраны основные моменты, но некоторые вещи до сих пор являются белым пятном. и может оказаться что какой то байтик в белом пятне и является критичным.
Поэтому делается заход с другой стороны - смоделировать ситуацию создания массива при которой будет создана новая LDM. И тут самый главный момент - точность создания массива. Особенно это очень актуально для составных томов. состоящих из нескольких фрагментов (в том числе на одном диске). Хотя и в такой ситуации у меня получилось создать массив а потом скорректировать его записи в части размеров блоков и их позиции в самом массиве.
В случае с "полосатиком" эта точность не критична, зато очень критично организовать само чередование - то есть какой из дисков будет начальным.

Сразу небольшое предупреждение. У тебя используется новодел (10ка) и по скриншоту видно что она проинициализировала диски как то по своемому. Я не исключаю что и само создание массивов у неё отличается, но нет никакого желания ставить это д...мо и проверять так ли это.

Поэтому надежда на то, что часть кода, отвечающую за создание массивов не затронули. Вывод - для создания массива лучше всего использовать ту систему, под которой он формировался изначально.
В случае если это не принципиально важно. я в своих "экспериментах" использую "старушку" win7 поэтому всё написанное далее относится к ней.

В описании дальше предполагается что на массиве создаётся один логический диск, в случае с большим числом дисков вряд ли что то меняется, тем не менее лучше это уточнить.
1. Если дальнейшая сборка будет сделана правильно, то винда обнулит бустектор бывшего тома. И хотя можно будет найти копию такового, нельзя не исключать что её может не оказаться. Поэтому лучше сразу зарезервировать её.
В твоём случае это содержимое сектора 2048 на диске, где есть раздел data.
В случае чередующегося тома, при неправильном задании начального диска обнулится такой же сектор другого диска, поэтому для подстраховки не помешает создать дамп этого сектора и с другого диска.

СПОЙЛЕР »

В моделировании ситуации именно такое и произошло. Как выяснилось. в том секторе находился метафайл $Upcase и последующая поверка чекдиском не нашла ошибки в нём, хотя вполне очевидно что какая то его часть была обнулена.

2. Подготовительный этап.
Его задача - избавится от старой базы LDM.
В случае MBR разметки диска, как писал выше - эти данные записаны в конце каждого диска + приватный заголовок (PRIVHEAD) есть в начале диска. Конкретный данные массива можно уточнить в ранее указанных блоках VBLK, но в твоём (типичном для современных win случае) части массива начинаются в секторе 2048 (*) и их размер определён в тех же записях, но не далее примерно 2048 -го сектора от конца каждого из дисков.
В принципе, можно использовать команду clean (без дополнительных ключей0 из diskpart, которая очищает искомые сектора, но я не могу гарантировать что это будет сделано именно так и особенно применительно к ситуации когда ещё актуален старый массив (у тебя то его уже нет).

СПОЙЛЕР »

В одном из экспериментов лишил том буквы и в в таком состоянии сделал clean на каждом из дисков массива - очистилось бОльшее количество секторов.

. Поэтому, как говорится "Хочешь сделать хорошо - сделай сам".

Для начала, чтобы исключить работу винды с дисками-участниками (особенно если речь идёт о актуальном массиве) надо сделать каждому их этих дисков MBR off, применить изменение разметки и перезагрузить систему.
После этого занулить 2048 секторов от начала диска (0-2047) - на скриншоте показано как делается зануление для начала диска; и столько же - от конца. Применительно к MBR разметке, можно найти в конце диска сектор в начале которого записано TOCKBLOCK (это и есть начало базы LDM) - и затереть сектора начиная с него и до конца диска.
И, несомненно, перед занулением секторов можно сохранить их содержимое - это если захочется проанализировать ситуации или сравнить потом смещения и размеры блоков.
Зануление делается использованием функции заполнить секторы. Надо очень внимательно смотреть что зануляется потому как можно и лишнее обнулить и, что может быть особенно печальным - занулить что то на диске не относящемся к массиву.
После зануления желательно перезагрузить систему или хотя бы обновить оснастку в управлении дисков винды.

9285 · 13.05.2019, 13:51

3. Создание нового массива.
Заходишь в управление дисков винды и инициализируешь оба диска-участника как MBR.
Следующий момент очень критичен и важно не ошибиться с выбором "начального" диска. Насколько заметил, DMDE правильно отображает номерацию дисков и, если исходить из начальных скриншотов, в твоём случае начальным будет disk1. На всякий случай проверяешь на каком диске бывший том с началом в секторе 2048 и с индикаторами Bxxf
На моих скриншотах номерация другая, поэтому показываю как есть а ты там уже учитывай свою номерацию.

Итак, выделяем на начальном диске нераспределённую область и в контекстном меню выбираем создание чередующегося тома. В последующем окне проверяем что в правой части нужный диск; после чего добавляем второй и создаём том. Букву пока назначать не надо. И ещё очень важный момент - диск ни в коем случае не надо форматировать.

9285 · 13.05.2019, 13:54

Будет сообщение о преобразовании диска в динамические - соглашаешься.
Если всё сделал правильно, то в управлении дисков появится массив а том будет иметь состояние RAW.
Для контроля что всё сделано правильно - открой в DMDE диск на котором ранее был "раздел" data и убедись что теперь его нет. На самом деле том на месте, но у него просто нет бутсектора, а в секторе 2049 и далее можно увидеть содержимое кода загрузчика.

9285 · 13.05.2019, 14:17

4. "Восстановление" прежнего тома.
Теоретически, если всё сделал правильно, можно назначить букву тому и запустить чекдиск.Он должен увидеть что нет бутсектора и восстановить его из копии. Но лучше не надеятся на него и сделать по ранее озвученному принципу.

Тем более что в "ручном" режиме ты сможешь проверить правильность действий и наличие структуры данных.
Т.к. винда будет блокировать запись в бутсектор, надо сделать как ранее MBRoff на обоих дисках, применить изменения и перезагрузить систему.
После этого открыть начальный диск и записать ранее сохранённый дамп бутсектора на его бывшее место (в сектор 2048). Это делается по аналогии сохранения дампа, только источник и приёмник меняются местами. И тут важно, в месте для записи, указать нужный номер сектора. Для тех кто может зевнуть и не проверить номер сектора рекомендую сначала перейти в требуемый сектор; во первых - будет видно что там 00, а главное - при выполнении записи номер сектора должен подставится сам (но лучше проконтролировать).
После записи бутсектора, можно собрать массив как было написано вчера, открыть том и проверить что всё на месте.
Если всё нормально, делаем MBRonn на обоих дисках, применяем изменения и перерезагружаем систему.
После перезагрузки, в диспетчере дисков винды назначаем букву тома и проверяем том чекдиском в режиме только чтения - нельзя исключать что были какие то ошибки - ведь не просто так том слетел после перезагрузки. Если ошибки есть - смотрим какие и определяем что делать дальше. Если нет - ~~открываешь шампанское и пьёшь его~~ значит всё сделано правильно..

PS. В принципе можно сделать контрольные суммы данных на восстановленном томе и сравнить с теми куда ты ранее восстановил. Это чтобы понять есть ли ошибки восстановления и в чём они.
PPS. Если что непонятно - лучше спроси. Если вдруг ошибёшься с выбором начального диска - не страшно, надо будет повторить всё с начала, но "поменять" диск. Главное - по ошибке не затронуть какой то другой диск (не участник) массива.

9285 · 13.05.2019, 14:24

Совет
обычно "полосатики" используют для ускорения работы с диском. Не уверен что таковое имеется на сделанном таким образом, но вот проблем он может создать немало.
В случае того же составного тома (в котором идёт сначала блок с одного диска а потом с другого), в случае разрушения массива или гибели одного из дисков, есть шанс на то. что можно восстановить файлы целиком с жиого.
В случае "полосатика" такое возможно лишь для файлов. которые вместились в размер блока (в твоём случае - 64 кб).
Не думаю что это правильный выбор и советую лишний раз задуматься прежде чем связываться с такими конструкциями.

vladimir87 · 13.05.2019, 23:12

Цитата (9285) »

надо сделать каждому их этих дисков MBR off, применить изменение разметки и перезагрузить систему.
После этого занулить 2048 секторов от начала диска (0-2047) - на скриншоте показано как делается зануление для начала диска; и столько же - от конца. Применительно к MBR разметке, можно найти в конце диска сектор в начале которого записано TOCKBLOCK (это и есть начало базы LDM) - и затереть сектора начиная с него и до конца диска.

Занулять надо начало и конец одного диска или обоих?

vladimir87 · 13.05.2019, 23:19

Ты указал что надо сделать MBRoff, ничего что у меня GPToff?

9285 · 13.05.2019, 23:47

Занулять на обоих.
Да, в твоём случае - GPToff, и это первый раз.
Кстати, не очень понятно откуда взялась GPT. Можно предположить что это 10-ка сделала при преобразовании, но как то нелогична смена стиля разметки.

vladimir87 · 16.05.2019, 21:22

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

Сделал я все что ты написал и честно говоря даже не удивился что все получилось! Все данные на месте, том собрался без проблем!

Еще раз от всей души благодарю за помощь в решении моей проблемы, моя вера в человечество восстала из пепла и я с радостью плюсую тебе в карму миллион очков!

9285 · 17.05.2019, 01:23

Ок!
Продолжишь ты работать с "полосатиком" или нет - в любом случаев рекомендую делать некоторую профилактику файловой системы.
Если посмотришь лог полного сканирования. то можешь увидеть огромное число фрагментов MFT которые не относятся к текущей. И когда я первый раз смотрел лог, и считал что у тебя составной том, то всё это выглядело как помойка и не внушало оптимизма. Из того что мне известно - дефрагментатор Vopt умеет заполнять неиспользованное пространство, хотя с ходу не скажу чем он заполняет (а главное поддерживает ли он микрософтовские новоделы). Поэтому практикую более простой способ, который гарантированно заполняет почти всё свободное место 0-мя.

СПОЙЛЕР »

В винде есть штатная утилита, которая позволяет создать файл-пустышку заданного размера. В дальнейшем эту пустышку можно открыть в DMDE как образ, прописать 00-ми а затем удалить. Можешь проверить на этом массиве и сравнить логи полного скана до и после.
Применительно к диску D команда выглядит примерно так
fsutil file createnew d:\fill.bin 561566973952
Название файла можешь выбрать сам, расширение такое чтобы в DMDE он сразу был виден при выборе файла-образа. Что касается размера, то исходил из размера пустого места на разделе с умножением 561566973952=523*1024*1024
По факту можешь "забить" диск несколькими фалами исходя из свободного места.

12.05.2019, 09:51	[включить плавающее окно] Вверх #25
vladimir87 Новенький Автор темы Регистрация: 06.05.2019	Насколько я помню бирюзовый Изображения

12.05.2019, 10:06	[включить плавающее окно] Вверх #26
9285 Умудрённый Регистрация: 08.02.2019 Адрес: https://t.me/help9285	Когда вчера смотрел логи уже думал написать что ситуация швак, потому как в дампах не было нужного и в огромнейшем числе блоков не отслеживалась необходимая структура. Но в таких случаях не стоит торопиться с выводами, потому как всякое бывает - и это подтвердилось. Просмотр логов при разных сортировках позволил заметить чётко чередующиеся блоки по 64 записи, расположенных в секторах со значением в 2 раза меньше прописанного в 0-вой секторе. И стало понятно что у тебя ~~не закрытый перелом а открытый~~ использовался чередующийся том, у которого как раз бирюзовый цвет. Так что, со зрительной памятью у тебя всё нормально. Добавлено через 12 минут С таковым не доводилось сталкиваться ранее, поэтому не знал их устройство, и как оказалось, она имеет свою специфику, которая пока не понятна до конца. И это не позволяет сделать сборку массива для проверки - точнее можно собрать "начало", а вот с остальной частью пока не понятно (есть какое то смещение). В данной ситуации можно попробовать воспользоваться функционалом автоматического определения RAID - такая функция есть в DMDE (насколько знаю - в R-studio). Если что - размер блока 64кб. Последний раз редактировалось 9285; 12.05.2019 в 14:28.

12.05.2019, 17:05	[включить плавающее окно] Вверх #27
9285 Умудрённый Регистрация: 08.02.2019 Адрес: https://t.me/help9285	До сих пор не смог понять откуда берётся смещение для в районе начала второго фрагмента, имеющееся и в смоделированной ситуации - но при этом прекрасно работает вполне логичная сборка массива. Можешь и сам попробовать собрать и проверить. На скриншоте изображено как собрать массив в DMDE. Сначала указываешь тип массива и размер блока. Потом плюсиком (отмечено зелёным) последовательно добавляешь два физических диска - первым тот, на котором есть том с меткой data. Далее меняешь параметры (выделено оранжевым) каждого из диска - при данном типе массива достаточно сменить только стартовый сектор. После этого можешь открыть найденный том и посмотреть что в нём, восстановить на другой носитель и проверить какие то файлы. Миниатюры

13.05.2019, 10:57	[включить плавающее окно] Вверх #31
9285 Умудрённый Регистрация: 08.02.2019 Адрес: https://t.me/help9285	В виду того, что написать надо не так уж мало - буду писать по частям. Вступление Технически, можно попробовать разобраться с самими записями LDM и что в них не так. Основная проблема в том, что нет достоверной (100% ной) информации о том, как устроено всё это. Разобраны основные моменты, но некоторые вещи до сих пор являются белым пятном. и может оказаться что какой то байтик в белом пятне и является критичным. Поэтому делается заход с другой стороны - смоделировать ситуацию создания массива при которой будет создана новая LDM. И тут самый главный момент - точность создания массива. Особенно это очень актуально для составных томов. состоящих из нескольких фрагментов (в том числе на одном диске). Хотя и в такой ситуации у меня получилось создать массив а потом скорректировать его записи в части размеров блоков и их позиции в самом массиве. В случае с "полосатиком" эта точность не критична, зато очень критично организовать само чередование - то есть какой из дисков будет начальным. Сразу небольшое предупреждение. У тебя используется новодел (10ка) и по скриншоту видно что она проинициализировала диски как то по своемому. Я не исключаю что и само создание массивов у неё отличается, но нет никакого желания ставить это д...мо и проверять так ли это. Поэтому надежда на то, что часть кода, отвечающую за создание массивов не затронули. Вывод - для создания массива лучше всего использовать ту систему, под которой он формировался изначально. В случае если это не принципиально важно. я в своих "экспериментах" использую "старушку" win7 поэтому всё написанное далее относится к ней. В описании дальше предполагается что на массиве создаётся один логический диск, в случае с большим числом дисков вряд ли что то меняется, тем не менее лучше это уточнить. 1. Если дальнейшая сборка будет сделана правильно, то винда обнулит бустектор бывшего тома. И хотя можно будет найти копию такового, нельзя не исключать что её может не оказаться. Поэтому лучше сразу зарезервировать её. В твоём случае это содержимое сектора 2048 на диске, где есть раздел data. В случае чередующегося тома, при неправильном задании начального диска обнулится такой же сектор другого диска, поэтому для подстраховки не помешает создать дамп этого сектора и с другого диска. СПОЙЛЕР » В моделировании ситуации именно такое и произошло. Как выяснилось. в том секторе находился метафайл $Upcase и последующая поверка чекдиском не нашла ошибки в нём, хотя вполне очевидно что какая то его часть была обнулена. 2. Подготовительный этап. Его задача - избавится от старой базы LDM. В случае MBR разметки диска, как писал выше - эти данные записаны в конце каждого диска + приватный заголовок (PRIVHEAD) есть в начале диска. Конкретный данные массива можно уточнить в ранее указанных блоках VBLK, но в твоём (типичном для современных win случае) части массива начинаются в секторе 2048 () и их размер определён в тех же записях, но не далее примерно 2048 -го сектора от конца каждого из дисков. В принципе, можно использовать команду clean (без дополнительных ключей0 из diskpart, которая очищает искомые сектора, но я не могу гарантировать что это будет сделано именно так и особенно применительно к ситуации когда ещё актуален старый массив (у тебя то его уже нет). СПОЙЛЕР » В одном из экспериментов лишил том буквы и в в таком состоянии сделал clean на каждом из дисков массива - очистилось бОльшее количество секторов. . Поэтому, как говорится "Хочешь сделать хорошо - сделай сам". Для начала, чтобы исключить работу винды с дисками-участниками (особенно если речь идёт о актуальном массиве) надо сделать каждому их этих дисков MBR off, применить изменение разметки и перезагрузить систему. После этого занулить 2048 секторов от начала диска (0-2047) - на скриншоте показано как делается зануление для начала диска; и столько же - от конца. Применительно к MBR разметке, можно найти в конце диска сектор в начале которого записано TOCKBLOCK (это и есть начало базы LDM) - и затереть сектора начиная с него и до конца диска. И, несомненно, перед занулением секторов можно сохранить их содержимое - это если захочется проанализировать ситуации или сравнить потом смещения и размеры блоков. Зануление делается использованием функции заполнить секторы. Надо очень внимательно смотреть что зануляется* потому как можно и лишнее обнулить и, что может быть особенно печальным - занулить что то на диске не относящемся к массиву. После зануления желательно перезагрузить систему или хотя бы обновить оснастку в управлении дисков винды. Миниатюры Последний раз редактировалось 9285; 13.05.2019 в 13:46.

13.05.2019, 13:51	[включить плавающее окно] Вверх #32
9285 Умудрённый Регистрация: 08.02.2019 Адрес: https://t.me/help9285	3. Создание нового массива. Заходишь в управление дисков винды и инициализируешь оба диска-участника как MBR. Следующий момент очень критичен и важно не ошибиться с выбором "начального" диска. Насколько заметил, DMDE правильно отображает номерацию дисков и, если исходить из начальных скриншотов, в твоём случае начальным будет disk1. На всякий случай проверяешь на каком диске бывший том с началом в секторе 2048 и с индикаторами Bxxf На моих скриншотах номерация другая, поэтому показываю как есть а ты там уже учитывай свою номерацию. Итак, выделяем на начальном диске нераспределённую область и в контекстном меню выбираем создание чередующегося тома. В последующем окне проверяем что в правой части нужный диск; после чего добавляем второй и создаём том. Букву пока назначать не надо. И ещё очень важный момент - диск ни в коем случае не надо форматировать. Миниатюры

10.05.2019, 19:40	[включить плавающее окно] Вверх #21
9285 Умудрённый Регистрация: 08.02.2019 Адрес: https://t.me/help9285	В секторах, где ожидались записи MFT нет ничего подобного. Не хочется думать о печальном, поэтому надо посмотреть что в этих же секторах на другом диске - возможно он является начальным. А можно и не смотреть а приступить к полному сканированию (с учётом написанного ранее). в процессе скана делай промежуточные сохранения лога - и можешь выложить (в запакованном виде) таковой когда просканируется примерно 7000000 секторов.

11.05.2019, 13:18	[включить плавающее окно] Вверх #23
vladimir87 Новенький Автор темы Регистрация: 06.05.2019	Логи сюда не влезают, поэтому скинул на гугл диск. https://drive.google.com/open?id=1E1...Ydvf8LYf0uPGhE

11.05.2019, 20:55	[включить плавающее окно] Вверх #24
9285 Умудрённый Регистрация: 08.02.2019 Адрес: https://t.me/help9285	vladimir87 Ок. Ситуация немного проясняется, но ещё не окончательно. Выясняется что с памятью у тебя склероз, надеюсь что зрение в порядке. Каким цветом были окрашены тома в диспетчере дисков винды?

12.05.2019, 22:30	[включить плавающее окно] Вверх #28
vladimir87 Новенький Автор темы Регистрация: 06.05.2019	Цитата (9285) » Можешь и сам попробовать собрать и проверить. На скриншоте изображено как собрать массив в DMDE. Сработало! Собрался RAID, данные на месте! Осталось их только восстановить на другие диски! Огромное тебе спасибо, как я могу тебя отблагодарить за помощь!?

12.05.2019, 22:45	[включить плавающее окно] Вверх #29
9285 Умудрённый Регистрация: 08.02.2019 Адрес: https://t.me/help9285	Отлично. Насколько понимаю, после восстановления ты будешь что то делать с обоими дисками (переразбивать, форматировать и т.п.) В качестве благодарности могу предложить тебе сделать восстановление массива по месту - в конце концов, если не получится, то терять то нечего. Метода восстановления по месту составных томов уже проверена, с чередующимися ещё не пробовал, хотя думаю что всё аналогично. Но одно дело делать это в смоделированной ситуации - совсем другое в реальности.

13.05.2019, 08:23	[включить плавающее окно] Вверх #30
vladimir87 Новенький Автор темы Регистрация: 06.05.2019	Не вопрос, давай проверим, к вечеру думаю R-studio закончит копирование на новые диски, и можно будет поэкспериментировать.

13.05.2019, 13:54	[включить плавающее окно] Вверх #33
9285 Умудрённый Регистрация: 08.02.2019 Адрес: https://t.me/help9285	Будет сообщение о преобразовании диска в динамические - соглашаешься. Если всё сделал правильно, то в управлении дисков появится массив а том будет иметь состояние RAW. Для контроля что всё сделано правильно - открой в DMDE диск на котором ранее был "раздел" data и убедись что теперь его нет. На самом деле том на месте, но у него просто нет бутсектора, а в секторе 2049 и далее можно увидеть содержимое кода загрузчика. Миниатюры Последний раз редактировалось 9285; 13.05.2019 в 17:47.

13.05.2019, 14:17	[включить плавающее окно] Вверх #34
9285 Умудрённый Регистрация: 08.02.2019 Адрес: https://t.me/help9285	4. "Восстановление" прежнего тома. Теоретически, если всё сделал правильно, можно назначить букву тому и запустить чекдиск.Он должен увидеть что нет бутсектора и восстановить его из копии. Но лучше не надеятся на него и сделать по ранее озвученному принципу. Тем более что в "ручном" режиме ты сможешь проверить правильность действий и наличие структуры данных. Т.к. винда будет блокировать запись в бутсектор, надо сделать как ранее MBRoff на обоих дисках, применить изменения и перезагрузить систему. После этого открыть начальный диск и записать ранее сохранённый дамп бутсектора на его бывшее место (в сектор 2048). Это делается по аналогии сохранения дампа, только источник и приёмник меняются местами. И тут важно, в месте для записи, указать нужный номер сектора. Для тех кто может зевнуть и не проверить номер сектора рекомендую сначала перейти в требуемый сектор; во первых - будет видно что там 00, а главное - при выполнении записи номер сектора должен подставится сам (но лучше проконтролировать). После записи бутсектора, можно собрать массив как было написано вчера, открыть том и проверить что всё на месте. Если всё нормально, делаем MBRonn на обоих дисках, применяем изменения и перерезагружаем систему. После перезагрузки, в диспетчере дисков винды назначаем букву тома и проверяем том чекдиском в режиме только чтения - нельзя исключать что были какие то ошибки - ведь не просто так том слетел после перезагрузки. Если ошибки есть - смотрим какие и определяем что делать дальше. Если нет - ~~открываешь шампанское и пьёшь его~~ значит всё сделано правильно.. PS. В принципе можно сделать контрольные суммы данных на восстановленном томе и сравнить с теми куда ты ранее восстановил. Это чтобы понять есть ли ошибки восстановления и в чём они. PPS. Если что непонятно - лучше спроси. Если вдруг ошибёшься с выбором начального диска - не страшно, надо будет повторить всё с начала, но "поменять" диск. Главное - по ошибке не затронуть какой то другой диск (не участник) массива. Миниатюры Последний раз редактировалось 9285; 13.05.2019 в 17:45.

13.05.2019, 14:24	[включить плавающее окно] Вверх #35
9285 Умудрённый Регистрация: 08.02.2019 Адрес: https://t.me/help9285	Совет обычно "полосатики" используют для ускорения работы с диском. Не уверен что таковое имеется на сделанном таким образом, но вот проблем он может создать немало. В случае того же составного тома (в котором идёт сначала блок с одного диска а потом с другого), в случае разрушения массива или гибели одного из дисков, есть шанс на то. что можно восстановить файлы целиком с жиого. В случае "полосатика" такое возможно лишь для файлов. которые вместились в размер блока (в твоём случае - 64 кб). Не думаю что это правильный выбор и советую лишний раз задуматься прежде чем связываться с такими конструкциями.

13.05.2019, 23:12	[включить плавающее окно] Вверх #36
vladimir87 Новенький Автор темы Регистрация: 06.05.2019	Цитата (9285) » надо сделать каждому их этих дисков MBR off, применить изменение разметки и перезагрузить систему. После этого занулить 2048 секторов от начала диска (0-2047) - на скриншоте показано как делается зануление для начала диска; и столько же - от конца. Применительно к MBR разметке, можно найти в конце диска сектор в начале которого записано TOCKBLOCK (это и есть начало базы LDM) - и затереть сектора начиная с него и до конца диска. Занулять надо начало и конец одного диска или обоих?

13.05.2019, 23:19	[включить плавающее окно] Вверх #37
vladimir87 Новенький Автор темы Регистрация: 06.05.2019	Ты указал что надо сделать MBRoff, ничего что у меня GPToff? Миниатюры

13.05.2019, 23:47	[включить плавающее окно] Вверх #38
9285 Умудрённый Регистрация: 08.02.2019 Адрес: https://t.me/help9285	Занулять на обоих. Да, в твоём случае - GPToff, и это первый раз. Кстати, не очень понятно откуда взялась GPT. Можно предположить что это 10-ка сделала при преобразовании, но как то нелогична смена стиля разметки.

16.05.2019, 21:22	[включить плавающее окно] Вверх #39
vladimir87 Новенький Автор темы Регистрация: 06.05.2019	Привет, извини за задержку с отчетом, много работы с понедельника навалилось. Сделал я все что ты написал и честно говоря даже не удивился что все получилось! Все данные на месте, том собрался без проблем! Еще раз от всей души благодарю за помощь в решении моей проблемы, моя вера в человечество восстала из пепла и я с радостью плюсую тебе в карму миллион очков! Миниатюры

17.05.2019, 01:23	[включить плавающее окно] Вверх #40
9285 Умудрённый Регистрация: 08.02.2019 Адрес: https://t.me/help9285	Ок! Продолжишь ты работать с "полосатиком" или нет - в любом случаев рекомендую делать некоторую профилактику файловой системы. Если посмотришь лог полного сканирования. то можешь увидеть огромное число фрагментов MFT которые не относятся к текущей. И когда я первый раз смотрел лог, и считал что у тебя составной том, то всё это выглядело как помойка и не внушало оптимизма. Из того что мне известно - дефрагментатор Vopt умеет заполнять неиспользованное пространство, хотя с ходу не скажу чем он заполняет (а главное поддерживает ли он микрософтовские новоделы). Поэтому практикую более простой способ, который гарантированно заполняет почти всё свободное место 0-мя. СПОЙЛЕР » В винде есть штатная утилита, которая позволяет создать файл-пустышку заданного размера. В дальнейшем эту пустышку можно открыть в DMDE как образ, прописать 00-ми а затем удалить. Можешь проверить на этом массиве и сравнить логи полного скана до и после. Применительно к диску D команда выглядит примерно так fsutil file createnew d:\fill.bin 561566973952 Название файла можешь выбрать сам, расширение такое чтобы в DMDE он сразу был виден при выборе файла-образа. Что касается размера, то исходил из размера пустого места на разделе с умножением 561566973952=52310241024 По факту можешь "забить" диск несколькими фалами исходя из свободного места.