3TB HDD是混沌的奴役 ~ 修复死去的3TB HDD的坏扇区并使其复活 ~

7 min

自宅サーバー修理
language: ja bn en es hi pt zh-cn zh-tw

大家好，我是无能。
虽然我在上一篇文章中沉浸在绝望中，但我不是一个轻易放弃的人。
夏天不会结束。直到作业完成______

事情经过

昨天，SSH连接突然中断，GNU/Linux似乎卡住了，重启后，我首先检查了syslog。

Aug 27 04:03:55 localhost kernel: [2768521.366336] EXT4-fs (sdc1): error count since last fsck: 52  
Aug 27 21:19:27 haturatu kernel: [   28.915465] EXT4-fs (sdc1): warning: mounting fs with errors, running e2fsck is recommended  
Aug 27 21:24:30 haturatu kernel: [  332.803482] EXT4-fs (sdc1): error count since last fsck: 53  
Aug 27 22:28:45 haturatu kernel: [    5.694598] EXT4-fs (sdc1): warning: mounting fs with errors, running e2fsck is recommended  
Aug 27 22:33:55 haturatu kernel: [  316.412146] EXT4-fs (sdc1): error count since last fsck: 53  
Aug 28 08:19:17 haturatu kernel: [    5.710007] EXT4-fs (sdc1): warning: mounting fs with errors, running e2fsck is recommended  
Aug 28 08:24:39 haturatu kernel: [  316.427213] EXT4-fs (sdc1): error count since last fsck: 53

咦

啊

嗯？

HDD，未能归来

尝试fsck

首先通过USB-HDD连接。

$ sudo fsck -f -y /dev/sdb

在用lsblk确认磁盘后，我首先执行了它。

727810) +(77856769--77859749) +(77987841--77990269) +(78118913--78121629) +(78249985--78252434) +(78381057--78383008) +(78512129--78515588) +(78643201--78644782) +(78774273--78776000) +(78905345--78907598) +(79036417--79038955) +(79167489--79169769) +(79298561--79300360) +(79429633--79431425) +(79560705--79562857) +(79691777--79695179) +(79822849--79857556) +(79953921--79960927) +(80084993--80113787) +140247041  
Fix? yes  
  
Padding at end of inode bitmap is not set. Fix? yes  
  
Error reading block 32768 (输入/输出错误です).  Ignore error? yes  
  
Force rewrite? yes  
  
Error writing block 32768 (输入/输出错误です).  Ignore error? yes  
  
Error reading block 98304 (输入/输出错误です).  Ignore error? yes

果然如此——！！！！！
是的，这是我以前见过的绝望的I/O错误。

用dmesg查看

我将省略一些细节，但会用grep确认相关驱动器的条目。

$ sudo dmesg | grep ' I/O error,' | grep "sdb"  
[227123.296980] I/O error, dev sdb, sector 62916608 op 0x0:(READ) flags 0x83700 phys_seg 1 prio class 0  
[227175.622027] I/O error, dev sdb, sector 78880 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0  
[227175.622087] I/O error, dev sdb, sector 62916624 op 0x0:(READ) flags 0x83700 phys_seg 14 prio class 0  
[227459.286465] I/O error, dev sdb, sector 373295104 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0  
[227490.240900] I/O error, dev sdb, sector 377489408 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0

啊啊啊
我的心快碎了，帕特拉修。

谷歌搜索

我将借鉴过去技术人员的智慧。

(Linux硬盘出现坏扇区，尝试修复)[https://web.archive.org/web/20240828125146/https://neocat.hatenablog.com/entry/2019/10/21/061645]

我大致阅读后理解了其机制。

在这种情况下，如果对这个扇区进行写入操作，HDD的固件应该会将其替换为备用扇区。

据说如此。总之，我一边焦急，一边不停地输入dmesg输出中出现的扇区。

$ cat secter.sh   
#!/bin/bash  
sudo dd if=/dev/zero of=/dev/sdc bs=4k seek=$((62916608 / 8)) count=1  
sudo dd if=/dev/zero of=/dev/sdc bs=4k seek=$((62916624 / 8)) count=1  
sudo dd if=/dev/zero of=/dev/sdc bs=4k seek=$((373295104 / 8)) count=1  
sudo dd if=/dev/zero of=/dev/sdc bs=4k seek=$((406849536 / 8)) count=1  
sudo dd if=/dev/zero of=/dev/sdc bs=4k seek=$((411043840 / 8)) count=1  
sudo dd if=/dev/zero of=/dev/sdc bs=4k seek=$((415238144 / 8)) count=1  
sudo dd if=/dev/zero of=/dev/sdc bs=4k seek=$((419432448 / 8)) count=1  
sudo dd if=/dev/zero of=/dev/sdc bs=4k seek=$((423626752 / 8)) count=1

这里也省略了一些细节，但请注意，由于我每次尝试fsck都遇到I/O错误并重新插拔，所以驱动器名称从sdb变到sdc再到sdd。请谅解。
总之，我将dmesg中出现的扇区编写成脚本，并一口气运行了这些命令。
虽然可能有更简洁的方法，但在这种时候我顾不上效率。如果粗糙的战斗方式能避免误操作导致整个驱动器数据丢失，那我宁愿拼尽全力。

然后，进行fsck...

在同一个扇区上反复执行了几次，
Bad sectors playing hide and seek on my hard drive
据说smartctl也能检查坏扇区，我一开始也尝试了，但没有通过。
然而，在进行了几次前面提到的粗糙操作后，它变得可以运行了，所以我执行了sudo smartctl -a /dev/sda, sudo smartctl -t short /dev/sda并成功了，然后又重复了粗糙的操作...

$ sudo fsck -f -y /dev/sdd1  
fsck from util-linux 2.40.2  
e2fsck 1.47.1 (20-May-2024)  
Pass 1: Checking inodes, blocks, and sizes  
Pass 2: Checking directory structure  
Pass 3: Checking directory connectivity  
Pass 4: Checking reference counts  
Pass 5: Checking group summary information  
Block bitmap differences:  +(7864320--7872543) +(7929856--7946227) +(7946240--7962599) +(46661632--46669855) +(50855936--50864159) +(51380224--51388447) +(51388796--51404769) +(51404800--51412989) +(51904512--51928992) +(51929026--51929058) +(51929088--51937274) +(52428800--52453339) +(52453376--52461542) +(52953088--52962248) +(52964143--52977649) +(52977664--52985847)  

Fix? yes

呜啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊！！！！！

复活！！！！

Image
虽然还没有完全确认哪些文件损坏了，但1TB的数据大部分都恢复了。

那天我深刻体会到，前人的智慧是多么伟大。
没想到早上发现硬盘坏了，当天就能恢复，真是出乎意料的一天。
那么。
下次再见。

Related Posts