2TBの壁

サーバーの基本情報

• ハードディスクが10本搭載されたLinuxサーバー
• その内2本がRAID1（80GB）で構成されOSがインストール
• 残り8本がRAID6（4.1TB）で構成されたデータ領域

　　RAID1（80GB）Drive Bay ID 1,2
　　　　/dev/cciss/c0d0p3　　/
　　　　/dev/cciss/c0d0p2　　/boot
　　　　/dev/cciss/c0d0p5　　/home
　　　　/dev/cciss/c0d0p6　　/var
　　RAID6（4.1TB）Drive Bay ID 3,4,5,6,7,8,9,10
　　　　/dev/cciss/c0d1p1　　/data（RAID6 750G * 8）

依頼内容

サーバーにアップロードしているファイルの読み書きができなくなってしまった。ファイルが存在していることだけは分かる。助けてちょ！
という内容の依頼。

状況確認

ファイルの読み書きができないのはサーバー全体のディレクトリではなく、/data 内全てのディレクトリとファイル。

lsコマンドで確認するとこんな具合にパーミッション情報が全て？で表示される。

??????????　4 xyz xyz　4096 Jul 2 2012 hogehoge

これは以前にも経験したことがあり、inode周りに問題が発生していることを推測する事は容易。

dfコマンドに「i」オプションを付けるとinodeの使用量を表示することができる。

念のため確認すると、表示される内容の信憑性は低いと思われるが、使用量が表示されinode領域を使い切っている訳ではなくディスク故障臭い。

サーバー機器を目視確認してもらうと、目視確認してもらうと2本のハードディスクのLEDは消灯。

2本のハードディスクが同時に故障することはある？と突っ込むことなく次のステップ。

重要な設定変更

ファイルが存在していることは分かるのだから、データをロストしている訳ではない。これで直らないかやってみた。
# mount -o rw.remount /data

が不発。次にやりたくなるのが、いや、データの吸い出しができない状態で次にやれる事と言えば再起動しかない。

とその前にやっておくことがある。

大容量のパーティションを切っている場合、長い間OSの再起動をしていないとfsckが自動で走って起動に多くの時間を要する。ましてや今回のようにハードディスクが物理的に故障しているとなると起動できないことは必至。
なので、問題のあるパーティション（マウントポイント）を起動時にマウントしないように設定しておく必要がある。

依頼のあったサーバーでいうと、/dev/cciss/c0d1p1 というファイルシステムが /data としてマウントされるように設定されているので、/etc/fstab にてマウントされないように手を施す。

あとはOSを再起動して、fsckの番人となればいい。

完全ではないが、実際にサルベージできたのは最初の連絡があってから5日後だった。

2本ではなく3本が故障の疑い

あとはハードウェアベンダーからハードディスクを調達して、故障したハードディスクと交換してやればいいだろうと思っていたが、サーバーのオフライン調査で恐るべき事が明らかになった。

なんと、故障しているハードディスクは2本ではなく、3本の可能性が高いというのだ。結局Drive Bay ID 3,4,8がアウト、赤で囲んだ箇所が故障と判明。

RAID6の耐性を超える救出劇、依頼者から必要以上に感謝されるとそのまま引くわけにもいかなくなり最後まで付き合うことに。

復旧プラン

2本のハードディスクは 完全にアウト。

ID8は辛うじて動いている状態の様なので、「故障ディスク3本を交換してID3〜10のアレイ設定を再度行ってからデータを戻しましょう」と提案。

1. 故障ハードディスク交換
2. アレイコンフィギュレーションユーテリティでRAID6を再設定
3. fdiskでパーティション設定
4. mkfsでファイルシステム設定

こんな感じで簡単に直る。

2TBの壁

ハードディスクがベンダーから届いて交換した後に、上記1〜4まで問題なく完了したかのように思えたが・・・ハードディスク容量が1.9TBしか認識してないことに気付いてしまった。

自分で構築するサーバーはVPSとて2TBを超えるディスクを使うことはない。

なので最初は「ん？」と思ったが、fdiskは2TB以上のパーティションをサポートしていないことを思い出した。

言いたかったこと

ここまでして言いたかったことは、「大容量ハードディスク（今は必ずしもHDDではないけど）で2TB以上のパーティションを設定しているのであれば、Linux OSインストール直後にpartedもインストールしておきましょう！絶対に！！」ということです。

稼働してもう何年にもなるサーバーマシン。

経年劣化による故障のリスクは日に日に高まるものです。

OSやその他ソフトウェアのメンテナンスも全く成されていないとなると、故障した時に必要となるソフトウェアをインストールするのも相当骨が折れます。

おかげでガッツリ儲けさせてもらいましたが（笑）。
2TB以上のパーティションを持つサーバーでやっておくことは、「ディスクのパーティショニングとパーティションサイズを変更できるpartedのインストールを必ず行う」ですよ。

partedでパーティション設定

# parted /dev/cciss/c0d1
GNU Parted 1.7.1 Using /dev/cciss/c0d1 Welcome to GNU Parted! Type ‘help’ to view a list of commands.
(parted) print
Disk /dev/cciss/c0d1: 4501GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
(parted) mklabel gpt （ディスクラベルは2TB越えをサポートしたGPTに設定）
(parted) mkpart primary ext3 0 4501G（ファイルシステムやパーティションサイズを指定）
(parted) print
Disk /dev/cciss/c0d1: 4501GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 17.4kB 4501GB 4501GB primary
(parted) quit
# partprobe（OSを再起動せずにパーティションの更新情報を認識させる）
# mkfs.ext3 -j /dev/cciss/c0d1p1（ファイルシステムをext3でフォーマット）
mke2fs 1.40-WIP (14-Nov-2006)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
549421056 inodes, 1098812245 blocks
54940612 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
33534 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000, 550731776, 644972544
Writing inode tables: 3521/33534