Intel Rapid Storage Technology の RAID1 (mirror) で運用していたボリューム(HDD 2台で構成)の片方の HDD が頻繁に以下で反応しなくなって，使い物にならないので，別途買っていたHDDでリプレースしようとして失敗．
May 7 19:11:22 hoge kernel: [1666250.655691] ata2: link is slow to respond, please be patient (ready=0)
May 7 19:11:27 hoge kernel: [1666255.359669] ata2: COMRESET failed (errno=-16)
May 7 19:11:30 hoge kernel: [1666258.195679] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
May 7 19:11:30 hoge kernel: [1666258.197435] ata2.00: configured for UDMA/133http://blog.e-photographer.net/raid-degraded?lang=ja の記事を参考にしつつやっていたつもりなのだが，途中で失敗．以下失敗手順．
- 電源落とす
- 不調HDDを新しいものに差し替え
- 電源入れて Control-I で RAID 設定画面を開く
- Status Failed となっていることを確認，このままだと Create RAID Volume or Delete RAID Volume しかできず，身動き不能に．
- 仕方なく Delete RAID Volume (←これが失敗の原因)
- Create RAID Volume すればよいか．．．と思い，そもそもこの状態だとリプレースされたのがどちらのHDDか不明で，どちらからどちらに Mirror されるか決められないのでは？ と思う (←この辺でやってしまったかも知れないことに気づく)
- 電源落とす
- 新しいHDDを取り外して不調HDDもどす
- 電源入れて Control-I で RAID 設定画面を開く
- Create RAID Volume で RAID Volume の復活を試みる (Mirror なのだから，元データは維持されるはず)
- Reset Disks to Non-RAID で不調HDDを Reset (Volume から切断)する
- 電源落とす
- 不調HDDを新しいものに差し替え
- 電源入れて Control-I で RAID 設定画面を開く(Volume は Degraded 状態)
- リビルドするか？ と聞かれるので，新しいHDDを選択してリビルド
- 再起動
この手順でなにが起こったかというと /dev/md126 の先頭 4096 byte が初期化されてしまい(sudo dd if=/dev/md126 | less等でざっと見の結果)，実は LUKS でまるごと /dev/md126 を encrypted volume として利用していたので，つまり LUKS ヘッダが壊れてしまった．
cryptsetup luksOpenできず，そもそもcryptsetup luksDumpもできず(ヘッダが存在しないので)，実はどこかにヘッダのバックアップがあったりしないかとman cryptsetupを確認すると，以下のように書かれており，どうやらダメっぽいことに気づく．
LUKS header: If the header of a LUKS volume gets damaged, all data is permanently lost unless you have a header-backup. If a key-slot is damaged, it can only be restored from a header-backup or if another active key-slot with known passphrase is undamaged. Damaging the LUKS header is something people manage to do with surprising frequency. This risk is the result of a trade-off between security and safety, as LUKS is designed for fast and secure wiping by just overwriting header and key-slot area.
他の計算機で LUKS header のバックアップを sudo cryptsetup luksHeaderBackup /dev/md126 --header-backup-file backup_file でとってみたところ 2,068,480 byte (4096x505) あって，その先頭 4,096 byte (UUIDやCipher mode，MK digest/salt)を移植してみたが当然だめだった(偽情報だが luksDump は可能になるが，やはり luksOpen でパスフレーズが合うはずがない)．
参考: