何が起きたか

稼働年数が7年を超えたHDDをバックアップサーバーのシステムディスク(btrfs)として使っていたところ、ある日回復不可能セクタが発生した。

別のHDD(容量違い)にクローンしてGPTパーティションを修復したが、1物理セクタ(4096バイト)は読めなかったので、破損状況の確認と修復を試みる。

破損状況の確認

クローンしたときに、読み取りエラーが発生していた。その場所は/(ルート)にマウントしているパーティションの領域

まずは、btrfsのscrubを実施して影響を受けているか確認する。

# btrfs scrub start /

「Status」が「finished」になるまで待つ。60GBくらいの領域で3GBも使っておらず、体感数分程度で完了した。

# btrfs scrub status /

「Error summary」を見る。

残念ながら影響を受け、回復不能に陥ったファイルが検出された。

もし、冗長性のあるストレージ構成ならscrubをした時点で回復を試みてくれるらしい。

シングルでもこれを検出できるのはファイルシステムとしてはかなり優秀。助かる。

Error summary:    csum=1
  Corrected:      0
  Uncorrectable:  1
  Unverified:     0

scrub後にdmesgをみると、破損したファイルのパスを得ることができる。

# dmesg | tail -n 50
[46440.889254] BTRFS info (device dm-0): scrub: started on devid 1
[46446.670143] BTRFS warning (device dm-0): checksum error at logical 1275736064 on dev /dev/mapper/sda4_crypt, physical 2357866496, root 256, inode 34533, offset 1302528, length 4096, links 1 (path: usr/lib/x86_64-linux-gnu/libgnutls.so.30.29.1)
[46463.324118] BTRFS info (device dm-0): scrub: finished on devid 1 with status: 0

(path: ～～)のところが破損したファイル。このボリュームは/にマウントしているため、絶対パスに直すと、次のようになる。

/usr/lib/x86_64-linux-gnu/libgnutls.so.30.29.1

幸いなことに、破損したファイルはソフトウェアパッケージのもので、これは再インストールができる。

ファイル名をネットで検索してみると、「libgnutls30」というパッケージのものであることが判明。このパッケージを再インストールする。

# apt --reinstall install libgnutls30

再度scrubを行う。

「Error summary」が「no errors found」になっていればひとまずファイルの破損からは回復。

# btrfs scrub status /
UUID:             ******
Scrub started:    *** *** ** **:**:** ****
Status:           finished
Duration:         0:00:22
Total to scrub:   2.56GiB
Rate:             118.45MiB/s
Error summary:    no errors found

ただ、dmesgを眺めていると、corruptのカウントが4になっているのはちょっと気になる。もしかしたら、該当セクタをbtrfsがマークしているかもしれない。今回はクローンでディスクを移植したので、ファイルシステムから見ればここが正常になったことは気づけない。

容量には余裕があるので問題ないが、あんまり気持ちのいいものではないかも。

ただ、とりあえずシステム全体としては正常に回復したので、ヨシ！！

参考資料