fundo
Coloquei uma unidade de 2 TB em um gabinete Sata-para-USB3.0 e copiei 1 TB de dados para ele. Era 2,5 5300rpm, e levou quase 20 horas. Como sou um dos tipos paranóicos, antes de copiar os dados, usei o TotalCommander para criar somas de verificação sha256 de tudo o que queria copiar e, em seguida, verifiquei os dados copiados na nova unidade USB. Eu usei duas outras peças do mesmo gabinete para outros dois discos, embora 1 TB. Nunca tive nenhum problema.
Problema
Ao verificar as somas de verificação, observei uma notificação no centro de ação do Windows 10 com um "X" vermelho, que me dizia para verificar meu sistema de arquivos. Não mostrou qual, mas cliquei de qualquer maneira. Nada aconteceu, então eu corri o eventviewer para ver o que aconteceu. Eu vi três eventos EventID 55 referentes a erros no meu novo volume, um deles dizendo que „:$I30:$INDEX_ALLOCATION”
está corrompido, outros dois disseram que o arquivo está corrompido <can't determine file name>
. Parei todas as operações no volume e o executei chkdsk /F
, mas, como reclamou que algum outro software está acessando o disco, removi uma letra de unidade usando o utilitário de gerenciamento de disco. Quando planejei adicionar uma carta novamente para fazer com que o chkdsk a reparasse, de repente vi todas as opções acinzentadas e a partição foi exibida como Healthy (GPT Protective Partition)
. Este é o tipo de EEh
acordo com este artigo da Wikipedia .
O disco nunca foi GPT. Ainda vejo uma opção Convert to GPT disk
ao clicar com o botão direito do mouse na ferramenta Gerenciamento de Disco. Abaixo está uma saída DETAIL DISK
e DETAIL PARTITION
comandos de 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.
Este disco não faz parte de nenhum ataque, ao contrário do que está sendo exibido, atualmente está conectado à porta SATA diretamente na placa-mãe, talvez seja exibido como tipo RAID porque o controlador está no modo RAID.
O que eu acho que aconteceu (não tenho como verificar isso) é que o chkdsk estava tentando reparar o volume em segundo plano ao clicar nessa notificação no centro de ação, ele deve ter definido o ID da partição como EEh, provavelmente com a intenção de redefini-lo quando terminar. Quando defino a letra da unidade como nenhuma, ela deve ter sido exibida com erro e deixada como indicado.
O que eu tentei
Eu estava pensando em usar o comando SETID do DISKPART para especificar o tipo de partição 07, no entanto, isso não funciona:
DISKPART> set id=07
DiskPart has encountered an error: The parameter is incorrect.
See the System Event Log for more information.
Nenhuma mensagem de log de eventos é gravada no log de eventos, apenas não funciona.
Eu acho que definir essa partição de volta ao que era resultará na recuperação do acesso aos arquivos e, como eu tenho mais um desses discos formatados da mesma maneira, estou convencido de que definir o ID da partição para 07h será suficiente. só que eu não consigo fazer isso. Abaixo estão os dados do meu outro disco rígido.
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>
Se alguém tiver experiência em empreendimentos semelhantes, compartilhe sua opinião. Não tocarei na unidade por algum tempo, porque quero praticar a recuperação dessa situação. Na recuperação, verificarei as somas de verificação dos arquivos e tentarei culpar a corrupção que provocou o chkdsk na unidade ou na ponte USB.
EDIT - dados do inversor
--------------- 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 - setores 0, 7 e 8
fonte
Respostas:
Como o disco é menor que 2 TB, eu me ateria ao MBR e evitaria o incômodo de criar uma GPT e me incomodaria com todas as somas de verificação, mas, em vez disso, alterei os últimos 64 bytes do setor 0 de
para
Isso deve fazer o truque.
Eu realmente não sei por que o cabeçalho GPT está no setor 7 e a tabela está no setor 8, deve ser o setor 7 e 15 ou 1 e 2 ...
fonte