Фон
Я вставил диск на 2 ТБ в какой-то корпус Sata-to-USB3.0 и скопировал на него 1 ТБ данных. Это был диск 2,5 5300 об/мин, так что это заняло около 20 часов. Я один из параноиков, поэтому перед тем, как скопировать данные, я использовал TotalCommander, чтобы сделать контрольные суммы sha256 всего, что я хотел скопировать, затем я запустил проверку скопированных данных на новом USB-накопителе. Я использовал два других куска того же корпуса для двух других дисков, правда, на 1 ТБ. Никогда не было никаких проблем.
Проблема
Во время проверки контрольных сумм я заметил уведомление в центре действий Windows 10 с красным значком «X», в котором говорилось, что нужно проверить файловую систему. Не было указано, какое именно, но я все равно нажал на него. Ничего не произошло, поэтому я запустил EventViewer, чтобы посмотреть, что произошло. Я увидел три события EventID 55, относящихся к ошибкам на моем новом томе, одно из них говорило, что „:$I30:$INDEX_ALLOCATION”он поврежден, два других говорили, что поврежденный файл — <can't determine file name>. Я остановил все операции на томе и запустил chkdsk /Fего, но поскольку он пожаловался, что к диску обращается какое-то другое программное обеспечение, я удалил букву диска с помощью утилиты Disk Management. Когда я снова планировал добавить букву, чтобы chkdsk восстановил его, я внезапно увидел, что все параметры стали серыми, а раздел отображался как Healthy (GPT Protective Partition). Это тип EEhсогласноэта статья в Википедии.
Диск никогда не был GPT. Я все еще вижу опцию, Convert to GPT diskкогда щелкну правой кнопкой мыши по нему в инструменте управления дисками. Ниже приведен вывод DETAIL DISKи DETAIL PARTITIONкоманды DISKPART:
DISKPART> detail disk
ST2000LM003 HN-M201RAD
Disk ID: 08686B3E
Type : RAID
Status : Online
Path : 2
Target : 0
LUN ID : 0
Location Path : PCIROOT(0)#PCI(1700)#RAID(P02T00L00)
Current Read-only State : No
Read-only : No
Boot Disk : No
Pagefile Disk : No
Hibernation File Disk : No
Crashdump Disk : No
Clustered Disk : No
There are no volumes.
DISKPART> detail partition
Partition 1
Type : EE
Hidden: Yes
Active: No
Offset in Bytes: 512
There is no volume associated with this partition.
Этот диск не является частью какого-либо рейда, вопреки тому, что отображается, в настоящее время он подключен к порту SATA непосредственно на материнской плате, возможно, он отображается как тип RAID, потому что контроллер находится в режиме RAID.
Что ядуматьпроизошло (у меня нет возможности это проверить), так это то, что chkdsk пытался восстановить том в фоновом режиме, когда я щелкнул это уведомление в центре действий, он, должно быть, установил идентификатор раздела на EEh, вероятно, с намерением сбросить его обратно, когда он закончит. Когда я установил букву диска на none, он, должно быть, выдал ошибку и оставил все как есть.
Что я пробовал
Я думал использовать команду SETID DISKPART, чтобы указать тип раздела 07, однако это не работает:
DISKPART> set id=07
DiskPart has encountered an error: The parameter is incorrect.
See the System Event Log for more information.
В журнал событий не записываются никакие сообщения, он просто не работает.
Я думаю, что восстановление этого раздела в том виде, в котором он был, приведет к восстановлению доступа к файлам, и поскольку у меня есть еще один такой диск, который был отформатирован таким же образом, я убежден, что установка идентификатора раздела на 07h сработает, только я, похоже, не могу этого сделать. Ниже приведены данные с моего другого такого же жесткого диска.
DISKPART> detail disk
ST2000LM 003 HN-M201RAD SCSI Disk Device
Disk ID: BB31CF75
Type : USB
Status : Online
Path : 0
Target : 0
LUN ID : 0
Location Path : UNAVAILABLE
Current Read-only State : No
Read-only : No
Boot Disk : No
Pagefile Disk : No
Hibernation File Disk : No
Crashdump Disk : No
Clustered Disk : No
Volume ### Ltr Label Fs Type Size Status Info
---------- --- ----------- ----- ---------- ------- --------- --------
* Volume 4 E SMSNG1 NTFS Partition 1863 GB Healthy
DISKPART> detail partition
Partition 1
Type : 07
Hidden: No
Active: No
Offset in Bytes: 1048576
Volume ### Ltr Label Fs Type Size Status Info
---------- --- ----------- ----- ---------- ------- --------- --------
* Volume 4 E SMSNG1 NTFS Partition 1863 GB Healthy
DISKPART>
Если у кого-то есть опыт в подобной ситуации, поделитесь своим мнением. Я не буду трогать диск некоторое время, потому что хочу попрактиковаться в восстановлении после этой ситуации. После восстановления я проверю контрольные суммы файлов и попытаюсь возложить вину за повреждение, вызвавшее срабатывание chkdsk, либо на диск, либо на USB-мост.
EDIT - данные привода
--------------- SeaTools for Windows v1.4.0.5 ---------------
2017-08-30 20:37:53
Model Number: 003 HN-M201RAD
Serial Number: S377J9GGA02406
Firmware Revision: 2BE1
Identify - Started 2017-08-30 20:37:53
Model Number: 003 HN-M201RAD
Serial Number: S377J9GGA02406
Firmware Revision: 2BE1
Drive Capacity: 2,00 TB / 1,82 TiB
Max LBA: 3907029167
Cache Size: ----
Lifetime Bytes Read: 3,54 GB
Lifetime Bytes Written: 545,50 MB
Power-On Hours: 4255
Annualized Workload Rate [ (Writes + Reads) * (8760 / POH) ]: 0 TB/yr
Drive Temperature (C/F): 29 / 84
WWN: 50004CF210CD3B3B
Sector size (Logical/Physical/Allignment): 512 / 4096 / 0
Signal Speed (Max/Negotiated): 6.0 / 6.0 Gb/s
Transport Supported: SATA 3.0
Rotation rate: 5400 RPM
Form factor: 2.5 inch
Specification Supported: ATA8-ACS
Encryption Support: Not Supported
Security Mode: Supported, Frozen
SMART: Enabled
Host Protected Area features: Enabled
Advanced Power Management: Enabled
Download Microcode: Segmented
EDIT2 - сектора 0, 7 и 8
решение1
Поскольку диск меньше 2 ТБ, я бы остановился на MBR и избежал бы хлопот с созданием GPT и возни со всеми контрольными суммами, но вместо этого изменил бы последние 64 байта сектора 0 с
0000000000432 | 00 00 00 00 00 00 00 00 3E 6B 68 08 04 D0 00 00 |
0000000000448 | 02 00 EE FE 7F FF 01 00 00 00 FF FF FF FF 00 00 |
0000000000464 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |
0000000000480 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |
0000000000496 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA |
к
0000000000432 | 00 00 00 00 00 00 00 00 3E 6B 68 08 04 D0 00 00 |
0000000000448 | 02 00 07 FE 7F FF 00 08 00 00 00 80 E0 E8 00 00 |
0000000000464 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |
0000000000480 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |
0000000000496 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA |
Это должно делать свое дело.
Я действительно не знаю, почему заголовок GPT находится в секторе 7, а таблица — в секторе 8, это должны быть либо секторы 7, либо 15.или1 и 2...