2025年6月にメインファイルサーバーのzfsを”物理的操作ミス”で飛ばしてしまいました。（；＿；）
メインファイルサーバーには、これまで試作など行ってきた電子工作の回路図や、鉄道模型関連の図面、料理のレシピ等、すべての情報を保管。
アナログの情報もほとんど残していない（かなり処分した／電子データ以外、作っていない）状態。
しかも、過去情報のアーカイブ化も一部のみで、アーカイブもほとんどなく、
zfsのスナップショット作成やscrubもしていませんでした。（；＿；）
進退窮まりました。（＊＿＊）
しかし、何とかリカバリー（読み出し）をして、少しでもデータを引き上げたいです。【注*1】
暇を見つけては、国内外の情報を探していたのですが、幾つか試してみたところ、
何とか、引き上げに一筋の光明が見えた気がするので😅、
ここまでの作業記録を整理していこうと思います😅。
実は、”アクティブドメインコントローラーの再設定／バックアップ領域追加［*2］”や、
”一時データファイルサーバーへのレプリケート設定［*3］”を集中的に行っていたのは、背景にこの件があったためです😅。
- 完全に小生の作業記録兼健忘禄となっておりますことをご容赦いただければ幸いです🙇♂️。
0. やらかした！
1)ケアレスミスでzfsがとんだ。（1つ目のミス）
BluRayに保管してあったデータを、他のサーバーメンテで使うために、
メインファイルサーバーにつなげたBD-Rアーカイブユニットのディスクをアーカイブ保管ディスクに交換しようとししました。
この時、マウント中のディスク、かつ、ディスク内のISOイメージをメモリーディスクとマウントしていた、デバイスのイジェクトボタンを”物理的”に押してしまいました。
2)2つ目のミス
当該のBD-Rディスクは、ノートパソコン向けのスリムタイプで、マウント中でもイジェクトボタンが動作してしまいます。
しかも、マウント中のイジェクトボタンの無効化設定をしてませんでした。
3)3つ目のミス
BD-Rアーカイブユニットのドライブとは別に、一時利用用にマザーボートのSATAポートに直接接続したBD-Rドライブを使えばよいものを、なぜか、BD-RアーカイブユニットのBD-Rドライブを使おうとしました。
4)4つ目のミス
メンテナンスを予定していたものの、全体の作業工程を熟考せずに、
バックアップなどの手段をとる前に、
メインファイルサーバーに手を出してしまいました。
5)イジェクトさせた瞬間
表示していたコンソールに突然、panicメッセージが😵。
再起動するとzfsなファイルシステムがマウントされてなくなっていました😵。
事故（業務不適合）は、一つの要因で起きるのでなく、複合的要因で破滅的な結果を招くことを改めて実感します。
1. エラー状況を確認
1) ”zpool status”で確認
| root@main_sv:# zpool status pool1 |
”The pool metadata is corrupted and the pool cannot be opened”と言われたうえ、
”poolを作り直して、バックアップからいリストアせよ”、
と言われてしまいました。
2)"gpart"で物理ディスクを確認
とりあえず、物理ディスクの確認をしておきます。
| root@main_sv:# gpart list |
ディスク内のパーティションは生きているようです。
2. 手を付ける前に
メインファイルサーバー上で、試行していると余計に状況が悪化して、収拾がつかなくなりそうです。
まずは、障害発生時点の当該ディスクをバックアップしておきます。
そのあと、ファイルサーバーにReplocate用ディスクを準備し、引き上げ手順を試行してみることにします。
1)ディスクのRAWデータをバックアップ
ディスクイメージのバックアップ用に8TBのディスクを新規に準備して、古いUSB-HDDケースに装着。
| root@main_sv:# dd if=/dev/da3 of=/mnt/da4p1/main_sv.da3.250622.img bs=4M conv=sync,noerror |
取り付けたUSB/HDDはUSB2.0のせいか、転送量4TBの転送時間147,342秒（41時間）もかかってしまいました。
