Программа для диагностики жёстких дисков R.tester

Бесплатная программа для восстановления файлов R.saver

Неофициальный блог R.LAB, заходите!

Восстановление данных
восстановление данных
Звоните нам в Москве: +7(495) 230−1000
04.07.2020, 08:18:38 *
Добро Пожаловать, гость. Пожалуйста войдите или зарегистрируйтесь, если хотите стать полноправным участником форума. Не получили активационное письмо?

Страницы: [1]
  Печать  
автор Тема: Восстановление данных из удаленного VMDK, с физического диска (ESXi 5.5)  (прочитано 1002 раз)
tormozok
Newbie
*

Репутация: 0
сообщений: 1


просмотр профиля
« было: 09.12.2017, 06:14:38 »

Доброго времени суток всем!
Начну с истории: В datastores сервера (ESXi 5.5) добавлен винчестер (WD15EARX 1.5Tb). Файловая система VMFS 5.6 на весь физический диск (создал ESXi 5.5). На все доступное место создан один VMDK с файловой системой UFS (создала FreeBSD 6.4, не системный). VMDK добавлен к существующей в системе виртуальной машине для сброса данных. После сброса всех необходимых данных виртуальная машина была благополучно удалена методом Delete from Disk. VMDK описанный выше не был отключен, как следствие тоже был удален.

Клонировали диск для опытов. Прошлись разными программами... результаты неудовлетворительные.

Перешли к работе с байтами напрямую:

1. WinHex - видит на диске GPT раздел на весь физический диск
2. поиск по фразе "Boot  error" - дал четыре попадания
3. только две записи содержат выше MBR блок

Незадача в том, что они не содержат разметки:

Offset       0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

77335A6800   FC 31 C0 8E C0 8E D8 8E  D0 BC 00 7C 89 E6 BF 00   ü1ÀŽÀŽØŽÐ¼ |‰æ¿
77335A6810   06 B9 00 01 F3 A5 89 FD  B1 08 F3 AB FE 45 F2 E9    ¹  ó¥‰ý± ó«þEòé
77335A6820   00 8A A1 E3 00 E8 18 01  F6 46 BB 20 75 08 84 D2    Š¡ã è  öF» u „Ò
..................
77335A6960   53 6A 01 6A 10 89 E6 48  80 CC 40 CD 13 89 FC 5E   Sj j ‰æH€Ì@Í ‰ü^
77335A6970   C3 20 20 A0 0A 44 65 66  61 75 6C 74 3A A0 0D 8A   Ã    Default:  Š
77335A6980   00 05 0F 01 06 07 0B 0C  0E 83 9F A5 A6 A9 0E 0D            ƒŸ¥¦© 
77335A6990   0C 0B 0A 09 0B 13 0E 11  10 01 3F BF 44 4F D3 4C             ?¿DOÓL
77335A69A0   69 6E 75 F8 46 72 65 65  42 53 C4 90 90 90 90 90   inuøFreeBSÄ     
77335A69B0   66 BB 44 72 69 76 65 20  00 00 80 8F B6 00 00 00   f»Drive   € ¶   
77335A69C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
77335A69D0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
77335A69E0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
77335A69F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 AA                 Uª

4. сравниваем с налитой отдельно осью под ESXi и без него
5. ...курим вики по MBR...
6. пишем ссылку на партицию руками:

И тут вторая незадача:

Везде, где бы мы не ставили FreeBSD и какую бы мы версию не ставили - BSD всегда пишет свой загрузчик в "FE00".
У нас же он лежит на "С00", а по "FE00" - каша полнейшая.

80 01 01 00 A5 3F FF FF 00 0C  00 00 FC CD 0E 73

7. ...нас видимо кто то проклял... смотрим загрузчик BSD и сравниваем с рабочим:

Offset       0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

77335A7400   EB 3C 00 00 00 00 00 00  00 00 00 00 02 00 00 00   л<             
77335A7410   00 00 00 00 00 00 00 00  12 00 02 00 00 00 00 00                   
77335A7420   00 00 00 00 00 16 1F 66  6A 00 51 50 06 53 31 C0          fj QP S1А
77335A7430   88 F0 50 6A 10 89 E5 E8  C0 00 8D 66 10 CB FC 31   €рPj ‰еиА  f Ль1
.............
77335A7590   46 0A D0 E3 00 5E 05 28  46 02 77 88 C3 52 65 61   F Рг ^ (F w€ГRea
77335A75A0   64 00 42 6F 6F 74 00 20  65 72 72 6F 72 0D 0A 00   d Boot  error   
77335A75B0   80 90 90 90 90 90 90 90  90 90 90 90 90 90 00 00   Ђ               
77335A75C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
77335A75D0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
77335A75E0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 80 00                 Ђ
77335A75F0   01 00 A5 FE FF FF 00 00  00 00 50 C3 00 00 55 AA     Ґюяя    PГ  UЄ
77335A7600   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
77335A7610   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
77335A7620   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
77335A7630   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
77335A7640   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
77335A7650   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
77335A7660   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
77335A7670   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
77335A7680   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
77335A7690   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
77335A76A0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
77335A76B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
77335A76C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
77335A76D0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
77335A76E0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
77335A76F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
77335A7700   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
77335A7710   00 00 00 00 EB 0E 42 54  58 01 01 80 F6 0F 80 07       л BTX  Ђц Ђ
77335A7720   00 20 00 00 FA 31 C0 8E  D0 BC 00 18 8E C0 8E D8       ъ1АЋРј  ЋАЋШ
77335A7730   66 6A 02 66 9D BF 00 1E  B9 00 39 57 F3 AB 5F BE   fj f ї  № 9Wу«_ѕ
77335A7740   E2 96 AC 98 91 E3 1D AC  92 AD 93 AD B6 08 D1 EB   в–¬?‘г ¬’­“­¶ Сл

Напрочь отсутствует хоть какая нибудь запись о слайсах "7600 - 7700"

И вот тут на данный момент непробиваемая стена:

Слайс начинается на рабочем диске с "FC00", но как его найти на диске со сдвигом, если данные в нем

Offset       0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00000FС00   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
00000FС10   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
00000FС20   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
00000FС30   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
00000FС40   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
00000FС50   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   

Будем рады любым мыслям...
Авторизирован
Fader
RAID EXPERT
Global Moderator
Hero Member
*

Репутация: 30
сообщений: 1097



просмотр профиля
« Ответить #1 было: 09.12.2017, 17:05:51 »

Если файл VMDK был удален с VMFS раздела, то толку от этих "приседаний" особо не будет. Все метаданные на разделах ВМФС хранятся в одном экземпляре.  Машины сильно фрагментированы. Так что, скорее всего, здесь уже ничего сделать не удастся. Хотя, попробовать можно.
Мы за такую работу взяться можем, но результат не гарантирован. Если дадите удаленный доступ к датастору через винду с 9-ой версией ТимВьювера, то можем попробовать глянуть. Реквизиты Тима можно кинуть на мыло v@rlab.ru
Авторизирован

RAID RECOVERY EXPERT
Страницы: [1]
  Печать  
 
Перейти в раздел:  

Яндекс.Метрика
Восстановление данных - R.LAB
Москва, Коровий Вал, д. 1А  (схема проезда). Телефон: +7 (495) 230−1000; e-mail: 
Другие города »