【障害経過のご報告】kita ノードのストレージ障害によるデータ消失について
2026年9月15日
このたび、弊社ストレージサービスの一部ノード（kita.teracloud.jp）において、保存されていたお客様のデータが消失する重大な障害が発生いたしました。対象となったお客様には多大なご迷惑とご心配をおかけしておりますことを、深くお詫び申し上げます。本ページでは、何が起きたのか、その技術的な背景と原因、今後の対応について、ご説明いたします。
| 対象ノード | kita.teracloud.jp ノード（kita1 ストレージプール） |
|---|---|
| 影響を受けるユーザー | 上記ノードにデータを保存されていたユーザー |
| 障害発生日 | 2026年8月19日（JST）~ |
本障害の影響は kita.teracloud.jp ノードに限られます。 それ以外のノード・サービスをご利用のお客様には影響なく、通常どおりご利用いただけます。
ご自身が影響対象かどうかは、ファイルブラウザーのアドレス欄またはWebDAV接続URLにてでご確認いただけます。該当ノードをご利用でないお客様は、これまでどおり安心してご利用いただけます。
1. 何が起きたのか
2026年8月19日、お客様のデータを保存していたノード（kita.teracloud.jp）で、データの破損が発生しました。
このストレージは、ハードディスク20台をZFSのraidz3という構成で運用しておりました。raidz3 は、パリティ（復元用の予備情報）を三重に持ち、最大3台のディスクが同時に失われてもデータを復元できる、堅牢性の高い方式です。通常であれば、数台のディスク故障でデータが失われることはありません。
しかし今回は、この冗長性が想定する範囲を超える形で障害が発生しました。1台のディスクが完全に応答しなくなった（UNAVAIL）のに加え、複数のディスクでデータの整合性エラー（チェックサムエラー）が同時多発的に増加しました。
raidz は、複数のディスクが不調（DEGRADED）でも、壊れている箇所が互いに異なれば、残ったデータとパリティから相互に補い合って復元できます。ところが今回は、復旧処理を進めるうちに破損が広範囲へ拡大し、壊れた箇所が重なり合ったため、パリティによる復元が成立しなくなりました。結果として、大部分のデータが読み出せない状態に至りました。
2. 復旧の経過
| 日付 | 内容 |
|---|---|
| 8/19 | 障害を検知。当初は影響が一部のお客様に限られると見込み、装置本体（筐体）の障害と判断して機材を交換 |
| 8/20 以降 | 復旧処理（resilver）を進める中で、破損が想定に反して拡大。チェックサムエラーは数千件から約180万件、最終的に数百万件へ急増。処理中にストレージが繰り返し停止（SUSPENDED） |
| 8/21 | 破損したデータが約475万件に達したことを確認 |
| 8/24 以降 | 方針を「修復」から「読み出せるデータの救出」へ転換。別領域への移設に切り替え |
| 8/26 以降 | 移設を開始するも、救出できたデータは容量全体のわずか 0.2% にとどまる |
※ resilver（リシルバー）とは、失われたディスクの冗長性を回復するための、正規の再構築処理です。本来は復旧のための処理ですが、今回はこの進行とともに破損範囲拡大が発覚するという、想定外の経過をたどりました。
3. 被害の状況
該当ノード（kita.teracloud.jp）における影響は、現時点(9/14)で判明している範囲で以下のとおりです。以下の割合は、あくまで当該ノード内のデータに対するものです。
| 項目 | 割合（容量／ファイル数ベース） |
|---|---|
| 消失したデータ | 容量ベース 99.85% ／ ファイル数ベース 34.20% |
| 救出できたデータ | 容量ベース 0.2%（移設による実績値） |
容量では大部分が失われている一方、ファイル数では約3分の1にとどまっています。この差は、サイズの大きいファイルが集中して失われたことを示しています。データの所在を管理する情報（メタデータ）の上位が壊れると、その配下にぶら下がる大容量のファイル群がまとめて到達不能になる一方、別の系統に残ったファイルは無事に読める、という構造から生じたものと考えられます。
なお、これらの数値は、破損したデータを実際に読み出した時点で判明するものです。raidz では、ディスクが破損していた場合、そのデータを初めて読み出すときに欠損が判明します。そのため、全データの確認が完了するまで、割合は今後も変動する可能性があります。
4. 原因について
原因はこれまでの経過から、以下のように考えております。
破損が復旧処理の進行とともに増加したことから、ディスク1台1台の個別故障ではなく、複数のディスクに同時に作用した共通の要因があったと見ています。これを「誘引」と「素因」の二層で捉えています。
誘引（引き金）
ディスクをつなぐ内部の通信経路（SAS 経路：HBA・エクスパンダ・バックプレーン）が、同時多発的に停止したこと。経路が停止すると、配下のディスクが一斉に応答不能になります。ただし、経路の停止そのものは、原理的にはデータを破壊しません。ZFS はトランザクショナル（書き込みを一括で確定する）な設計であり、書き込み途中で経路が落ちても、確定前の処理が失われるだけで、確定済みデータの整合性は保たれるためです。
素因（下地）
一部のディスクのファームウェアが「書き込みが完了した」と実際には未完了のまま応答していた可能性。ZFS は、ディスクからの「完了しました」という応答を信じて次の処理を確定させます。この応答が偽りだった場合、経路の停止やリセットが重なったときに、データの整合性を守る前提が崩れます。この崩れは、データ全体の起点となる管理情報の不整合として現れ得ます。
そして、約475万件という大量のエラーは、個々のデータブロックが独立に壊れた結果ではなく、上位の管理情報の不整合が、その配下の広範なデータへ波及した結果である、と見ています。前述の「容量99.8% に対しファイル数35%」という非対称も説明できます。
装置本体を交換しても破損の拡大が止まらなかったことから、消去法として、原因は交換していないディスク側にある可能性が高いと判断しております。
5. 再発防止・対応策
同様の障害を繰り返さないため、以下に取り組みます。
該当ディスクの全数交換
他のノードで同様のデータ消失は発生しておりませんが、再発を未然に防ぐため、原因として疑われる型番のハードディスクを予防的措置として順次交換してまいります。交換の過程で、確証に向けたエラー傾向の採取も並行して行います。
Ceph による多重化への移行
今回の障害の本質は、単一の装置・単一のプール内に冗長性が閉じており、その内部で複合障害が起きると全損に至る点にありました。raidz3 の三重パリティも、壊れた箇所が重なれば復元できません。InfiniCLOUD（旧称：TeraCLOUD）サービス開始時では最善の選択ではありましたが、今後ストレージ基盤を Ceph と組み合わせた仮想基盤構成へ移行し、複数の筐体をまたいでデータを多重化する方針です。これにより、1つの装置・1つのプールへの依存を解消いたします。
6. 今後の対応
- 読み出せるデータの救出・移設を、引き続き順次実行してまいります。
- 状況の続報を、随時ご案内いたします。
このたびは、お客様の大切なデータをお預かりする立場でありながら、このような事態を招いてしまい、重ねて深くお詫び申し上げます。
