ここでは、最近サーバのHDDを交換しようとして、さんざん手こずった後を記録として、書いていきます。データ復旧だけで、あまりに長い記事になったので、記事を二つくらいに分けてます。
事の発端
最近ネットワークドライブとして使っているHDDの容量が半分を切り、使い切ってしまいたくないと思い立つ。そこで、ヤフオクで10TBのHDD2個を新たに購入し、RAID1で運用したいと思うようになる。まだいっぱい空き容量があるじゃないか！と思う人もいると思うが、自分的にはHDDのスペースはいっぱい用意しといて、心置きなく作業したかったので、もっと容量のあるHDDへ交換することにした。
今回得た教訓
smart arrayは優しくない
HPE社製のRAIDコントローラーに搭載されているソフトウェアでは、管理コンソールから論理ディスクを消したら、平気でGPTとかのパーティション情報は、少なくともHDDを付けたまま作業すると、消されてしまう。
バックアップを取ろう
消えてかつ上書きされてしまったら運の尽き。
やらかしたらなるべく書き込まない
元の構成に戻して、上書きしないようインストールメディアなどから作業を行い、testdiskコマンドとかでパーティション情報を探して復元を試みてみる。
新旧比較
古いHDD
今までは、普通のWestern Digital製500GB HDDを使っていた。SATA対応。確か2016年製で、2018年くらいに中古で買って連続で5年程度使ってた覚えがある。
新しく買ったHDD
今回新たに買ったのは、2017年製と古いものではあるが、ヘリウム充填のHGST（現 Western Digital）製の10TB HDDを買った。SAS対応。出品者によれば動作に問題なさそうらしい。
Smart HBA H240
今使っているRAIDコントローラーは、「Smart HBA H240」とかいうやつで、サーバーを買ったときにセットでついてきたもの。以下は、外したりするのはメンドウだったので、適当に画像はネットから拾ってきた。
悲劇と出会う 🫠
さっそく、HDDを交換してみようと試みるのだが、RAID1の500GB二枚のHDDをどうやって交換か考えたとき、今までの経験上では、RAIDの論理ディスクを消してもよかったなと思い出す。（🚩）ついつい早まってしまい、バックアップを取らずに作業をはじめてしまう。HDDを外して、外したHDDの中身を何かしら見えるように調整し、新しいディスクにクローンしたらいいだろうと思ってやってみたら、どうもSmart arrayはそうではなかったようで。。。
HDDを付けたまま論理ディスクを削除
これは完全に失敗で、論理ディスクを消すとSmart arrayでは、GPTなどの情報をいじくりまわしてしまうようだった。なので、同じ構成、設定で再構築しても中身のパーティションはなかったことになるという、ホラーな状態に。arch linuxのインストールメディアから、中身を確認すると、こんなことに。。。
fdisk -l
ディスク /dev/sdb: 465.66 GiB, 500000514048 バイト, 976563504 セクタ
ディスク型式: WDC WD5003ABYX-2
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: gpt
ディスク識別子: 一応秘匿
デバイス 開始位置 終了位置 セクタ サイズ タイプ
一体全体ワイのデータをいずこへ？ と思って焦っていたが、よくよく考えれば、論理ディスクとか消すときって、あんまり時間かからないクイックフォーマットみたいな感じで終わってたから、まだデータはあるのではと勘繰る。最終的にはこの予感は当たるのだが、そこまでが長かった。。。
もしかして？
調べていると、HPEのコミュニティサイトに、まったく同じ設定、構成にして、gdiskで開いたら、「gptの構成が壊れている」というメッセージが出てきて、writeしてやれば治るみたいな返信を発見する。
いろいろ試してみる
早速修復を試みてみるが、何をとち狂ったのか、RAID1なら2台のHDDとも同じ内容だろうと思い、一つだけ繋げてRAID0で設定を行ってしまう。幸いにもセクタサイズとかは、そのままにしてたので、データを破壊するまでには至らなかったが。。。
gdiskで読み込ませてみても、“No problem reported"みたいなのしか出てこず、MBR、GPTともに何もないことになってて、アッこれ終わったわ、って一瞬なったが、諦めきれずに作業を続けた。
gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.10
Partition table scan:
MBR: not present
BSD: not present
APM: not present
GPT: not present
testdiskコマンド
頑張って、GPTパーティション情報を復元する方法を探していると、testdiskコマンドなるものがあることを発見した。ので試してみたところ、quick searchで見覚えのあるパーティションを見つける。arch linuxのインストールメディアには標準で入っていたので、それをそのまま使った。
mke2fs -n /dev/sdX1
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, ...
e2fsck -b 32768 /dev/sdX1
e2fsck -b 98304 /dev/sdX1
e2fsck -b 163840 /dev/sdX1
fsck.ext4 -b 32768 /dev/sdX1
上記に示した様なコマンドをひたすら試して、バックアップされてるらしいいろんなスーパーブロックらしきものを試すが、まったくうまくいかなかった。
実はずれている！
そうこうしているうちに、とあることに気づく。もしかして、復元したパーティションは、間違っているのではないかと。通常のOSが入ったパーティションの構成は、
/dev/sdb1 2048 1025986 1023939 500M EFI システム
/dev/sdb2 1026048 881829887 880803840 420G Linux ファイルシステム
/dev/sdb3 881829888 976496623 94666736 45.1G Linux スワップ
のように、ブート用のFAT32でフォーマットされたEFI領域に、ext4やNTFSでフォーマットされた、OSやその他もろもろデータの入っている領域、後は今回でいえばスワップ領域となっているが、winRE?などの回復環境のためのパーティション領域などが、一般的にはあるはずであると。しかしさっき表示されていたパーティションは明らかに様子がおかしく、全部復元するように設定できず、MS dataというパーティションが本来、EFIパーティションとなっているはずの部分で、Linux filesysと認識されれているパーティションは、ファイルの中身が閲覧できないという状態だった。とにかく、問題に気づいたので、さっそくtestdiskコマンドで、deep searchを行ってみる。
バックアップを取る 💾
今思えば、なぜ約20TBの容量のあるデータディスクに、たかだか500GB程度のデータのバックアップを怠ったのかという話ではあるが、とにかく動くようになったので、必要なコンフィグとか授業資料などのデータをバックアップした。
次のページ
参考にしたサイト
- 「TestDisk」の使い方 - PCと解
https://pctrouble.net/software/testdisk.html （2024年6月12日） - partitioning - Fixing corrupt backup GPT table? - Ask Ubuntu
https://askubuntu.com/questions/386752/fixing-corrupt-backup-gpt-table （2024年6月12日） - Accidentally deleted the RAID configuration - Hewlett Packard Enterprise Community
https://community.hpe.com/t5/proliant-servers-ml-dl-sl/accidentally-deleted-the-raid-configuration/td-p/7161927（2024年6月12日）