SATA ポートが足りない時代のデータサーバー運用

by

秋葉原で最近のケースとマザーボードを見ると、現在の自作 PC 市場がどこを向いているかがよく分かる。店頭で目立つのは、大型 GPU を収める空間、前面や上面に大型ラジエータを置ける冷却設計、強化ガラスのサイドパネル、LED を前提にした見た目、複数の M.2 スロット、高速な USB Type-C や USB4 である。これらは現在の主流用途にはよく合っている。ゲーム、配信、制作作業、日常作業では、OS とアプリケーションを NVMe SSD に置き、大型 GPU を冷やし、配線を隠し、見た目を整えることに大きな意味がある。

しかし、その店頭風景の中では、3.5-inch HDD を何台も収めるベイや、SATA ポートを 6 基以上持つマザーボードは見つけにくくなっている。これは、単に古い PC のほうが良かったという話ではない。市場の主流が、内蔵 HDD を多数積む機械から、高速な SSD と大型 GPU を中心にした機械へ移ったということである。現在のケースとマザーボードは、現在の主流用途に合わせて合理的に変化している。その結果として、ストレージ中心の汎用データサーバーに必要な要素が、一般向け PC の標準構成から外れつつある。

本稿で扱うデータサーバーは、単なる NAS 専用機ではない。LAN 内でファイル共有を提供する機械であると同時に、ローカルで GUI も使え、複数の HDD や SSD を直接接続し、暗号化デバイスを開き、ファイルシステムをマウントし、S.M.A.R.T. を確認し、必要に応じてディスクを交換し、データを整理する汎用 Linux マシンである。この種の機械では、ストレージは単なる容量ではない。物理ディスク、SATA ポート、暗号化レイヤー、ファイルシステム、マウントポイント、権限、共有設定が積み重なった運用基盤である。

そのため、本稿ではまず、システム領域を含めて保存されるデータを原則として暗号化するという前提を置く。暗号化する対象は、文書や写真や動画のように分かりやすいデータだけではない。OS、ユーザー領域、共有領域、swap、一時ファイル、ログ、キャッシュ、サムネイル、仮想マシンイメージ、アプリケーション設定にも、データの断片や履歴や構成情報が残る。データ領域だけを暗号化しても、システム領域が平文のままなら、保護したつもりの情報が別の場所に残る。したがって、暗号化ストレージを扱う汎用データサーバーでは、システムを含めた全体暗号化を基本方針にする必要がある。

この前提に立つと、古い SATA 環境を大切にする理由ははっきりする。古い機械への愛着だけではない。暗号化ストレージを扱う汎用データサーバーでは、ディスクを OS から直接観測できること、S.M.A.R.T. を確認できること、複数の 3.5-inch HDD を安定して固定できること、電源と冷却を確保できること、暗号化デバイスの解除とマウントを一貫した手順で管理できることが重要になる。LUKS、cryptsetup、デバイス名、マウントポイント、鍵管理を運用として扱うという既稿の整理は、この前提を与える[1][2][3][4][5][6]。

本稿の中心命題は、古い SATA 環境は時代遅れだから残るのではなく、特定の用途に対して今でも合理的だから残る、というものである。最新の PC は、高速な NVMe SSD、大型 GPU、高速外部 I/O、見た目、冷却の面で優れている。一方で、暗号化された複数の 3.5-inch HDD を直接扱うデータサーバーでは、SATA 直結、HDD ベイ、前面吸気、ケーブルの追跡性、ディスク交換の作業空間、S.M.A.R.T. による観測可能性が効いてくる。市場の主流と運用上の必要条件がずれているため、十年以上前のケースとマザーボードが、今でもストレージ運用の基盤として価値を持つことがある。

観点 現在の主流 PC で重視されるもの 汎用データサーバーで重視されるもの
保存媒体 OS、アプリケーション、ゲーム、作業領域を高速な NVMe SSD に置くことが重視される。 大容量の 3.5-inch HDD と高速な SSD を役割分担し、暗号化された保存層として管理することが重視される。
接続経路 M.2、PCIe、USB4、Thunderbolt などの高速接続が訴求される。 SATA 直結によって、HDD を OS から素直に観測し、S.M.A.R.T. や long test を扱えることが重視される。
ケース設計 大型 GPU、ラジエータ、前面メッシュ、裏配線、ガラスパネルが重視される。 3.5-inch HDD を固定し、冷却し、交換し、電源と SATA ケーブルを無理なく引き回せることが重視される。
運用構造 個人作業やゲームの快適さを中心に構成される。 暗号化デバイス、マウントポイント、権限、Samba、NFS を一貫して説明できることが重視される。

1. 問題は新旧ではなく、用途と設計思想のずれである

最近の PC パーツは、最新であること自体が問題なのではない。むしろ、多くの用途では明らかに改善している。NVMe SSD は速く、CPU は高性能で、GPU は大きな演算能力を持ち、USB やネットワークは高速化し、ケースは冷却しやすく、配線も整理しやすくなった。ゲーム、配信、動画編集、開発、日常作業では、こうした進歩はそのまま利点になる。したがって、古いケースとマザーボードを再評価する議論は、新しい PC パーツへの反発ではない。

問題は、用途と設計思想のずれである。現在の一般向け PC は、多くの場合、OS とアプリケーションを NVMe SSD に置き、大型 GPU を冷やし、ケース内を見せ、外部 I/O を高速化する方向へ最適化されている。この設計では、3.5-inch HDD を多数内蔵する必要は薄い。SATA ポートが 4 本前後でも、多くの利用者には十分である。3.5-inch ベイが 1 基から 2 基でも、OS を M.2 SSD に置き、追加の大容量 HDD を 1 台だけ使う程度なら困りにくい。

一方、ストレージ中心の汎用データサーバーでは評価軸が変わる。CPU の世代や GPU の性能だけではなく、ディスクを何台直結できるか、どのディスクがどの用途に対応しているか、どの物理ベイに入っているか、どの SATA ポートへ接続されているか、どの暗号化デバイス名で開くか、どのマウントポイントへ載せるか、どの共有設定へ渡すかが重要になる。これは、単なる性能比較ではなく、運用構造の比較である。

暗号化を前提にすると、この違いはいっそう大きくなる。暗号化されたディスクは、電源を入れれば自動的にただの保存領域として使えるものではない。物理ディスクを認識し、暗号化デバイスを解除し、ファイルシステムをマウントし、権限を確認し、共有サービスの対象にする必要がある。ディスクを差し替えるたびに接続経路が変わったり、USB ブリッジを挟んで S.M.A.R.T. が取れなかったり、マウント先と共有名の対応が曖昧になったりすると、データサーバーの運用は複雑になる。

この意味で、速度を上げるために構成を複雑にする判断は、常に正しいとは限らない。LVM cache を試しても、起動時の認識順や復旧性が複雑になれば、常時運用の信頼性は下がるという判断は、ストレージ中心の機械では速度より構成の単純さが価値を持つことを示している[7][8]。速いことは重要である。しかし、どこに何があり、どの順序で起動し、何が壊れたときにどこを疑うのかを説明できない構成は、データサーバーには向かない。

GUI を提供する点も、この機械を単なる NAS 専用機ではなく汎用機にする。ローカル画面と入力装置が使えると、暗号化ボリュームの解除、ディスク状態の確認、S.M.A.R.T. の確認、ファイル整理、障害時の切り分けがしやすい。GUI は、データサーバーを単なるネットワーク上の箱ではなく、直接操作できる作業環境にする。一方で、古い GPU や表示系は、現行カーネルや Xorg との相性に左右されることがある。GUI は便利であるが、最終的には SSH、VNC、xrdp などの代替操作も成立するように設計しておく必要がある[9]。

遠隔 GUI を併用する場合は、既存画面を共有する VNC 型の方式と、RDP 経由で別の GUI セッションを起動しやすい xrdp 型の方式を区別する必要がある。xrdp では local GUI と remote GUI が別セッションとして並び、D-Bus、systemd user session、Xauthority、デスクトップ環境の設定やセッション保存が競合しうる。したがって、データサーバーで GUI を提供するなら、ローカル画面、SSH、VNC、xrdp を単なる接続手段として並べるだけでなく、どの層を共有し、どの層を分離するかまで設計する必要がある[10][11][12][13][14][15][16]。

用途 重視される要素 不足すると起こる問題
ゲーミング PC GPU 性能、冷却、NVMe SSD、外観、静音性が重視される。 HDD の多台数搭載性が低くても、主要用途では大きな問題になりにくい。
日常作業用 PC OS の応答性、アプリケーションの起動、低消費電力、静音性、扱いやすさが重視される。 SATA ポートや 3.5-inch ベイが少なくても、クラウドや外付けストレージで補える場合が多い。
NAS 専用機 ネットワーク共有、低消費電力、専用管理 UI、常時稼働性、簡易なディスク管理が重視される。 OS から個々の暗号化デバイスを柔軟に直接操作したい場合、専用設計が制約になることがある。
汎用データサーバー 複数 SATA、3.5-inch ベイ、S.M.A.R.T.、全体暗号化、暗号化デバイス管理、GUI、ネットワーク共有が同時に必要になる。 新しい構成でも、SATA ポートや HDD 搭載性や観測可能性が足りなければ、運用上の自由度が落ちる。

この表が示しているのは、どの用途が上位で、どの用途が下位かという序列ではない。用途ごとに必要な設計が違うということである。ゲーミング PC では、大型 GPU と冷却が中心になる。日常作業用 PC では、応答性と静音性が中心になる。NAS 専用機では、ネットワーク越しに安定してファイルを出すことが中心になる。汎用データサーバーでは、それらとは別に、ローカルで暗号化ストレージを直接扱い、必要な範囲を LAN 内へ共有し、ディスク状態を観測しながら長期運用することが中心になる。

したがって、古い SATA 環境を再評価する議論は、最新機能の否定ではない。むしろ、用途に対してどの設計が合っているかを見直す議論である。現在の主流 PC は、速度、見た目、冷却、GPU、M.2、USB4 を重視する用途にはよく合っている。しかし、暗号化された複数の 3.5-inch HDD を常時接続し、S.M.A.R.T. を見て、マウント構造を保ち、Samba や NFS で共有する機械では、SATA 直結と HDD ベイの多さが実用上の価値になる。問題は新旧ではなく、用途と設計思想のずれである。

2. 暗号化ストレージは、単にファイルを置く場所ではない

ストレージ中心の汎用データサーバーでは、まずシステム領域を含めて、保存されるデータを原則として暗号化するという前提を置くべきである。ここでいう暗号化は、特定の秘密ファイルだけを暗号化するという意味ではない。OS、ユーザー領域、共有領域、一時ファイル、ログ、キャッシュ、swap、仮想マシンイメージ、アプリケーション設定、鍵ファイル、作業途中のデータを、可能な限り同じ方針のもとで保護するという意味である[17]。暗号化ストレージを扱う機械では、ディスクは単なる容量ではなく、ブロックデバイス、暗号化レイヤー、ファイルシステム、マウントポイント、権限、共有設定が重なった管理対象になる。cryptsetup は plain encrypted volume と LUKS volume を扱うツールであり、LUKS はヘッダーや keyslot を持つため、単なる暗号化だけでなく鍵管理の構造も含む[18]。Linux カーネル側では、dm-crypt が device-mapper の crypt target としてブロックデバイスの透過的な暗号化を提供する[19]。

すべてのデータを暗号化する理由は、秘密に見えるファイルだけが秘密とは限らないからである。文書や写真や動画は分かりやすい。しかし、実際にはシステム領域にも多くの情報が残る。ログにはファイル名、接続元、ユーザー名、エラー、実行履歴が残る。キャッシュには閲覧済みの画像、サムネイル、インデックス、パッケージ情報が残る。swap には、メモリ上にあった断片が書き出されることがある。一時ディレクトリには、展開中のファイル、変換中の画像、編集中の文書、削除前の断片が残ることがある。アプリケーション設定には、接続先、履歴、トークン、秘密鍵、認証情報の痕跡が入ることがある。したがって、データ領域だけを暗号化し、システム領域を平文のまま残すと、保護したつもりの情報が別の場所から漏れる。

領域 含まれやすい情報 暗号化しない場合の問題 方針
ユーザー領域 文書、写真、動画、作業ファイル、設定ファイル、鍵、認証情報が含まれる。 もっとも直接的に個人情報や業務情報が残る。 暗号化対象の中心に置く。
共有領域 LAN 内で共有するファイル、家族や端末間で使うデータ、整理済みアーカイブが含まれる。 複数端末から見えるため、漏れた場合に影響範囲が広がりやすい。 共有する前に、下層のストレージを暗号化する。
システム領域 ログ、設定、サービス情報、接続履歴、パッケージ情報、ユーザー名が含まれる。 データ本体を暗号化しても、行動履歴や構成情報が残る。 OS を含めて暗号化する前提で設計する。
swap メモリ上にあったデータの断片、編集中の文書、秘密情報の一部が書き出されることがある。 アプリケーション側で保存していない情報が平文で残る可能性がある。 swap も暗号化対象に含める。
一時ファイル 展開中のアーカイブ、変換中のファイル、印刷用データ、編集途中のデータが含まれる。 作業後に削除したつもりでも、途中生成物が残ることがある。 一時領域を含むファイルシステムを暗号化された領域に置く。
キャッシュ サムネイル、検索インデックス、ブラウザキャッシュ、パッケージキャッシュが含まれる。 本体データを隠しても、縮小画像や履歴から内容を推測されることがある。 キャッシュを含むシステム全体を暗号化する。
仮想マシンイメージ 別 OS のファイルシステム、作業環境、認証情報、履歴が丸ごと含まれる。 1 ファイルに見えても、中身は別の計算機全体に近い。 保存先を暗号化領域に限定する。

このように見ると、暗号化の対象を「大事なファイル」だけに限定する考え方は危うい。どのファイルが秘密かを人間が毎回正しく判定することは難しい。さらに、秘密ではないと思っていたファイルでも、組み合わせると意味を持つことがある。ファイル名、ディレクトリ名、サムネイル、ログ、アクセス時刻、接続先、マウント名、共有名は、それぞれ単体では小さな情報である。しかし、それらが集まると、生活、仕事、趣味、家族構成、機材構成、運用習慣、保存しているデータの種類を推測できる。したがって、暗号化は個別ファイルの秘密度を判定するための道具ではなく、ストレージ全体を紛失、盗難、廃棄、修理、転用、誤接続から守るための基盤として扱うべきである。

暗号化範囲 一見した利点 実際の弱点 本稿での評価
個別ファイル暗号化 対象を絞れるため、導入しやすい。 一時ファイル、ログ、キャッシュ、ファイル名、メタデータが残りやすい。 補助的には有効だが、データサーバーの基本方針にはしにくい。
ユーザー領域だけの暗号化 個人ファイルを中心に保護できる。 システムログ、swap、キャッシュ、サービス設定、共有設定が残る。 保護範囲が中途半端になりやすい。
データ用 HDD だけの暗号化 大容量データを保護でき、構成も分かりやすい。 OS 側に履歴、マウント情報、サムネイル、作業途中の断片が残る。 保存領域の保護としては有効だが、全体保護には足りない。
システムを含む全体暗号化 OS、ユーザー領域、swap、一時ファイル、ログ、キャッシュをまとめて保護できる。 起動時の解除、鍵管理、復旧手順、ヘッダーバックアップを慎重に設計する必要がある。 汎用データサーバーでは基本方針にしやすい。

システムを含めて暗号化するもう一つの理由は、データサーバーが長く使われる機械だからである。長く使う機械では、データがどこを通ったかを完全には覚えていられない。あるファイルを一時的にデスクトップへ置く。圧縮ファイルを展開する。画像を変換する。動画を一時的に切り出す。ブラウザで管理画面を開く。エディタがバックアップファイルを作る。検索インデックスが作られる。サムネイルが作られる。ログにエラーが残る。こうした動作は、普段は便利で自然である。しかし、暗号化していない領域が混じっていると、便利な補助機能が情報の残留先になる。

特に GUI を提供する汎用データサーバーでは、この問題が大きい。GUI 環境は、サムネイル、最近使ったファイル、ファイルマネージャーの履歴、検索インデックス、アプリケーション設定、ブラウザプロファイルなどを作る。これは利用上は自然であるが、データの痕跡をシステム領域へ広げる。したがって、GUI を使うなら、データ領域だけを暗号化して安心するのではなく、GUI が使うシステム側の領域も暗号化する必要がある。システムを含めた暗号化は、GUI の利便性とストレージ保護を両立させるための前提になる。

GUI が作る情報 具体例 漏れ方 暗号化方針
サムネイル 画像、動画、PDF、スキャンデータの縮小画像である。 元ファイルを暗号化しても、縮小画像から内容を推測できる。 サムネイル保存先を含むユーザー領域を暗号化する。
最近使ったファイル ファイル名、パス、利用履歴である。 ファイル本体がなくても、どのようなデータを扱っていたか分かる。 ホームディレクトリとシステム設定領域を暗号化する。
検索インデックス ファイル名、本文の断片、メタデータである。 検索のために作られた情報が、元データの内容を要約して残る。 インデックス保存先を暗号化領域に置く。
ブラウザプロファイル Cookie、履歴、保存済みセッション、管理画面の URL である。 データサーバーの管理対象や接続先が推測できる。 プロファイルを含むユーザー領域を暗号化する。
アプリケーション設定 接続先、最近開いたディレクトリ、変換設定、作業履歴である。 保存データの種類や作業内容が分かる。 設定ファイルを含むシステム全体を暗号化する。

暗号化の効果は、電源が切れている状態、または暗号化デバイスが解除されていない状態で特に大きい。ディスクを紛失した場合、盗難に遭った場合、故障して修理や RMA に出す場合、廃棄する場合、別の機械へ一時的に接続する場合、暗号化されていないディスクはそのまま読まれる可能性がある。暗号化されていれば、少なくとも保存されているデータ本体を鍵なしで読むことは難しくなる。データサーバーは大容量の保存媒体を複数持つため、1 台ごとのディスクに多くの情報が集まる。だからこそ、ディスク単位で外へ出たときに読めない状態にしておくことが重要になる。

ただし、暗号化は万能ではない。起動中に暗号化デバイスが解除され、ファイルシステムがマウントされ、ユーザーやサービスがアクセスできる状態では、OS 上の権限、サービスの脆弱性、マルウェア、誤操作、共有設定のミスからは守れない。暗号化は、保存媒体がオフラインになったときの防御であり、実行中のシステムをすべて守る防御ではない。したがって、暗号化は権限管理、バックアップ、更新、ネットワーク制限、ログ監視、共有設定と組み合わせて使う必要がある。暗号化を過大評価せず、それでも基礎として必ず置く、という位置づけが重要である。

場面 暗号化が効くこと 暗号化だけでは効かないこと 必要な補助策
ディスク紛失 鍵なしで保存データを読まれにくくする。 弱い passphrase や鍵の保管不備は防げない。 強い passphrase、鍵管理、ヘッダーバックアップの保護が必要である。
盗難 電源断後のディスク内容を保護する。 起動中に盗まれた場合や、自動解除された状態は別問題である。 画面ロック、物理管理、自動解除範囲の制限が必要である。
修理と RMA 故障ディスクを外へ出しても、保存内容を読まれにくくする。 暗号化ヘッダーやメタデータの扱いは設計次第である。 媒体を出す前の判断手順と、鍵を外へ出さない運用が必要である。
廃棄 暗号化鍵を失わせれば、データ本体の復元を難しくできる。 暗号化されていない領域が残っていれば、そこは読まれる。 全体暗号化と、退役前の消去手順を組み合わせる。
稼働中の侵入 解除済みのファイルシステムに対しては基本的に防御にならない。 マルウェア、権限奪取、共有設定ミスは防げない。 OS 更新、権限管理、ネットワーク制限、サービス最小化が必要である。
誤共有 マウント前のデータは守れる。 マウント後に Samba や NFS で公開した範囲は共有設定に従って見える。 共有範囲、権限、ユーザー、グループを整理する必要がある。

システムを含めた暗号化は、物理構成にも影響する。暗号化されたディスクは、開けるか開けないかだけでなく、どの物理ディスクがどの暗号化デバイスに対応するのかを追える必要がある。Debian では cryptsetup パッケージがこの基盤を提供し、ディストリビューションのパッケージ管理下で更新される[20]。起動時に暗号化デバイスを扱う場合は、crypttab が暗号化ブロックデバイスの設定を記述し[21]、systemd-cryptsetup が暗号化デバイスの attach と detach を担う[22]。このため、暗号化はアプリケーションの設定ではなく、起動、デバイス認識、マウント、共有サービスの前提になる。

解除された暗号化デバイスは、最終的にファイルシステムとしてマウントされる。fstab はディスクパーティション、ブロックデバイス、リモートファイルシステムをどのようにファイルシステムツリーへ組み込むかを定義する[23]。ここで重要なのは、暗号化デバイスの名前、マウント先、共有設定が一貫していることである。たとえば、ある HDD を暗号化デバイスとして解除し、所定のディレクトリへマウントし、そのディレクトリを Samba や NFS で共有する場合、物理ディスク、暗号化名、マウントポイント、共有名が対応していなければならない。対応関係が曖昧だと、誤ったディスクを開く、空ディレクトリを共有する、想定外の領域へ書き込むといった事故が起きる。

構成要素 役割 管理上の意味 誤ると起きること
物理ディスク 実際にデータを保持する媒体である。 型番、シリアル、接続ポート、設置ベイを追跡する必要がある。 交換対象や故障対象を取り違える。
LUKS ヘッダー 暗号化ボリュームのメタデータと keyslot を持つ。 鍵管理と復旧可能性に直結する。 ヘッダーを失うと、データ本体が残っていても復号できなくなることがある。
暗号化デバイス名 解除後のブロックデバイスを OS 上で識別する名前である。 マウント先や共有設定と対応付ける必要がある。 別のデバイスを想定した場所へマウントする危険がある。
ファイルシステム 暗号化デバイス上にディレクトリとファイルを作る。 fsck、マウントオプション、権限、容量管理の対象になる。 マウントできず、共有サービスの下層が成立しない。
マウントポイント ファイルシステムを Linux のディレクトリツリーへ組み込む位置である。 共有設定、スクリプト、運用手順の基準になる。 空ディレクトリや別領域を共有することがある。
共有設定 ローカルのマウント済み領域を LAN 内へ公開する。 Samba や NFS の設定とローカル権限を一致させる必要がある。 見えてはいけない範囲が見えたり、書けるべき範囲に書けなかったりする。

全体暗号化では、鍵管理も運用の中心になる。LUKS は keyslot を持つため、複数の passphrase や keyfile を扱える。しかし、鍵を増やせば便利になる一方で、鍵の保管、失効、バックアップ、漏えい時の対応も必要になる。ヘッダーバックアップも重要である。LUKS ではヘッダーと keyslot が暗号化ボリュームの入口であり、ヘッダーを失うとデータ本体が残っていても復号できない場合がある。反対に、ヘッダーバックアップと有効な passphrase があれば、過去の時点の鍵状態から復号できる可能性がある。したがって、ヘッダーバックアップは単なる保険ではなく、強い秘密情報として扱う必要がある。

鍵管理項目 役割 便利な点 危険な点
passphrase 暗号化デバイスを解除するための秘密である。 人間が入力でき、追加や変更もできる。 弱い文字列や使い回しは、全体暗号化の強度を下げる。
keyfile ファイルを鍵として暗号化デバイスを解除する。 自動化や複数デバイスの運用に使いやすい。 keyfile を暗号化されていない領域へ置くと、暗号化の意味が弱くなる。
keyslot 複数の解除手段を LUKS ヘッダー内で管理する。 主鍵、予備鍵、移行用鍵を分けられる。 不要な keyslot を残すと、過去の鍵が攻撃面として残る。
ヘッダーバックアップ LUKS ヘッダー破損時の復旧に備える。 ヘッダー破損から復旧できる可能性を残せる。 有効な passphrase と組み合わせると復号に使えるため、厳重に保護する必要がある。
復旧手順 鍵忘れ、ヘッダー破損、ディスク交換時の対応を定義する。 障害時に慌てず対応できる。 手順がないと、暗号化は安全性ではなく復旧不能性として現れる。

システム全体を暗号化する場合でも、実装上の例外はある。UEFI 環境では、起動に必要な EFI System Partition が平文で存在することがある。構成によっては、ブートローダーや初期起動に必要な領域を完全には暗号化できない、または別の保護策と組み合わせる必要がある。この点は過大に単純化してはならない。ただし、ここでいう「システムも含めてすべてのデータを暗号化する」とは、実装上どうしても必要な最小の起動領域を除き、OS、ユーザー領域、swap、一時領域、ログ、キャッシュ、共有領域、仮想マシンイメージ、データ HDD を、暗号化された管理下へ置くという意味である。

この方針は、ストレージ接続の議論にもつながる。すべてのデータを暗号化するなら、どのディスクがどの暗号化デバイスに対応しているかを安定して観測できなければならない。SATA 直結、S.M.A.R.T.、シリアル番号、ベイ位置、ケーブル、マウントポイントが結びつく理由はここにある。暗号化は、単に秘密を守る技術ではなく、ストレージを管理可能な単位へ分ける技術でもある。だからこそ、USB-SATA 変換のように観測経路が製品依存になる方法は慎重に扱う必要があり、古い多 SATA 環境のように物理ディスクを素直に追える構成には運用上の価値が生まれる。

この章の結論は、暗号化ストレージは単にファイルを置く場所ではないということである。暗号化する対象は、秘密に見えるデータファイルだけでは足りない。システム領域、swap、一時ファイル、ログ、キャッシュ、GUI の履歴、共有設定まで含めて、データはさまざまな場所に残る。したがって、汎用データサーバーでは、システムを含めた全体暗号化を基本方針にし、その上で物理ディスク、暗号化デバイス、ファイルシステム、マウントポイント、権限、共有設定を一つの構造として管理する必要がある。この構造を安定して支えるために、SATA 直結、十分な 3.5-inch ベイ、S.M.A.R.T.、冷却、電源、交換性が重要になる。

3. 速さだけを求めると、構成は見えにくくなる

ストレージを考えるとき、最初に目に入りやすい数字は速度である。NVMe SSD は速い。PCIe 4.0 や PCIe 5.0 に対応した M.2 SSD は、SATA SSD や HDD とは桁の違う帯域を示す。OS の起動、アプリケーションの起動、パッケージ更新、仮想マシン、ビルド、画像処理、動画編集、一時ファイルの展開では、この速度差は体感にも出る。しかし、ストレージ中心の汎用データサーバーでは、速さだけを最上位の評価軸にすると構成を誤る。データサーバーで重要なのは、最速の媒体をどれだけ積めるかではなく、どのデータを、どの媒体に、どの接続経路で、どのように観測しながら運用するかである。

SATA は終わった規格ではない。SATA-IO では Serial ATA Revision 3.5a Specification が 2021 年に示されており、HDD や SATA SSD を接続する基盤として現役である[24]。一方で、NVMe は PCIe 経由の不揮発性メモリを効率よく扱うための仕様であり、SATA のような従来型インターフェースより低遅延で、SSD に対してスケーラブルな接続を提供する[25]。つまり、SATA と NVMe は、同じ「ストレージ接続」ではあっても、前提としている媒体と用途が違う。SATA は HDD や SATA SSD を扱う成熟した接続であり、NVMe は高速な半導体ストレージを PCIe 上で効率よく扱う接続である。

接続方式 主な対象 強い用途 弱い用途 データサーバーでの位置づけ
SATA 3.5-inch HDD、2.5-inch SATA SSD、光学ドライブなどである。 大容量 HDD の直結、S.M.A.R.T. 取得、長期運用、交換可能な保存層に向く。 低遅延のランダム I/O や、複数 GB/s 級の高速処理には向かない。 暗号化された大容量データ領域を安定して接続する下層として使う。
NVMe M.2 SSD、U.2 SSD、AIC SSD、EDSFF SSD などである。 OS、アプリケーション、一時領域、仮想マシン、ビルド、低遅延 I/O に向く。 3.5-inch HDD の物理的な置き場や交換性を代替するものではない。 システム領域や高速作業領域として使い、HDD の保存層と分ける。
USB4 外付け SSD、ドック、ディスプレイ、複合デバイスなどである。 高速な外部接続、機器集約、一時的な大容量転送に向く。 内蔵 HDD を単純な経路で常時観測する用途では、ブリッジや外付け筐体が追加層になる。 補助的な高速外部 I/O として扱い、常用 HDD の基本経路とは分ける。

速度を数字で見ると、NVMe や USB4 の優位は明確である。SATA 6Gb/s の理論上の最大転送速度は、符号化などを考慮した実効上限として約 600 MB/s の世界である。一方、PCIe 4.0 x4 や PCIe 5.0 x4 の NVMe SSD は、数 GB/s から 10 GB/s を超える帯域を示す製品がある。USB4 も 40Gbps や 80Gbps の世代へ進んでおり、USB Type-C を使う外部接続の速度は大きく伸びている[26]。この比較だけを見ると、SATA は遅く、古い接続に見える。

しかし、ここで比較しているのは接続規格の理論帯域であり、データサーバーで扱う実データの性質とは別である。3.5-inch HDD の逐次転送速度は、現行の高容量 NAS 向け HDD でもおおむね数百 MB/s の範囲にある。これは SATA 6Gb/s の実効帯域を使い切るほどではない。したがって、HDD を接続するという用途では、SATA 6Gb/s は規格として極端に不足しているわけではない。HDD に対して問題になるのは、接続帯域よりも、台数、冷却、電源、振動、S.M.A.R.T.、長時間 I/O、交換性である。

評価対象 速度面の特徴 見落としやすい点 結論
SATA 6Gb/s NVMe や USB4 と比べると理論帯域は小さい。 3.5-inch HDD の逐次転送では、SATA 6Gb/s が直ちにボトルネックになるわけではない。 HDD の直結には今でも実用的である。
NVMe SSD 低遅延かつ高帯域で、ランダム I/O に強い。 高速であることと、大容量 HDD の物理的な交換性を持つことは別である。 OS と作業領域には強いが、3.5-inch HDD の保存層とは役割が違う。
USB4 外部接続として非常に高速である。 外付けストレージでは、USB ブリッジ、ケーブル、電源、筐体、熱が追加される。 高速な補助経路として有効だが、内蔵 HDD の管理経路とは性格が違う。
3.5-inch HDD NVMe SSD より大幅に遅く、ランダム I/O に弱い。 大容量、交換性、常時保存、S.M.A.R.T. による観測という強みがある。 高速作業層ではなく、大容量保存層として評価するべきである。

速度だけを基準にすると、すべてを NVMe SSD に置き換えればよいように見える。しかし、これはデータサーバーの構造を単純化しすぎている。データサーバーでは、OS、作業領域、共有データ、アーカイブ、暗号化ボリューム、交換予定ディスク、検査対象ディスクが同じ性格を持たない。OS は低遅延が効く。仮想マシンはランダム I/O が効く。動画や写真の長期保存は容量が効く。暗号化された大容量データ領域では、長時間安定して接続され、状態を観測できることが効く。つまり、速さは一つの評価軸にすぎず、保存層の評価軸とは一致しない。

データの種類 主な I/O 特性 向いている媒体 理由
OS とアプリケーション 小さなランダム読み書きと多数のメタデータ操作が多い。 NVMe SSD 低遅延とランダム I/O 性能が体感に直結する。
パッケージキャッシュと作業用一時領域 展開、削除、更新、再生成が多い。 NVMe SSD 高速に作って消す領域であり、容量単価より応答性が重要になる。
仮想マシン 小さなランダム I/O が継続的に発生する。 NVMe SSD HDD に置くと体感が大きく悪化し、共有データの I/O と干渉しやすい。
写真と動画の元データ 大きなファイルの逐次読み書きが中心である。 3.5-inch HDD 容量単価、交換性、長期保存性が効きやすい。
文書とアーカイブ 頻繁な更新より、長期保存と検索が中心である。 3.5-inch HDD 常時接続された大容量保存層として扱いやすい。
暗号化データ領域 大容量で、長時間マウントされ、共有サービスの下層になる。 3.5-inch HDD または SATA SSD 速度だけでなく、物理ディスクと暗号化デバイスの対応を追えることが重要である。
臨時検査ディスク S.M.A.R.T.、long test、全域読み取り、消去前確認が中心である。 SATA 直結または検証済み USB-SATA ファイル転送速度より、状態観測と接続安定性が重要になる。

このように分けると、SATA と NVMe の関係は競争ではなく役割分担になる。NVMe SSD は、OS、作業領域、仮想マシン、一時処理に向く。SATA HDD は、大容量の保存層、共有データ、長期保管、暗号化データ領域に向く。SATA SSD は、HDD より低遅延で、NVMe ほど高速ではないが、SATA ポートで扱える中間的な媒体として使える。したがって、データサーバーでは、最速の媒体に統一するのではなく、媒体ごとの得意分野を分けることが重要になる。

ここで暗号化ストレージの観点が加わる。暗号化されたデータ領域は、単なるフォルダではない。物理ディスク、暗号化ヘッダー、解除名、ファイルシステム、マウントポイント、権限、共有設定が結びついている。NVMe SSD に置くか、SATA HDD に置くかという判断は、速度だけでは決められない。大容量データを HDD に置く場合、重要なのは、ディスク本体を識別できること、S.M.A.R.T. を取れること、長時間の読み書きに耐えること、交換時にどの物理ディスクかを間違えないこと、マウント先が安定していることである。

暗号化ストレージの要素 速度だけでは見えない問題 SATA 直結が有利になる理由
物理ディスクの識別 どの HDD がどの暗号化デバイスに対応するかを追う必要がある。 OS からディスク本体の情報を確認しやすく、ラベルやポートと対応付けやすい。
S.M.A.R.T. 媒体の劣化、温度、稼働時間、自己診断結果を確認する必要がある。 USB ブリッジを挟まないため、情報取得と切り分けが比較的単純である。
長時間 I/O 初期化、全域検査、コピー、暗号化領域の作成には長時間かかる。 ケース内の電源と冷却に組み込めるため、外付け電源や USB ケーブルの影響を受けにくい。
マウント構造 暗号化解除後のファイルシステムを、常に同じ場所へ載せる必要がある。 固定された内蔵ディスクとして扱いやすく、接続順や外付け機器の揺れを減らせる。
障害切り分け エラー発生時に、媒体不良、接続不良、電源、ファイルシステムを分ける必要がある。 接続経路が短く、疑うべき層を減らせる。

高速な外部接続にも価値はある。USB4 や Thunderbolt は、外付け SSD、ドッキングステーション、高速カードリーダー、ノート PC との接続では強力である。短時間で大きなデータを移す用途では、高速外部 I/O は便利である。しかし、外部接続は内蔵 SATA 直結とは性格が違う。外付けストレージでは、USB-SATA ブリッジ、外付け筐体、外部電源、ケーブル、ファームウェア、スリープ制御、UAS の相性が追加される。理論帯域が高くても、暗号化された常用データ領域を長時間マウントし、S.M.A.R.T. を継続的に確認し、障害時に原因を切り分ける用途では、追加層の少なさが効く。

評価軸 高速外部 I/O が有利な場面 SATA 直結が有利な場面 判断
短時間転送 外付け SSD から大容量データを一気に取り込む場面で有利である。 HDD 間の通常転送では、HDD 自体の速度が上限になりやすい。 一時的な高速転送には外部 I/O が向く。
常時マウント ケーブル、ブリッジ、外部電源を安定管理できるなら使える場合がある。 内蔵電源とケース冷却に組み込めるため、常用経路として説明しやすい。 暗号化データ領域の常用には SATA 直結が自然である。
S.M.A.R.T. 観測 対応ブリッジなら取得できる。 ディスク本体を直接観測しやすい。 媒体状態の継続確認では SATA 直結が扱いやすい。
障害時の切り分け 外付け筐体、USB ケーブル、ブリッジ、電源も疑う必要がある。 ディスク、SATA ケーブル、電源、ポートへ疑う範囲を絞りやすい。 データサーバーでは、原因を狭められることが重要である。
交換性 ドックや外付けケースなら抜き差しは容易である。 ケース内ベイに固定するため、頻繁な抜き差しには向かない。 臨時作業は外付け、常用保存層は内蔵で分ける。

市場の注目が M.2、PCIe、USB4 へ移っていることは、最新の PC にとっては自然である。小型で高速な SSD は配線が不要で、ケース内の空気の流れを妨げず、大型 GPU やラジエータとも組み合わせやすい。USB Type-C と USB4 は、外部機器の接続をまとめ、高速な転送やドック機能を提供する。これらは明確な進歩である。しかし、その進歩は「3.5-inch HDD を複数直結し、暗号化データ領域として常時運用する」用途を自動的に改善するわけではない。進歩の方向と、データサーバーの必要条件は別である。

ここまでを定量的に見ると、誤解がほどける。SATA 6Gb/s は、NVMe や USB4 と比べれば遅い。しかし、HDD の実転送速度に対してはなお十分な場面が多い。NVMe は、SATA より高速で低遅延だが、3.5-inch HDD の大容量保存層、交換性、S.M.A.R.T. 観測、物理ベイを代替するものではない。USB4 は高速だが、外付けストレージではブリッジ、筐体、電源、ケーブルが増える。したがって、単純に「速いものが正しい」とは言えない。

誤解 実際の整理 データサーバーでの結論
SATA は古いので不要である SATA は高速 SSD の主役ではなくなったが、HDD 接続では今も実用的である。 3.5-inch HDD を常用するなら、SATA 直結は基本経路として残る。
NVMe が速いので HDD は不要である NVMe は高速作業層に強く、HDD は大容量保存層に強い。 両者は置き換えではなく、役割分担で考える。
USB4 が速いので外付けでよい 外付けは便利だが、ブリッジ、電源、筐体、ケーブル、S.M.A.R.T. の問題が加わる。 臨時作業や高速転送には有効だが、常用暗号化データ領域とは分ける。
速度が上がれば運用も良くなる 運用では、観測可能性、再現性、冷却、電源、交換性、障害切り分けが効く。 ストレージ中心の機械では、速さだけでなく構成の見通しを重視する。

この章の結論は、速さは重要だが、速さだけではデータサーバーの構成を決められないということである。NVMe SSD は、OS、アプリケーション、作業用一時領域、仮想マシンに使うべきである。USB4 は、外付け SSD や一時的な高速転送に使うべきである。SATA HDD は、大容量保存層、暗号化データ領域、LAN 内共有の下層として使うべきである。それぞれの媒体と接続方式を役割ごとに分けることで、性能と運用性の両方を得られる。

したがって、暗号化された 3.5-inch HDD をサーバー内部に固定して常用するなら、SATA 直結には固有の価値がある。高速な外部接続は理論上の帯域を提供するが、USB-SATA ブリッジ、外付け筐体、電源、ケーブル、ファームウェアという複数の層を増やす。暗号化デバイスの解除、S.M.A.R.T. の確認、長時間の読み書き、障害時の切り分けを考えると、経路が単純であること自体が実用上の価値になる。速さを否定する必要はない。ただし、ストレージ中心の汎用データサーバーでは、速さだけを求めると、構成の見通しがかえって悪くなる。

4. 最近のマザーボードでは、SATA は少数の補助線になりやすい

現行の一般向けマザーボードでは、SATA が消えたわけではない。しかし、SATA は主役ではなく、NVMe SSD を補うための少数の接続口として残される傾向が強い。この傾向を確認するために、AMD AM5 と Intel LGA1851/LGA1700 の一般向け製品から、B 系、X 系、Z 系、ATX、microATX を混ぜて 14 製品を拾い、M.2 スロット数と SATA ポート数を比較した。対象は、ゲーミング向け、標準 ATX、microATX を含むが、サーバー用、ワークステーション用、産業用の特殊なマザーボードは除いた。

製品 世代・チップセット フォームファクター M.2 スロット数 SATA ポート数 読み取れる傾向
ASUS TUF GAMING B650-PLUS WIFI AMD B650 ATX 3 4 AM5 の中位構成では、M.2 を複数持ちながら SATA は 4 本に整理されている[27]。
ASUS TUF GAMING X870-PLUS WIFI AMD X870 ATX 4 2 X870 世代では M.2 が 4 本に増える一方、SATA は 2 本まで減る例がある[28]。
ASUS ROG STRIX X870E-E GAMING WIFI AMD X870E ATX 5 4 上位製品では M.2 が 5 本まで増えるが、SATA は 4 本にとどまる[29]。
MSI MAG B850 TOMAHAWK MAX WIFI AMD B850 ATX 4 4 新しい B850 世代でも、M.2 は 4 本、SATA は 4 本という構成が標準的である[30]。
ASRock B850 Steel Legend WiFi AMD B850 ATX 4 4 B850 でも M.2 4 本と SATA 4 本の組み合わせが確認できる[31]。
GIGABYTE X870 AORUS ELITE WIFI7 AMD X870 ATX 4 4 X870 では PCIe 5.0 M.2 と USB4 が強調され、SATA は 4 本に整理されている[32]。
MSI MAG B760 TOMAHAWK WIFI Intel B760 ATX 3 4 LGA1700 世代でも、M.2 3 本と SATA 4 本の構成が一般的である[33]。
ASUS PRIME B860M-A WIFI Intel B860 microATX 2 4 microATX では M.2 が 2 本に減るが、SATA は 4 本を残す構成もある[34]。
MSI B860 GAMING PLUS WIFI Intel B860 ATX 3 4 B860 世代の ATX 製品では、M.2 3 本と SATA 4 本の組み合わせが確認できる[35]。
ASRock B860 Steel Legend WiFi Intel B860 ATX 4 4 B860 の中でも上位寄りの製品では、M.2 4 本と SATA 4 本を備える[36]。
GIGABYTE B860M AORUS ELITE WIFI6E Intel B860 microATX 3 4 microATX でも M.2 3 本と SATA 4 本を備える製品がある[37]。
MSI MAG Z890 TOMAHAWK WIFI Intel Z890 ATX 4 4 Z890 世代では Thunderbolt 4 や Wi-Fi 7 と並んで M.2 4 本が用意されるが、SATA は 4 本である[38]。
ASUS ROG STRIX Z890-E GAMING WIFI Intel Z890 ATX 7 4 上位製品では M.2 が 7 本まで増える一方、SATA は 4 本にとどまる[39]。
GIGABYTE Z890 AORUS ELITE WIFI7 Intel Z890 ATX 4 4 Z890 の一般的な ATX 製品でも、M.2 4 本と SATA 4 本の構成が確認できる[40]。

この 14 製品だけを標本として数えると、SATA ポート数の平均は 3.86 本、中央値は 4 本、最頻値も 4 本である。SATA が 4 本の製品は 14 製品中 13 製品で、割合は 92.9% である。SATA が 6 本以上の製品は 0 製品であり、少なくともこの標本では確認できない。一方、M.2 スロット数の平均も 3.86 本だが、分布の意味は SATA と異なる。M.2 は 2 本から 7 本まで広がり、4 本以上の製品は 14 製品中 9 製品、割合は 64.3% である。つまり、SATA は 4 本で頭打ちになりやすく、上位製品では SATA を増やすより M.2 を増やす方向へ設計資源が向かっている。

集計項目 M.2 スロット SATA ポート 読み取れること
標本数 14 製品 14 製品 AMD AM5、Intel LGA1851/LGA1700、ATX、microATX を混ぜた一般向け標本である。
平均 3.86 本 3.86 本 平均だけを見ると同数に見えるが、分布を見ると M.2 は上位製品で伸び、SATA は 4 本に集中している。
中央値 4 本 4 本 典型的な現行一般向けマザーボードは、M.2 4 本前後、SATA 4 本前後として設計されている。
最大値 7 本 4 本 上位製品で増えるのは SATA ではなく M.2 である。
6 本以上 1 製品 0 製品 多数の内蔵ストレージを増やす方向は、SATA ではなく M.2 側に現れている。
4 本固定 6 製品 13 製品 SATA は 4 本が事実上の標準枠になっている。

この結果から導ける第一の傾向は、SATA の標準本数が 4 本に収束していることである。4 本あれば、一般的なデスクトップ用途では不足しにくい。OS 用に NVMe SSD を使い、SATA SSD や HDD を 1 台から 2 台足す程度なら、4 本の SATA は十分である。しかし、ストレージ中心の汎用データサーバーでは、4 本は余裕ではなく最低限に近い。OS 用 SSD を M.2 に逃がしたとしても、常用データ用 HDD、増設 HDD、交換予定 HDD、検査対象 HDD、移行元 HDD、移行先 HDD を同時に扱う場面では、4 本ではすぐに作業順序の制約が出る。

第二の傾向は、上位チップセットや高価な製品ほど SATA が増えるわけではないことである。たとえば X870E や Z890 の上位製品では、M.2 スロット、USB4、Thunderbolt 4、Wi-Fi 7、高速 LAN、M.2 ヒートシンク、工具不要の M.2 固定機構などが増える。しかし、SATA は 4 本のまま残るか、製品によっては 2 本まで減る。このことは、メーカーが上位製品の付加価値を「多数の 3.5-inch HDD を内蔵できること」ではなく、「高速な NVMe SSD を複数載せられること」や「高速外部 I/O を備えること」に置いていることを示す。

第三の傾向は、M.2 の増加が必ずしも単純な拡張性を意味しないことである。M.2 は高速で小さく、配線も不要であるため、現代の PC には非常に向いている。しかし、M.2 スロットは CPU やチップセットの PCIe レーンを消費し、製品によっては PCIe x16 スロット、別の M.2 スロット、USB4、下位 PCIe スロットと帯域を共有する。たとえば ASUS TUF GAMING B650-PLUS WIFI では M.2_3 と PCIEX16_2 の共有が示され、ASUS TUF GAMING X870-PLUS WIFI では M.2_2 と PCIEX16(G5)、M.2_4 と PCIEX16(G4) の共有または無効化が示されている[27][28]。したがって、M.2 が多いことは、HDD を多数直結できることとは別の拡張性である。

観点 現行一般向けマザーボードで起きていること 汎用データサーバーでの意味
SATA の本数 標本では 4 本に集中し、6 本以上の製品は確認できない。 3.5-inch HDD を複数直結し、交換や検査も同時に行う用途では余裕が少ない。
M.2 の本数 中位製品でも 3 本から 4 本、上位製品では 5 本から 7 本まで増える。 システム領域や高速作業領域には有効だが、3.5-inch HDD の物理的な接続口にはならない。
高速外部 I/O USB4、Thunderbolt 4、USB Type-C、高速 LAN、Wi-Fi 7 が訴求点になっている。 外部機器との高速転送には有効だが、内蔵 HDD を単純な経路で常時管理する価値とは別である。
帯域共有 M.2、PCIe、USB4、下位 PCIe スロットが共有または排他になる場合がある。 仕様表上のスロット数だけではなく、同時利用時の制約まで確認しないと運用設計を誤る。

ここで重要なのは、現行マザーボードが劣化したという話ではない。現在の一般向けマザーボードは、OS、ゲーム、制作アプリケーション、AI PC、外部高速 I/O、無線通信、大型 GPU を中心にした構成へ合理的に最適化されている。その結果として、SATA は「残すべき互換的な接続口」ではあるが、「多数の 3.5-inch HDD を内蔵して管理するための中心的な接続基盤」ではなくなっている。

暗号化ストレージを扱う汎用データサーバーでは、この差が実運用に直結する。暗号化ディスクは、単に差せばよい媒体ではなく、物理ディスク、暗号化デバイス、ファイルシステム、マウントポイント、共有設定が結びついた管理対象である。SATA が少なければ、ディスク交換のたびに接続を入れ替える必要が生じる。接続を入れ替えれば、対象ディスクの取り違え、デバイス名の変動、マウント先の誤認、S.M.A.R.T. 確認漏れが起こりやすくなる。ストレージ運用における余裕とは、容量の余裕だけではなく、同時に安全に見えるディスク数の余裕でもある。

5. ケースは外装ではなく、ストレージの運用条件である

ケースの変化も、マザーボードの SATA ポート数と同じ方向を向いている。現在の一般向けケースでは、3.5-inch HDD を大量に内蔵することよりも、大型 GPU、前面メッシュ、簡易水冷ラジエータ、裏配線、強化ガラス、見た目の整理が優先されやすい。この傾向を確認するために、現行または現在も製品ページで確認できる ATX、microATX、ミドルタワー、フルタワー系ケースから 16 製品を拾い、3.5-inch HDD 搭載数、2.5-inch SSD 搭載数、5.25-inch ベイの有無を比較した。対象には、エアフロー重視の主流ケース、デザイン重視のケース、ストレージ搭載性を残したケースを混ぜている。

製品 性格 3.5-inch 搭載数 2.5-inch 搭載数 5.25-inch ベイ 読み取れる傾向
NZXT H5 Flow 2024 エアフロー重視 ATX 1 2 なし 前面吸気、GPU、ラジエータを優先する現代的な構成では、3.5-inch HDD は 1 基までに抑えられている[41]。
NZXT H7 Flow 2024 大型エアフロー ATX 2 2+2 なし 大型化して冷却余地は増えても、3.5-inch HDD は 2 基にとどまる[42]。
Corsair 4000D Airflow 定番エアフロー ATX 2 4 なし 主流のミドルタワーでは、2 基の 3.5-inch HDD と複数の 2.5-inch SSD を組み合わせる構成が標準的である[43]。
Corsair FRAME 5000D RS ARGB 大型高エアフロー ATX 2 6 なし 筐体が大きくなっても、増えるのは 2.5-inch SSD 側であり、3.5-inch HDD は 2 基に抑えられている[44]。
Lian Li LANCOOL 216 エアフロー重視 ATX 2 6 なし 大型ファンと冷却を重視するケースでは、HDD ケージは残るが、3.5-inch HDD の標準枠は 2 基である[45]。
Montech AIR 903 MAX 低価格高エアフロー ATX 2 5 なし 価格性能比と冷却を重視するケースでも、3.5-inch HDD は 2 基、2.5-inch SSD は 5 基という配分である[46]。
DeepCool CH560 高エアフロー ATX 2 2+1 なし 前面 140 mm ファンを複数備える冷却重視ケースでは、HDD は 2 基程度に収まる[47]。
be quiet! Pure Base 501 静音・標準 ATX 2 5 なし 静音寄りの標準ケースでも、3.5-inch HDD の上限は 2 基であり、2.5-inch SSD のほうが多く用意される[48]。
Fractal Design North デザイン重視 ATX 2 2 なし 木材調フロントと見た目を重視するケースでも、3.5-inch/2.5-inch 兼用マウント 2 基に整理されている[49]。
Fractal Design Pop Air エアフロー重視 ATX 2 4 あり 隠し 5.25-inch ベイを残す例外的な製品だが、3.5-inch HDD は 2 基が中心である[50]。
Lian Li O11 Dynamic EVO ショーケース型大型 ATX 6 9 なし デュアルチャンバー構造を活かし、例外的に最大 6 基の 3.5-inch HDD を収められる[51]。
Fractal Design Define 7 ストレージ重視 ATX 14 4 なし ストレージレイアウトへ切り替えることで、最大 14 基の HDD と 4 基の SSD を搭載できる[52]。
Fractal Design Define 7 XL ストレージ重視フルタワー 18 5 あり フルタワーでは最大 18 基の HDD/SSD と 5 基の SSD を搭載でき、明確にストレージサーバー寄りの設計である[53]。
Cooler Master MasterBox CM694 ストレージ重視 ATX 6 6 あり 2.5-inch/3.5-inch コンボベイを 6 基備え、ストレージ搭載性を残すケースとして位置づけられる[54]。
Fractal Design Pop XL Air 大型エアフロー ATX 6 4 あり 大型化と 5.25-inch ベイにより、主流エアフローケースより多くの 3.5-inch HDD を扱える[55]。
Lian Li O11 Dynamic EVO XL 大型ショーケース型 ATX 4 7 なし 大型ケースでも、3.5-inch HDD より 2.5-inch SSD と見せる構成に寄る例である[56]。

この 16 製品だけを標本として数えると、3.5-inch HDD 搭載数の平均は 4.56 基、中央値は 2 基、最頻値も 2 基である。平均だけを見ると 4 基以上あるように見えるが、これは Define 7、Define 7 XL、O11 Dynamic EVO、MasterBox CM694、Pop XL Air のようなストレージ搭載性の高い製品が平均を押し上げているためである。実際には、3.5-inch HDD が 2 基以下のケースは 16 製品中 10 製品で、割合は 62.5% である。反対に、6 基以上の 3.5-inch HDD を扱えるケースは 16 製品中 5 製品で、割合は 31.3% にとどまる。

集計項目 3.5-inch HDD 2.5-inch SSD 読み取れること
標本数 16 製品 16 製品 エアフロー重視、デザイン重視、ストレージ重視の現行ケースを混ぜた標本である。
平均 4.56 基 4.75 基 ストレージ重視ケースが平均を押し上げるため、平均値だけでは主流ケースの実態を読み誤る。
中央値 2 基 4.5 基 典型的なケースでは、3.5-inch HDD は 2 基、2.5-inch SSD は 4 基から 5 基程度として扱われる。
最頻値 2 基 5 基 現在のケース設計では、3.5-inch HDD より 2.5-inch SSD のほうが多く配置されやすい。
2 基以下 10 製品 2 製品 3.5-inch HDD は、多くのケースで 1 基から 2 基の補助的な搭載枠になっている。
6 基以上 5 製品 5 製品 多ドライブ構成は不可能ではないが、製品を明確に選ぶ必要がある。
5.25-inch ベイあり 4 製品 対象外 光学ドライブやリムーバブルベイを使えるケースは少数派になっている。

この結果から導ける第一の傾向は、主流ケースでは 3.5-inch HDD が 2 基前後に収束していることである。NZXT H5 Flow 2024 は 1 基、H7 Flow 2024、Corsair 4000D Airflow、Corsair FRAME 5000D、LANCOOL 216、Montech AIR 903 MAX、DeepCool CH560、Pure Base 501、Fractal North は 2 基である。つまり、現在のケース設計では、HDD は「大量に並べるもの」ではなく、「必要なら少数を入れるもの」として扱われやすい。

第二の傾向は、ケースが大きくなっても、必ずしも 3.5-inch HDD が増えるわけではないことである。大型ケースでは、前面 360 mm または 420 mm ラジエータ、上面ラジエータ、大型 GPU、縦置き GPU、裏配線、ファンハブ、ガラスパネル、デュアルチャンバー構造が優先される場合がある。そのため、筐体容量が増えても、HDD ケージではなく、ラジエータ空間、ケーブル空間、見せる空間、2.5-inch SSD マウントへ配分される。

第三の傾向は、ストレージ搭載性を持つケースが消えたのではなく、明確な選択対象になったことである。Define 7、Define 7 XL、MasterBox CM694、Pop XL Air、O11 Dynamic EVO のように、6 基以上の 3.5-inch HDD を扱えるケースは存在する。しかし、これらは一般的なエアフローケースの標準ではない。ストレージ中心の汎用データサーバーを組む場合、ケース選びは「ATX が入るか」では足りず、「3.5-inch HDD を何基、どの位置に、どの冷却条件で、どの配線余裕で固定できるか」を確認する作業になる。

観点 現行ケースで起きていること 汎用データサーバーでの意味
3.5-inch HDD 主流エアフローケースでは 1 基から 2 基に抑えられやすい。 複数 HDD を常時内蔵し、交換や検査も行う用途では、ケース選定の時点で不足が出る。
2.5-inch SSD 背面トレイや PSU シュラウド周辺に複数配置されやすい。 システム領域や作業領域には便利だが、3.5-inch HDD の容量単価や交換性とは別の役割である。
5.25-inch ベイ 多くのケースでは廃止され、残っている製品は少数派である。 光学ドライブ、リムーバブルラック、前面アクセス型ベイを使いたい場合、選べるケースが限られる。
冷却空間 前面メッシュ、大型ファン、ラジエータ、GPU 冷却が優先される。 HDD ケージを追加すると、前面吸気やラジエータ配置と競合することがある。
交換性 見た目と裏配線を優先するケースでは、HDD へのアクセスが奥まった位置になりやすい。 ディスク交換、S.M.A.R.T. 確認、ラベル確認、ケーブル確認の作業性が運用負荷に直結する。

3.5-inch HDD は、M.2 SSD や 2.5-inch SSD と違って、発熱し、振動し、SATA ケーブルと電源ケーブルを必要とし、物理的な固定面積を取る。したがって、HDD をデータサーバーの主要な保存媒体として扱うなら、単に仕様表に「3.5-inch 対応」と書かれているだけでは足りない。ドライブが前面吸気の風を受けるか、隣接する HDD と間隔があるか、ケーブルを無理なく曲げられるか、ディスク交換時に GPU やラジエータを外さずに済むか、振動をケース全体へ伝えにくい固定構造かを見なければならない。

ここで重要なのは、最近のケースが劣化したという話ではない。現在のケースは、冷却性能、組みやすさ、見た目、裏配線、USB Type-C、ガラスパネル、大型 GPU 対応という目的に対して合理的に進化している。その結果として、3.5-inch HDD を多数内蔵する用途は、主流設計の中心から外れた。ストレージ中心の汎用データサーバーでは、この市場の変化を前提にし、ケースを外装ではなくストレージの運用条件として評価する必要がある。

十年以上前のケースに 3.5-inch ベイが多く、SATA ケーブルと電源ケーブルを引き回す余裕があり、前面から HDD に風を当てやすい構造が残っているなら、それは単なる古い箱ではない。暗号化された複数の HDD を直接扱い、状態を確認し、必要に応じて交換し、LAN 内で共有する汎用データサーバーでは、その物理的な余裕そのものが運用資産になる。

6. USB-SATA 変換は便利だが、観測可能性を落とすことがある

裸の HDD を一時的に接続できる USB-SATA 変換機器やドックは便利である。ディスクの内容確認、短期のコピー、退避、初期化、消去前確認、臨時接続には向いている。しかし、暗号化されたストレージを汎用データサーバーの管理対象として扱う場合、USB 経由の接続は、単なる接続方式の違いでは済まない。SATA 直結では、マザーボード上の SATA コントローラ、Linux の ATA/SATA ドライバ層、ディスク本体という比較的単純な経路で HDD を扱う。一方、USB-SATA 変換では、OS と HDD の間に USB ホストコントローラ、USB ストレージドライバ、USB-SATA ブリッジ、ブリッジのファームウェア、外付け側の電源回路が入る。接続できることと、安定して観測できることは同じではない。

Linux で SATA デバイスを扱う基盤には libATA がある。libATA は Linux カーネル内部で ATA ホストコントローラと ATA デバイスを支える層であり、ATA/SATA デバイスを OS から扱うための基本的な経路になる[57]。S.M.A.R.T. 情報の取得は smartmontools の領域であり、smartmontools は smartctl と smartd によってストレージの自己診断情報を扱う[58]。ただし USB 接続では、HDD が直接 ATA デバイスとして見えるわけではない。USB ブリッジが ATA または NVMe の pass-through を提供し、それを smartmontools が扱える場合に、S.M.A.R.T. 情報を取得できる[59]。smartmontools は USB デバイスごとに成功例と失敗例を整理しており、USB 接続では製品ごとの実装差が問題になることが分かる[60]。

接続経路 主な構成層 層の数 観測上の意味
SATA 直結 Linux、libATA、SATA コントローラ、HDD 本体で構成される。 4 層 経路が単純で、ディスク本体の状態を OS から追いやすい。
USB-SATA 変換 Linux、USB ホスト、USB ストレージドライバ、USB-SATA ブリッジ、ブリッジファームウェア、HDD 本体で構成される。 6 層 途中にブリッジが入るため、S.M.A.R.T.、エラー、電源管理、切断時の挙動が製品ごとに変わりうる。
外付け HDD ケース USB-SATA 変換に加えて、外付け筐体、外部電源、冷却、スリープ制御が加わる。 7 層以上 机上では扱いやすいが、常時運用では筐体側の電源、冷却、ファームウェアの品質が観測結果に混じる。

この比較から分かるのは、USB-SATA 変換がただちに危険だということではない。問題は、観測対象が増え、切り分けが難しくなることである。SATA 直結で読み書きが不安定なら、ディスク、ケーブル、SATA ポート、電源、ファイルシステムを順に疑えばよい。USB-SATA 変換では、そこに USB ポート、USB ケーブル、USB ハブ、USB-SATA ブリッジ、UAS、usb-storage、ブリッジファームウェア、外付け電源、ケース内温度が加わる。障害点が増えるほど、データサーバーとしての管理は複雑になる。

特に重要なのは、S.M.A.R.T. が通るかどうかである。S.M.A.R.T. は、HDD や SSD が内部に持つ自己診断情報を読み出す仕組みであり、温度、稼働時間、代替処理済みセクタ、保留中セクタ、エラーログ、自己診断結果を確認する入口になる。データサーバーでは、ファイルが読めるかどうかだけではなく、媒体が劣化しつつあるか、長時間試験に通るか、エラーが蓄積しているかを見なければならない。USB ブリッジ経由で S.M.A.R.T. が取得できない、取得できても一部の情報が欠ける、特定の指定が必要になる、という状態では、媒体の判断材料が減る。

観測項目 SATA 直結 USB-SATA 変換 データサーバーでの意味
モデル名とシリアル番号 取得しやすい。 ブリッジ実装により、ディスク本体ではなくブリッジ側の情報が前面に出ることがある。 物理ディスクと暗号化デバイスを対応付ける基礎情報になる。
S.M.A.R.T. 属性 取得しやすい。 SAT pass-through などに対応していれば取得できるが、製品差がある。 代替処理済みセクタ、保留中セクタ、温度、稼働時間を確認するために必要である。
自己診断 short test と long test を扱いやすい。 実行できる場合もあるが、ブリッジや接続断の影響を受ける。 新規投入、継続使用、退役判断の材料になる。
温度 ディスク本体の温度を確認しやすい。 取得できる場合もあるが、筐体側の冷却状態と切り分ける必要がある。 常時稼働する HDD では、冷却不足の早期発見に関係する。
エラーログ ATA エラーやリンクリセットを追いやすい。 USB 側のリセット、UAS、ブリッジ、ディスク本体のどこで起きたか切り分けが難しくなる。 障害時に、媒体不良か接続経路不良かを判断するために重要である。
電源管理 OS とディスクの関係を比較的追いやすい。 外付けケースやドック側のスリープ制御が加わることがある。 暗号化ボリュームを常時マウントする環境では、意図しない停止や復帰失敗が問題になる。
接続の再現性 同じ SATA ポートに固定しやすい。 USB ポート、ハブ、ケーブル、接続順により見え方が変わることがある。 crypttab、fstab、共有設定と物理ディスクを対応付けるうえで重要である。
長時間 I/O ケース内電源と冷却が安定していれば継続しやすい。 USB ケーブル、外付け電源、ブリッジ温度、UAS の相性が影響する。 大容量コピー、検査、暗号化ディスクの初期化、ファイル整理で差が出る。

この表を 8 項目の観測可能性として見ると、SATA 直結では 8 項目すべてを比較的素直に扱える。一方、USB-SATA 変換では、S.M.A.R.T. 属性、自己診断、温度、エラーログ、電源管理、接続の再現性、長時間 I/O のうち、どれが安定するかは製品ごとに変わる。したがって、USB-SATA 変換は「使えるか使えないか」の二分法で見るべきではない。短時間のコピーに使えること、S.M.A.R.T. を取得できること、long test を通せること、常時マウントできることは別の段階である。

用途 USB-SATA 変換の適性 理由
内容確認 高い。 一時的に接続してディレクトリ構成や必要なファイルを確認する用途では、接続の手軽さが大きい。
短期コピー 中程度から高い。 数十 GB から数百 GB 程度のコピーでは有効だが、ケーブル、電源、熱で失敗しないかは確認が必要である。
大容量の長時間コピー 中程度。 数 TB 単位では、ブリッジ温度、外付け電源、UAS、USB ハブの品質が結果に影響しやすい。
S.M.A.R.T. 確認 製品依存である。 SAT pass-through に対応するブリッジなら取得できるが、成功例と失敗例が存在する。
long test 慎重に扱うべきである。 ディスク自身の長時間診断であっても、接続断、スリープ、電源不安定、ブリッジ相性で観測が乱れる可能性がある。
常時マウント 低い。 暗号化デバイス、ファイルシステム、共有設定を重ねる常用経路では、接続経路が単純な SATA 直結のほうが管理しやすい。
障害切り分け 低い。 不安定時に、ディスク本体、USB ブリッジ、ケーブル、電源、UAS、USB ポートのどこが原因か分けにくい。

UAS も混乱しやすい点である。UAS は USB Attached SCSI のことで、従来の USB mass storage より効率よくストレージを扱うための経路である。しかし、実際の USB-SATA ブリッジでは、UAS で安定する製品もあれば、UAS を無効化して usb-storage 側で扱ったほうが安定する製品もある。smartmontools は SAT with UAS under Linux という形で、Linux 上の UAS と SAT の関係を別項目として扱っている[61]。Linux カーネル文書でも、usb-storage.quirks には VID、PID、Flags の形式でデバイスごとの癖を指定する仕組みがあり、その中には UAS ドライバへ bind しないための IGNORE_UAS が定義されている[62]。

この事実は、USB-SATA 変換を汎用データサーバーの主経路にしにくい理由をよく示している。使える機器はある。S.M.A.R.T. が取れる機器もある。UAS で高速に動く機器もある。しかし、製品ごとに pass-through、UAS、quirks、スリープ、電源、熱の条件を確認しなければならないなら、それはデータサーバーの常用接続としては管理負荷が高い。SATA 直結は派手ではないが、こうした追加条件を少なくできる。

評価軸 SATA 直結 USB-SATA 変換 判断
接続の単純さ 高い。 中程度である。 USB-SATA 変換はブリッジと外付け側の要素が増えるため、障害点が増える。
S.M.A.R.T. の扱いやすさ 高い。 製品依存である。 媒体の状態を判断する用途では、取得できる情報の一貫性が重要である。
長時間運用 ケース、電源、冷却が適切なら高い。 製品依存である。 外付け電源、ケーブル、ブリッジ温度、スリープ制御が追加要因になる。
交換作業 内部配線を触る必要がある。 高い。 頻繁な一時接続では USB ドックが有利である。
障害時の切り分け 比較的しやすい。 難しくなりやすい。 データサーバーでは、問題が起きたときに原因を狭められることが重要である。
常用ディスクへの適性 高い。 低いから中程度である。 暗号化ストレージを常時マウントする経路としては、SATA 直結のほうが保守しやすい。
臨時ディスクへの適性 中程度である。 高い。 内容確認、退避、消去前確認では USB-SATA 変換の手軽さが有効である。

したがって、USB-SATA 変換の適切な位置づけは、主経路ではなく補助経路である。裸の HDD を一時的に接続し、中身を確認し、短期コピーを行い、消去前に内容を確認し、故障疑いのディスクを別経路で読むための道具としては有用である。反対に、暗号化された常用ディスクをマウントし、Samba や NFS の共有先として使い、長時間の I/O を行い、S.M.A.R.T. を継続的に観測する用途では、USB-SATA 変換は慎重に扱うべきである。

ここで重要なのは、USB-SATA 変換を否定することではない。USB-SATA 変換は、ストレージ運用における作業性を大きく高める。問題は、便利さと観測可能性を混同しないことである。ファイルが読めること、S.M.A.R.T. が取れること、long test が安定して完走すること、暗号化デバイスとして常時運用できることは、それぞれ別の条件である。ストレージ中心の汎用データサーバーでは、常用ディスクは SATA 直結を基本にし、USB-SATA 変換は臨時作業と救済経路として扱うのが自然である。

7. データサーバーはローカル機であり、共有機でもある

汎用データサーバーは、ローカルで操作できる Linux マシンであると同時に、LAN 内のファイル共有を提供する機械でもある。この二面性が重要である。ローカル機として見れば、ディスクを接続し、暗号化デバイスを解除し、ファイルシステムをマウントし、権限を設定し、S.M.A.R.T. を確認し、必要に応じて GUI でファイルを整理する機械である。共有機として見れば、Windows、macOS、Linux、スマートフォン、タブレット、仮想マシンなどから、ネットワーク越しに同じデータへアクセスするための機械である。この 2 つは別々に存在するのではなく、ローカルで成立したストレージ構造の上に、共有サービスが重なる形で成立する。

Windows 系クライアントとの共有では Samba が重要になる。Samba は Linux や UNIX-like system における SMB と Active Directory プロトコルの実装であり、SMB を使うクライアントに対して file service と print service を提供する[63]。実際の設定では、smb.conf が Samba suite の設定ファイルとして参照され、共有名、共有するパス、読み書きの可否、ゲストアクセス、ユーザー認証、権限の扱いなどを定義する[64]。Unix 系クライアントとの共有では NFS も選択肢になる。Ubuntu Server の文書では、NFS によってリモートシステム上のディレクトリをローカルファイルのように扱えると説明されている[65]。NFS server 側では、exports がクライアントからアクセス可能な local physical file systems の表として機能する[66]。

層 役割 代表的な要素 崩れた場合の影響
物理ディスク データを実際に保持する。 3.5-inch HDD、2.5-inch SSD、M.2 NVMe SSD、SATA ケーブル、電源ケーブルで構成される。 接続不良、温度上昇、媒体劣化が起きると、上層の暗号化デバイスや共有サービスも不安定になる。
暗号化デバイス 物理ディスク上のデータを暗号化されたブロックデバイスとして扱う。 LUKS、dm-crypt、cryptsetup、crypttab で構成される。 解除できなければ、ファイルシステムも共有サービスも利用できない。
ファイルシステム 暗号化デバイス上にディレクトリとファイルの構造を作る。 ext4、XFS、Btrfs などが該当する。 マウントできなければ、共有するパスが存在しない。
マウントポイント ファイルシステムを Linux のディレクトリツリーへ組み込む。 fstab、systemd mount unit、手動マウントで構成される。 想定した場所にマウントされなければ、Samba や NFS が別の空ディレクトリを共有してしまうことがある。
ローカル権限 ファイルとディレクトリに対する読み書きの可否を決める。 所有者、グループ、permission、ACL で構成される。 共有設定が正しくても、ローカル権限が合わなければ読み書きできない。
共有サービス LAN 内の他の機械からファイルへアクセスできるようにする。 Samba、NFS、smb.conf、exports で構成される。 下層が正しく成立していても、共有設定が誤っていればアクセスできない。
クライアント 共有されたファイルを利用する。 Windows、macOS、Linux、仮想マシン、スマートフォン、タブレットが該当する。 クライアント側の認証、文字コード、権限解釈、キャッシュにより見え方が変わる。

この階層を見れば、共有サービスが単独で成立しているわけではないことが分かる。Samba や NFS は、ディスクを良くする仕組みではない。暗号化ボリュームを解除する仕組みでもない。壊れたファイルシステムを修復する仕組みでもない。これらは、すでにローカルで見えているディレクトリをネットワーク越しに見せる仕組みである。したがって、共有設定を直しても、下層のディスク接続、暗号化解除、マウント、権限が崩れていれば、問題は解決しない。

たとえば、暗号化された HDD を起動時に解除し、その上のファイルシステムを特定のディレクトリへマウントし、そのディレクトリを Samba で共有する構成を考える。この場合、クライアントから見える共有名は、実際には物理ディスク、LUKS、ファイルシステム、マウントポイント、ローカル権限、Samba 設定の最後に現れる表面である。起動時に暗号化デバイスが解除されなければ、共有パスは実体を持たない。マウント先が空ディレクトリのままなら、共有は見えても中身が違う。権限が合わなければ、一覧は見えても書き込めない。共有サービスの問題に見えても、原因は下層にあることが多い。

見える現象 疑うべき層 原因の例 確認の方向
共有名は見えるが中身が空である マウントポイント 暗号化デバイスが解除されておらず、共有対象のディレクトリが空のまま見えている。 共有設定より先に、対象ファイルシステムが想定した場所へマウントされているかを確認する。
読み取りはできるが書き込みできない ローカル権限と共有設定 ファイルシステム上の所有者、グループ、permission、ACL、Samba 側の writeable 設定が一致していない。 共有プロトコル側だけでなく、Linux 上の実ファイルの権限を確認する。
Windows からは見えるが Linux から扱いにくい プロトコル選択 SMB と NFS で権限、ロック、ユーザー ID、ファイル名の扱いが異なる。 クライアントの種類に合わせて、Samba と NFS の役割を分ける。
再起動後に共有が壊れる 起動順序 暗号化解除、マウント、共有サービス起動の順序が揃っていない。 crypttab、fstab、systemd の依存関係を確認する。
アクセス中に I/O エラーが出る 物理ディスクと接続経路 HDD 劣化、SATA ケーブル不良、USB-SATA ブリッジ不安定、電源不足、熱暴走が起きている。 S.M.A.R.T.、カーネルログ、接続方式、温度を確認する。
特定の端末だけ認証に失敗する クライアントと認証 保存済み資格情報、ユーザー名、ワークグループ、ドメイン参加、プロトコルバージョンの差が影響している。 サーバー側の共有定義とクライアント側の認証情報を分けて確認する。

共有プロトコルにも役割の違いがある。Samba は、Windows を含む多様なクライアントからアクセスしやすい。家庭内や小規模な LAN で、Windows PC、macOS、Linux、スマートフォンが混在する場合、SMB 共有は事実上の共通語になりやすい。一方、NFS は Unix 系の機械同士で、サーバー上のディレクトリをクライアントのファイルシステムの一部として扱う用途に向いている。Ubuntu Server の説明が示すように、NFS ではリモートのファイルをローカルに近い感覚で扱える[65]。ただし、どちらも万能ではない。Samba は Windows 系との親和性が高いが、Linux の所有者やグループ、ACL との対応を意識する必要がある。NFS は Unix 系の作業には自然だが、クライアントの UID、GID、export option、ネットワーク境界を意識する必要がある。

共有方式 主な相手 向いている用途 注意点
Samba Windows、macOS、Linux、スマートフォン、タブレット 家庭内や小規模 LAN で、複数種類のクライアントへ同じ共有を見せる用途に向いている。 Linux のローカル権限と Samba 側の共有設定が重なるため、読み書き権限の設計が必要である。
NFS Linux、BSD、Unix 系クライアント Unix 系の作業機から、サーバー上のディレクトリをローカルファイルシステムに近い形で扱う用途に向いている。 exports、クライアント指定、UID、GID、root squash などの考え方を理解する必要がある。
ローカル GUI サーバー本体の画面と入力装置 暗号化デバイスの解除、ディスク確認、ファイル整理、障害時の切り分けに向いている。 共有越しでは見えない物理ディスク、マウント、権限、ログを直接確認できる一方、表示系や入力系の保守も必要になる。
SSH 管理用端末 設定変更、状態確認、ログ確認、軽いファイル操作、サービス再起動に向いている。 GUI ではなくコマンド操作が中心になるため、誤操作を避ける命名と手順が重要になる。

この比較から分かるのは、データサーバーを単なる NAS として見ると見落とすものがあるという点である。NAS 的な機能は、ネットワーク越しにファイルを出す機能である。しかし、汎用データサーバーはそれだけではない。ローカルで暗号化デバイスを開き、HDD の健康状態を確認し、ディレクトリ構成を変更し、共有対象を調整し、必要なら GUI でファイルを整理する。共有機能は重要だが、共有機能だけが本体ではない。

起動順序も重要である。暗号化ストレージを共有する場合、物理ディスクが認識され、暗号化デバイスが解除され、ファイルシステムがマウントされ、その後に Samba や NFS が期待するパスを共有する、という順序が必要になる。systemd.mount は、fstab から mount unit を生成し、local-fs.target や remote-fs.target との関係を扱う[67]。このため、共有サービスの自動起動だけを考えるのではなく、共有対象のファイルシステムが先に成立しているかを考えなければならない。

起動段階 成立すべき状態 失敗した場合の見え方 設計上の注意
ディスク認識 物理ディスクが OS から認識されている。 暗号化デバイスを開けず、マウント対象も存在しない。 SATA 直結、電源、ケーブル、S.M.A.R.T.、カーネルログを確認できる構成にする。
暗号化解除 LUKS などの暗号化デバイスが解除されている。 ファイルシステムが存在しないため、共有対象の実体が現れない。 crypttab、鍵入力、解除名、手動解除手順を明確にする。
マウント ファイルシステムが所定のマウントポイントへ載っている。 共有名は見えても、空ディレクトリや別の内容を共有することがある。 fstab、systemd mount unit、マウント先の命名を一貫させる。
権限確認 ローカルの所有者、グループ、permission、ACL が意図通りである。 共有へ接続できても、読み取り専用になったり、作成や削除に失敗したりする。 共有設定だけでなく、実ファイルの権限を基準にする。
共有サービス起動 Samba や NFS が、実体のあるマウント先を公開している。 クライアントから共有が見えない、または中身が期待と異なる。 サービスの起動順序と、共有対象パスの成立条件を結びつける。
クライアント接続 クライアントが認証され、共有へ接続できる。 特定の端末だけ失敗する、保存済み資格情報が衝突する、権限が合わない。 サーバー側の階層問題と、クライアント側の認証問題を分けて確認する。

権限設計は、共有サービスを使うときに最も混乱しやすい部分である。Linux では、ファイルとディレクトリは所有者、グループ、permission を持つ。さらに ACL を使えば、通常の UNIX permission より柔軟な権限指定ができる。ACL は UNIX permission を補助する柔軟な権限機構として説明されており、特定のユーザーやグループへ追加的な権限を与えるために使われる[68]。Samba では、このローカル権限の上に SMB 側の認証と共有設定が重なる。NFS では、クライアントとサーバーの UID、GID、export option が効いてくる。したがって、共有できない、書けない、消せないという現象は、プロトコルの問題ではなく、ローカル権限との重なりで起きている場合がある。

権限要素 効く場所 役割 誤解しやすい点
所有者 ローカルファイルシステム ファイルやディレクトリの基本的な所有主体を決める。 Samba で認証できても、実ファイルの所有者と権限が合わなければ書き込めない。
グループ ローカルファイルシステム 複数ユーザーで同じディレクトリを扱うための基本単位になる。 共有用グループを設計しないと、ユーザーごとに作成したファイルの扱いがばらつく。
permission ローカルファイルシステム 読み取り、書き込み、実行、ディレクトリ探索の可否を決める。 ディレクトリの実行権限は、ファイル一覧や移動の可否に影響する。
ACL ローカルファイルシステム 通常の所有者、グループ、その他だけでは足りない権限指定を補う。 柔軟だが、見落とすと permission だけ見ても原因が分からない。
Samba 設定 SMB 共有 共有単位で読み書き、認証、ゲスト可否、見え方を制御する。 Samba 側で書き込み可能にしても、ローカル権限が拒否すれば書けない。
NFS export option NFS 共有 どのクライアントへ、どの条件でファイルシステムを公開するかを決める。 NFS はローカルファイルシステムを公開するため、サーバー側の権限設計がそのまま効いてくる。
クライアント認証 接続元端末 共有に接続するユーザーや資格情報を決める。 サーバー側が正しくても、クライアント側に古い資格情報が残っていると失敗することがある。

このように見ると、データサーバーの設計では、共有サービスだけを最後に付け足すのでは不十分である。どのディスクをどの暗号化名で開き、どのディレクトリへマウントし、どの所有者とグループで管理し、どの範囲を Samba で公開し、どの範囲を NFS で公開するのかを、最初から一つの構造として考える必要がある。共有名は人間に見える入口であり、その背後には物理ディスクからローカル権限までの階層がある。

この章の結論は、汎用データサーバーを「ローカル機でもあり、共有機でもある」と捉えることである。ローカル機としての役割があるから、SATA 直結、S.M.A.R.T.、暗号化解除、マウント、GUI、ログ確認が重要になる。共有機としての役割があるから、Samba、NFS、認証、権限、クライアント差が重要になる。両者は分離できない。下層のストレージが観測でき、マウント構造が説明でき、権限が整理されているからこそ、上層の共有サービスも安定する。

8. HDD には、常時稼働するデータ置き場としての役割が残っている

3.5-inch HDD は、最新の高速ストレージではない。OS の起動、アプリケーションの起動、仮想マシンのランダム I/O、ビルド作業、画像生成や動画編集の一時領域では、NVMe SSD のほうが明らかに有利である。しかし、ストレージ中心の汎用データサーバーで扱うデータは、すべてが高速なランダム I/O を必要とするわけではない。写真、動画、音楽、文書、アーカイブ、スキャンデータ、作業済みデータ、長期保存したいファイル群は、大容量で、安価に、常時接続され、状態を観測できる保存層を必要とする。この用途では、HDD は過去の媒体ではなく、いまも現実的な選択肢である。

現行の NAS 向け HDD を見ると、この位置づけは仕様上も確認できる。Western Digital の WD Red Plus は、3.5-inch、SATA、CMR、NAS 向けの HDD として展開され、180 TB/year のワークロード率を掲げている[69]。Toshiba N300 も、3.5-inch、SATA、CMR、7200 rpm、最大 180 TB/year のワークロード、最大 1.2 million hours の MTTF/MTBF を掲げ、NAS、desktop RAID、server、private cloud storage などを用途として示している[70]。さらに高い負荷を想定する製品では、WD Red Pro が high-intensity 24×7 multi-user NAS environments 向けとして示され[71]、Seagate IronWolf Pro も 550 TB/year の workload rating、2.5 million hours MTBF、5-year limited warranty を掲げている[72]。

製品系列 想定用途 最大容量例 ワークロード指標 読み取れること
WD Red Plus 家庭、小規模事業者、NAS 向けの常時稼働ストレージである。 12 TB 級までのラインアップが確認できる。 180 TB/year を掲げる。 一般的な NAS や小規模データサーバー向けに、CMR、SATA、常時稼働を前提にした HDD が継続して提供されている。
Toshiba N300 NAS、desktop RAID、server、private cloud storage 向けである。 22 TB 級までのラインアップが確認できる。 180 TB/year、最大 1.2 million hours MTTF/MTBF を掲げる。 HDD は単なるデスクトップ部品ではなく、複数ベイや常時稼働を意識した保存媒体として設計されている。
WD Red Pro 高負荷の 24×7 multi-user NAS environments 向けである。 26 TB 級までのラインアップが確認できる。 550 TB/year 級のワークロードと 5 年保証を掲げる。 高容量、多ユーザー、長時間稼働を前提にした HDD は、上位製品として継続して存在する。
Seagate IronWolf Pro 商用 NAS、エンタープライズ寄り NAS、高負荷共有環境向けである。 30 TB 級までのラインアップが確認できる。 550 TB/year、2.5 million hours MTBF、5 年保証を掲げる。 30 TB 級でも SATA 接続の 3.5-inch HDD として提供されており、大容量保存層としての HDD の役割は残っている。

この比較から分かる第一の点は、HDD が単に「遅い古い部品」として残っているのではなく、用途別に製品系列が分かれていることである。WD Red Plus や Toshiba N300 のような 180 TB/year 級の NAS 向け HDD は、家庭内サーバー、小規模オフィス、個人のデータサーバーに近い用途を想定しやすい。一方、WD Red Pro や Seagate IronWolf Pro のような 550 TB/year 級の製品は、より高い負荷、多人数アクセス、多ベイ環境を想定している。つまり、HDD には「安い容量」だけではなく、常時稼働、複数ベイ、振動、ワークロード、保証という評価軸がある。

第二の点は、容量の伸びが続いていることである。Seagate は Mozaic 3+ プラットフォームで HAMR、つまり熱アシスト磁気記録を用いた高密度化を進め、30 TB 級の IronWolf Pro や Exos M を市場へ投入している[73]。HAMR は、磁気記録の密度を高めるために記録時に媒体の一部を熱で扱いやすくする技術であり、ここでは技術そのものの詳細よりも、3.5-inch HDD の容量拡大がまだ続いていることが重要である。HDD は、NVMe SSD のように低遅延で高速な媒体ではないが、1 台あたりの大容量保存という点ではなお進化している。

観点 HDD が持つ強み HDD が持つ弱み データサーバーでの配置
容量 1 台あたり 20 TB から 30 TB 級まで伸びており、大容量の常用保存層を作りやすい。 小容量用途では SSD との差が見えにくくなる。 写真、動画、文書、アーカイブ、長期保存データの置き場に向く。
速度 大きな連続読み書きでは実用的な速度を出せる。 ランダム I/O、低遅延、並列アクセスでは NVMe SSD に大きく劣る。 OS、作業用一時領域、仮想マシンの主領域には SSD を使い、HDD は保存層に回すのが自然である。
常時稼働 NAS 向け、Pro 向け、エンタープライズ寄りの製品では 24×7 や高ワークロードを前提にした仕様がある。 振動、温度、電源、取り付け状態に影響される。 ケースの 3.5-inch ベイ、前面吸気、SATA 直結、S.M.A.R.T. 監視と組み合わせる必要がある。
観測可能性 S.M.A.R.T. により、温度、稼働時間、代替処理、保留中セクタ、自己診断結果を確認できる。 USB-SATA 変換や外付けケースを挟むと、取得できる情報が製品依存になることがある。 常用ディスクは SATA 直結を基本にすると、状態確認と障害切り分けがしやすい。
交換性 3.5-inch ベイに固定された単体ディスクとして、交換、退役、増設がしやすい。 物理的に大きく、振動し、SATA ケーブルと電源ケーブルが必要である。 ケース内の作業空間、ラベル、ケーブル整理、ベイ数が運用負荷に直結する。
暗号化との相性 大容量の暗号化データ領域を構成しやすい。 初期化、全域検査、大容量コピー、暗号化ボリューム作成に時間がかかる。 長時間処理を前提に、安定した電源、冷却、接続経路を確保する必要がある。

第三の点は、HDD の信頼性は抽象論ではなく、大規模運用データでも観測され続けていることである。Backblaze の 2025 年ドライブ統計では、2025 年末時点で 349,462 台の HDD を監視し、そのうち基準を満たす 344,196 台を 2025 年の annual failure rate 集計対象としている[74]。Backblaze の環境は個人のデータサーバーとは異なるため、数値をそのまま家庭用運用へ移すことはできない。それでも、数十万台規模の HDD が実運用で使われ、容量、年齢、モデル別に故障率が継続的に観測されている事実は、HDD が現役の大容量保存媒体であることを示している。

データ 数値 読み方 本稿での意味
Backblaze の監視対象 HDD 2025 年末時点で 349,462 台である。 データセンター規模の運用であり、個人環境とは温度、振動、交換方針、I/O パターンが異なる。 HDD が現実の大容量保存基盤として大量に使われ続けていることを示す。
2025 年統計対象 HDD 344,196 台である。 基準を満たさない boot drive や対象外 drive を除いた集計である。 HDD の故障や運用は、印象ではなく統計的に観測されている。
対象モデル数 30 モデルである。 メーカー、容量、モデルごとに故障率が異なることを前提に読む必要がある。 HDD を一括して良い、悪いと見るのではなく、用途、容量、モデル、年齢で分ける必要がある。
個人運用への適用 そのまま移植できない。 Backblaze の筐体、冷却、交換方針、負荷は家庭内データサーバーと異なる。 参考にすべきなのは特定モデルの優劣だけではなく、状態を継続的に観測し、故障前提で運用する姿勢である。

HDD をデータサーバーで使う場合、速度よりも層の分離が重要になる。OS、アプリケーション、パッケージキャッシュ、仮想マシン、作業用一時領域は SSD に向く。特に NVMe SSD は、ランダム I/O と低遅延が必要な領域に向いている。一方、HDD は、大きなファイルを長期間置く領域、頻繁には書き換えないが常時参照したい領域、LAN 内で共有する大容量領域に向いている。したがって、HDD と SSD の関係は代替関係ではなく、役割分担として捉えるべきである。

領域 向いている媒体 理由 設計上の注意
OS 領域 NVMe SSD または SATA SSD 起動、更新、ログ、パッケージ操作では低遅延とランダム I/O が効く。 データ領域と分けると、OS 再構築時に大容量データへ触れずに済む。
作業用一時領域 NVMe SSD 展開、変換、ビルド、仮想マシン、画像や動画の一時処理では速度が効く。 一時領域と長期保存領域を混ぜると、不要データが HDD 側に残りやすい。
共有データ領域 3.5-inch HDD 大容量、常時接続、LAN 内共有、長期保存に向いている。 暗号化、マウントポイント、Samba、NFS、権限設計を一体で考える必要がある。
写真・動画保管 3.5-inch HDD ファイルサイズが大きく、容量単価と交換性が効きやすい。 サムネイル生成や編集作業は SSD 側、元データ保存は HDD 側に分けると扱いやすい。
アーカイブ領域 3.5-inch HDD 頻繁に書き換えない大容量データを保持する用途に向いている。 長期保存でも、S.M.A.R.T.、定期確認、媒体交換の判断は必要である。
仮想マシン領域 NVMe SSD 多数の小さなランダム I/O が発生しやすい。 HDD 上で動かすと体感が大きく悪化し、共有用途の I/O と干渉することがある。

この役割分担は、暗号化ストレージの設計にも直結する。暗号化されたデータ領域を HDD に置き、OS や一時領域を SSD に置く構成は、性能と容量を分ける設計として自然である。ただし、大容量 HDD を暗号化デバイスとして運用するには、時間がかかる。初期化、ファイルシステム作成、全域検査、大容量コピー、S.M.A.R.T. long test は、数 TB から数十 TB の容量では長時間作業になる。したがって、HDD を使う判断は、遅い媒体を我慢することではなく、長時間処理を前提にした接続、冷却、電源、監視、作業計画を受け入れることである。

ここで 3.5-inch HDD の物理性が再び問題になる。HDD は M.2 SSD と異なり、基板上に直接挿して終わる部品ではない。ベイに固定し、SATA ケーブルを接続し、電源ケーブルを接続し、振動を抑え、温度を見て、交換できるようにラベルや配線を整理する必要がある。大容量 HDD を常時稼働するデータ置き場として使うなら、マザーボードの SATA ポート数、ケースの 3.5-inch ベイ数、前面吸気、電源容量、ケーブルの取り回しが、そのまま運用条件になる。

HDD 運用条件 必要になる理由 不足した場合の問題 古い多 SATA 環境の価値
SATA 直結 S.M.A.R.T.、自己診断、エラーログ、温度を観測しやすくするためである。 USB 変換や外付けケースを挟むと、観測情報や長時間安定性が製品依存になりやすい。 複数 HDD を OS から素直に見せやすい。
3.5-inch ベイ HDD を安全に固定し、振動と交換作業を管理するためである。 無理な固定や仮置きは、振動、接触不良、温度上昇、誤操作につながる。 古いケースには複数 HDD を前提にした固定空間が残っていることがある。
前面吸気 複数 HDD の発熱を逃がすためである。 高温状態が続くと、寿命や安定性の判断が難しくなる。 HDD ケージに風を当てやすい構造は、データサーバーでは実用上の価値がある。
電源と配線 複数 HDD は SATA 電源コネクタと安定した電源供給を必要とするためである。 分岐や無理な配線が増えると、接触不良や保守時の混乱が起こりやすい。 電源ケーブルを自然に引き回せるケースは、長期運用で扱いやすい。
交換作業空間 HDD は増設、退役、検査、入れ替えが発生する媒体であるためである。 交換のたびに GPU やラジエータを外す構造では、作業負荷と誤操作の可能性が上がる。 古いケースの広い内部空間やベイ構造は、保守作業の安全性に直結する。

HDD を使う理由は、SSD を否定することではない。むしろ、データサーバーでは SSD と HDD の役割を分けることで全体が安定する。SSD は高速な作業層であり、HDD は大容量の保存層である。NVMe SSD が増えたことで、OS や作業領域を HDD から切り離しやすくなった。その結果、HDD はシステム全体を遅くする部品ではなく、データ置き場として役割を限定しやすくなったとも言える。

この章の結論は、HDD には常時稼働するデータ置き場としての役割が残っているということである。ただし、その役割は「安いから何でも置く」という雑なものではない。大容量、常時接続、S.M.A.R.T. による観測、暗号化データ領域、LAN 内共有、交換可能性という条件が揃ったとき、HDD は汎用データサーバーの保存層として意味を持つ。その条件を満たすには、HDD を物理的に安定して収め、SATA で直結し、状態を確認できるケースとマザーボードが必要になる。ここで、古い SATA ポートの多いマザーボードと HDD 向きのケースが、単なる古い部品ではなく、データサーバーの運用資産として再評価できる。

9. 拡張手段は、接続口を増やすだけでは足りない

SATA が足りない場合、拡張手段はいくつもある。PCIe SATA 増設カード、M.2-SATA 変換カード、SAS/SATA HBA、RAID コントローラ、SATA ポートマルチプライヤ、USB-SATA ドック、USB 多ベイ DAS、5.25-inch ベイ用リムーバブルケージ、別筐体 NAS 化などである。しかし、これらは同じ問題を同じ品質で解決するものではない。ある方法は接続口だけを増やす。ある方法は物理的な交換性を上げる。ある方法は RAID やキャッシュを持ち込み、OS からの見え方を変える。ある方法は本体からストレージを外へ逃がす。したがって、拡張手段を選ぶときは、単に「何台つながるか」ではなく、「どの層で、何を増やし、何を失うのか」を見なければならない。

以下の拡張手段は、すべてを導入すべき選択肢として並べるものではない。常用ディスクの経路、臨時接続の経路、交換性を高めるための物理拡張、別筐体へ分離する設計変更を区別するための整理である。接続口を増やすことは手段であり、目的は、暗号化された複数のストレージを観測でき、説明でき、保守できる状態で運用することである。

ストレージ中心の汎用データサーバーでは、増設の評価軸は数だけではない。HDD を OS から個別に見られるか、S.M.A.R.T. を取得できるか、long test を実行しやすいか、エラー時にディスク本体と接続経路を切り分けられるか、暗号化デバイスとして安定して扱えるか、Samba や NFS の共有先として常時マウントしてよいか、ケース内で冷却できるか、電源ケーブルを無理なく供給できるかが問題になる。つまり、拡張とは接続口を増やすことではなく、観測可能で、説明可能で、保守可能なストレージ経路を増やすことである。

拡張方法 増えるもの 主なメリット 主なデメリット 常用データサーバー適性
ネイティブ SATA の多いマザーボードを選ぶ チップセットまたはオンボードコントローラ由来の SATA ポートが増える。 経路が単純で、OS からディスクを個別に見やすく、S.M.A.R.T. や暗号化デバイス管理も扱いやすい。 現行一般向け製品では 4 本前後に収束しやすく、6 本以上を条件にすると選択肢が狭くなる。 最も自然である。
PCIe SATA 増設カード PCIe スロットから SATA ポートを 2 本から 6 本程度追加する。 安価に内蔵 SATA を増やしやすく、AHCI コントローラとして見えれば Linux でも扱いやすい。 チップ、ファームウェア、PCIe レーン数、発熱、S.M.A.R.T.、エラー時挙動の確認が必要である。 中程度から高い。
M.2-SATA 変換カード 余った M.2 PCIe スロットを SATA ポートへ変換する。 PCIe スロットを塞がず、M.2 スロットが余っている環境で SATA を追加できる。 M.2 スロットの帯域、排他条件、冷却、固定、ケーブル引き回し、基板の保持が問題になる。 中程度である。
SAS/SATA HBA PCIe 経由で多数の SAS/SATA デバイスを扱う接続基盤が増える。 複数 HDD を本格的に扱いやすく、HBA として使えば OS から個別ディスクを見せやすい。 発熱、ケーブル、SFF コネクタ、ファームウェア、PCIe x8 などの条件を理解する必要がある。 高い。
RAID コントローラ ハードウェア RAID、キャッシュ、バッテリまたはキャッシュ保護を含むストレージ制御層が増える。 RAID 構成、キャッシュ、管理機能をカード側で提供でき、サーバー用途では強力である。 ディスクの見え方が抽象化され、暗号化や個別 S.M.A.R.T.、障害時の切り分けが複雑になることがある。 用途を選ぶ。
SATA ポートマルチプライヤ 1 本の SATA 接続から複数の SATA デバイスを分岐する。 物理的なポート数を増やせる。 ホストとデバイス側の対応、帯域共有、エラー時の切り分け、安定性が問題になりやすい。 低い。
USB-SATA ドック USB 経由で裸 HDD や SSD を一時接続できる。 抜き差しが容易で、内容確認、短期コピー、消去前確認に向いている。 S.M.A.R.T.、UAS、USB ブリッジ、外付け電源、接続断、長時間 I/O が製品依存になる。 臨時用途向けである。
USB 多ベイ DAS USB 経由で複数台の 3.5-inch HDD を外付けできる。 PC ケース内に収まらない台数を外へ逃がせる。 複数 HDD が USB 経路、ブリッジ、外付け筐体、外部電源に依存する。 補助用途向けである。
5.25-inch ベイ用リムーバブルケージ ケース前面から HDD を交換できる物理ベイが増える。 交換性、ラベル確認、前面アクセス、冷却を改善できる。 SATA ポートそのものは増えず、5.25-inch ベイを持つケースが必要である。 高いが、ケース条件に依存する。
別筐体 NAS 化 ストレージ機能を別のサーバーまたは NAS 専用機へ移す。 本体 PC の SATA ポートやケース制約から離れられる。 ローカルの暗号化デバイスとして直接扱う設計から、ネットワーク越しの共有設計へ変わる。 別設計である。

第一の方法は、そもそもネイティブ SATA が多いマザーボードを使うことである。これは拡張カードではないが、最も素直な拡張である。チップセットまたはオンボードの SATA コントローラから直接出ているポートであれば、OS からの見え方が単純であり、S.M.A.R.T.、暗号化デバイス、マウント、ログ確認を扱いやすい。古い多 SATA マザーボードの価値はここにある。接続口を増やすために追加の変換層を入れる必要がないため、障害時の切り分けも比較的単純である。

ただし、現行一般向けマザーボードでこの条件を満たす製品は多くない。4 章で見たように、最近の一般向け製品では SATA は 4 本前後に収束しやすい。SATA 6 本以上を条件にすると、製品の選択肢は狭くなり、フォームファクター、チップセット、価格、M.2 スロット数、PCIe スロット配置、ケースとの相性まで含めて探す必要がある。したがって、ネイティブ SATA の多い環境をすでに持っているなら、それは単に古い機材ではなく、追加層なしで複数 HDD を扱える運用資産である。

方式 観測可能性 障害切り分け 導入難度 評価
ネイティブ SATA 高い。 比較的容易である。 既存環境なら低く、新規選定では高くなる。 常用ディスクには最も自然である。
追加コントローラ チップとドライバに依存する。 中程度である。 中程度である。 製品を選べば実用的である。
外付け変換 製品依存である。 難しくなりやすい。 低い。 臨時作業には便利だが、常用経路には慎重さが必要である。

第二の方法は、PCIe SATA 増設カードである。ASMedia ASM1166 は、PCIe Gen3 x2 を上流側に持ち、下流側に 6 本の SATA Gen3 ポートを提供する AHCI controller として説明されている[75]。この種のカードは、内蔵 SATA ポートを比較的安価に増やせる。AHCI として OS から見えるなら、Linux でも扱いやすく、暗号化ディスクを個別のブロックデバイスとして扱う構成に向いている。

PCIe SATA 増設カードの利点は、内蔵構成を保ったまま SATA HDD を増やせることである。USB 変換のように外付け電源や USB ブリッジを挟まず、ケース内の電源と冷却に組み込める。SATA ケーブルと電源ケーブルを整理し、ドライブをケース内に固定できるなら、汎用データサーバーの常用ディスクにも使いやすい。一方で、カードのチップ、PCIe レーン数、熱、ファームウェア、ポート数、OS からの見え方は確認が必要である。特に安価なカードでは、見かけのポート数、実効帯域、S.M.A.R.T.、エラー時の挙動、起動時の認識順にばらつきが出ることがある。

PCIe SATA 増設カードの観点 メリット デメリット 確認点
ポート数 2 本から 6 本程度の SATA を追加できる。 カード上のポート数が多くても、上流 PCIe 帯域は共有される。 同時に複数 HDD を読み書きする用途で帯域が足りるか確認する。
OS からの見え方 AHCI として見えれば個別ディスクを扱いやすい。 チップやドライバによって、ログやエラー時の挙動が変わる。 Linux で認識、S.M.A.R.T.、自己診断、再起動後の認識順を確認する。
発熱 小型でケース内に収めやすい。 小型ヒートシンクだけでは、長時間 I/O 時に熱を持つことがある。 カード周辺のエアフローを確保する。
電源 データ経路だけを追加し、HDD の電源は PC 電源から取れる。 SATA 電源コネクタの数や分岐が不足すると、別の不安定要因になる。 電源側の SATA コネクタ数とケーブル配線を確認する。
用途 内蔵 HDD を数台増やす用途に向く。 十数台以上の本格的な多ドライブ構成では、HBA のほうが整理しやすい。 増設台数が少数か、多数かで選択を分ける。

第三の方法は、M.2-SATA 変換カードである。SilverStone ECS07 は、M.2 PCIe インターフェースを使い、5 つの SATA Gen3 6Gbps ポートを追加する Non-RAID M.2 PCIe storage expansion card として説明されている[76]。これは、マザーボード上の M.2 スロットを NVMe SSD ではなく SATA 増設に使う方法である。最近のマザーボードでは M.2 スロットが複数あるため、SATA が少なく M.2 が余っている構成では魅力がある。

ただし、M.2-SATA 変換は、M.2 スロットが余っていれば簡単に使えるというものではない。M.2 スロットは、CPU 直結かチップセット側か、PCIe レーン数はいくつか、他の M.2 や PCIe スロットと排他になるか、ヒートシンクや GPU と物理干渉しないかを確認する必要がある。また、M.2 カードから複数の SATA ケーブルを引き出すため、ケース内の配線はむしろ複雑になりやすい。小さな M.2 基板に複数ポートを載せるため、冷却と固定も軽視できない。

M.2-SATA の観点 メリット デメリット 確認点
スロット利用 PCIe 拡張スロットを使わずに SATA を増やせる。 M.2 スロットを NVMe SSD に使えなくなる。 どの M.2 スロットを犠牲にするかを決める。
排他条件 余った M.2 を有効活用できる。 製品によっては PCIe スロットや他の M.2 と帯域を共有する。 マザーボード仕様の共有、無効化、レーン分岐条件を確認する。
冷却 基板が小さく設置しやすい。 小型カードに複数 SATA コントローラを載せるため、発熱が集中する。 ヒートシンクと周辺エアフローを確認する。
配線 マザーボード上から SATA ケーブルを増やせる。 M.2 スロット位置によっては、GPU やヒートシンク周辺に SATA ケーブルが密集する。 ケーブルの曲げ、抜け、交換時の作業性を確認する。
用途 SATA が数本足りない環境の補助に向く。 本格的な多 HDD サーバーでは、物理配線と冷却が難しくなりやすい。 少数増設か、長期常用かで判断する。

第四の方法は、SAS/SATA HBA である。Broadcom HBA 9500-8i は、PCIe Gen4 の Tri-Mode HBA で、8 internal ports を持ち、SAS、SATA、NVMe を扱うデータセンター向けの拡張手段として説明されている[77]。HBA は Host Bus Adapter のことで、ディスクを RAID ボリュームとしてまとめるよりも、ホスト OS へ接続された個別ディスクとして見せる方向の装置である。暗号化ストレージを個別に管理したい汎用データサーバーでは、この性格が重要になる。

SAS/SATA HBA の利点は、多数の HDD を整理して扱いやすいことである。内部コネクタから分岐ケーブルやバックプレーンへ接続し、ケース内の複数 HDD をまとめて扱える。サーバー寄りの設計なので、単なる安価な SATA 増設カードより、多ドライブ環境に向く。ただし、HBA は一般向け自作 PC パーツよりもサーバー寄りである。PCIe x8 スロット、発熱、エアフロー、SFF-8643 や SFF-8654 などのケーブル、ファームウェア、OS 対応、起動時認識を理解する必要がある。

HBA の観点 メリット デメリット 確認点
多ドライブ接続 8 台以上の SATA/SAS ディスクを整理して扱いやすい。 一般的な SATA ケーブルとは異なる SFF 系ケーブルが必要になる。 カード側コネクタ、ドライブ側コネクタ、ブレークアウトケーブルを確認する。
OS からの見え方 HBA として使えば個別ディスクを管理しやすい。 ファームウェアやモードにより、見え方や管理ツールが変わる。 個別ディスクとして見えるか、S.M.A.R.T. が取れるかを確認する。
信頼性 多ドライブを前提にした設計で、サーバー寄りの構成に向く。 カード自体が発熱し、冷却を前提にすることが多い。 ケース内エアフローとカード温度を確認する。
拡張性 バックプレーンや SAS エキスパンダと組み合わせやすい。 構成がサーバー寄りになり、ケーブルと部品の理解が必要になる。 何台まで増やすのかを先に決める。
暗号化との相性 個別ディスクとして見えれば、LUKS やファイルシステムをディスク単位で設計しやすい。 RAID 抽象化を挟むと、暗号化層と物理ディスクの対応が見えにくくなる。 HBA と RAID コントローラを混同しない。

第五の方法は、RAID コントローラである。Broadcom MegaRAID 9560-8i は、PCIe Gen4 x8 の Tri-Mode RAID adapter であり、SAS、SATA、NVMe を扱う高性能サーバー向けの製品として示されている[78]。RAID コントローラは、複数の物理ディスクをカード側でまとめ、RAID 0、1、5、6、10 などの論理ボリュームとして OS へ見せるために使われる。これは、ディスクを個別に扱いたい HBA とは方向が違う。

RAID コントローラの利点は、冗長化、キャッシュ、管理機能をカード側で提供できることである。サーバー用途では強力な選択肢であり、ハードウェア RAID を明確に使いたい場合には意味がある。しかし、暗号化ストレージを個別ディスク単位で把握したい汎用データサーバーでは、物理ディスクと OS から見える論理ボリュームの関係が一段抽象化される。S.M.A.R.T.、障害ディスクの特定、暗号化レイヤー、ファイルシステム、交換手順は、カードの管理ツールと設計思想に依存する。便利な抽象化は、同時に観測可能性の一部をカード側へ移す。

項目 HBA RAID コントローラ 汎用データサーバーでの判断
基本思想 ディスクを OS へ個別に見せる。 複数ディスクを論理ボリュームとしてまとめる。 暗号化ディスクを個別に扱うなら HBA が分かりやすい。
冗長化 OS 側の mdadm、LVM、ZFS、Btrfs などに任せる。 カード側で RAID を構成する。 どの層に冗長化を置くかを決める必要がある。
S.M.A.R.T. 個別ディスクとして取得しやすい。 カード管理ツール経由になることがある。 状態観測を重視するなら、取得方法を事前に確認する。
障害時交換 OS から見えるディスクと物理ディスクを対応付ける。 RAID 管理画面や管理ツールで故障メンバーを特定する。 運用手順を理解していないと誤交換のリスクがある。
暗号化 ディスク単位、パーティション単位、ファイルシステム単位で設計しやすい。 RAID ボリューム全体の上に暗号化を置く設計になりやすい。 物理媒体単位での管理を重視するか、論理ボリューム単位での管理を重視するかで変わる。

第六の方法は、SATA ポートマルチプライヤである。これは、1 本の SATA 接続の先に複数の SATA デバイスをぶら下げる考え方である。ASMedia ASM1166 の説明にも cascaded port multipliers という語が現れるように、SATA の世界には分岐的に台数を増やす仕組みが存在する[75]。しかし、汎用データサーバーの常用ディスクでは、この方式は慎重に扱うべきである。1 本の経路を複数ディスクで共有するため、帯域、エラー時の切り分け、ホスト側対応、デバイス側対応、相性が問題になる。

SATA ポートマルチプライヤの問題は、理屈として増やせることと、管理しやすいことが違う点にある。複数ディスクが 1 本の経路へ集約されると、あるディスクの不調、リンクリセット、ケーブル不良、筐体側の問題が他のディスクの見え方にも影響することがある。暗号化デバイスを常時マウントし、共有サービスを重ねる環境では、接続経路の不確定要素を増やすことは好ましくない。したがって、ポートマルチプライヤは、実験、臨時接続、低負荷用途では選択肢になりうるが、常用データサーバーの中心に置く方法ではない。

方式 台数の増やし方 メリット デメリット
PCIe SATA 増設 PCIe から SATA コントローラを追加する。 OS から複数 SATA ポートとして扱いやすい。 カード品質と発熱に依存する。
HBA サーバー向けの SAS/SATA 接続基盤を追加する。 多ドライブ運用に向く。 ケーブル、発熱、ファームウェアの理解が必要である。
ポートマルチプライヤ 1 本の SATA 接続を複数デバイスへ分岐する。 少ないポートから見かけ上の接続数を増やせる。 帯域共有とエラー切り分けが難しく、常用には向きにくい。

第七の方法は、USB-SATA ドックや USB 多ベイ DAS である。Sabrent の USB 3.2 Gen 2 Type-C 10-bay docking station は、10 台の 3.5-inch SATA 6Gbps HDD を tray-less bay で扱い、UASP、10Gbps、独立電源スイッチ、冷却ファンを備える製品として説明されている[79]。このような USB DAS は、PC ケース内に入りきらない HDD を外へ出し、机上または棚上でまとめて扱う手段になる。多ベイで、冷却と電源が用意されている製品なら、単体ドックより整理しやすい。

しかし、USB DAS は SATA 直結とは別物である。複数 HDD が USB ブリッジ、外付け筐体、外部電源、USB ケーブル、USB ホスト、UAS、ファームウェアに依存する。S.M.A.R.T. が通るか、各ディスクが個別に見えるか、同時 I/O 時に安定するか、長時間アクセスでブリッジや電源が安定するかを確認する必要がある。特に暗号化デバイスを常時マウントし、その上に Samba や NFS の共有を載せる用途では、USB DAS を主経路にするより、臨時接続、整理作業、退避、オフライン媒体確認のための補助装置として扱うほうが自然である。

USB 系拡張 メリット デメリット 適した用途
単体 USB ドック 裸 HDD をすぐ接続でき、交換が非常に速い。 電源、接触、S.M.A.R.T.、long test、長時間 I/O が製品依存である。 内容確認、短期コピー、消去前確認に向く。
2-bay USB ドック 移行元と移行先を並べて扱いやすい。 同時アクセス時の帯域と電源、クローン機能の誤操作に注意が必要である。 一時的なコピー、媒体比較、退避に向く。
多ベイ USB DAS ケース内に収まらない HDD を外付けでまとめられる。 USB 経路と外付け筐体に多数の常用ディスクが依存する。 補助ストレージ、整理作業、非常用媒体の接続に向く。
USB 外付けケース 単体 HDD を保護し、机上で扱いやすい。 ケースごとの冷却、スリープ、ブリッジ品質、電源品質に左右される。 持ち運び、臨時接続、単体媒体管理に向く。

第八の方法は、5.25-inch ベイ用リムーバブルケージやホットスワップケージである。ICY DOCK FatCage MB155SP-B は、3 つの 5.25-inch ベイに 5 台の 3.5-inch SATA III HDD を収める backplane module として説明されている[80]。SilverStone FS305 も、3 つの 5.25-inch device bay に 5 台の 3.5-inch SAS/SATA drive を収める hot-swap cage として示されている[81]。この方式は、SATA ポートを増やすものではない。しかし、ケース内の 5.25-inch ベイを使って、HDD の交換性、冷却、前面アクセス、ラベル確認を改善できる。

リムーバブルケージの利点は、物理運用を改善することである。HDD をケース内の奥へ固定すると、交換のたびにサイドパネルを開け、ケーブルを抜き差しし、他のディスクや GPU に触れる必要が出る。前面アクセスのケージがあれば、ディスクの挿抜、ラベル確認、交換作業が容易になる。S.M.A.R.T. で異常が出たディスクを物理的に特定しやすいことも利点である。一方で、ケージは SATA ポートを増やさない。各ドライブには個別の SATA データ接続と電源供給が必要である。さらに、ケージ自体のファン、バックプレーン、コネクタ、鍵、トレイ構造が新しい保守対象になる。

物理拡張 増えるもの メリット デメリット
5.25-inch リムーバブルケージ 前面から交換できる HDD ベイが増える。 交換性、ラベル確認、冷却、整理が改善する。 SATA ポートは増えず、5.25-inch ベイを持つケースが必要である。
内蔵 HDD ケージ追加 ケース内の 3.5-inch 固定位置が増える。 外観を変えずに内蔵台数を増やせる。 前面吸気、GPU、ラジエータ、ケーブルと干渉することがある。
外付け DAS ケース外にベイが増える。 PC ケースの物理制約から逃げられる。 USB、電源、筐体、ブリッジに依存する。

第九の方法は、別筐体 NAS 化である。これは、現在の汎用データサーバーに SATA を増やすのではなく、ストレージそのものを別の機械へ移す方法である。この方法では、HDD は NAS 専用機または別の Linux サーバーに収め、現在の機械からは Samba、NFS、SSH、rsync などで利用する。PC 本体の SATA ポート数やケース内の 3.5-inch ベイ数に縛られなくなる点は大きい。

ただし、別筐体 NAS 化は、拡張ではなく設計変更である。ローカルの暗号化デバイスを直接開いて、ローカルファイルシステムとしてマウントし、その上に共有を載せる構造から、ネットワーク越しに別サーバーの共有を使う構造へ変わる。ディスクの S.M.A.R.T.、暗号化解除、ファイルシステム、権限、共有設定は、別筐体側で管理することになる。これは有効な方法だが、本稿で扱っている「ローカル機でもあり、共有機でもある汎用データサーバー」とは運用の中心が変わる。

方式 本体 PC との関係 メリット デメリット 向いている場合
同一筐体内拡張 現在のデータサーバー内部にディスクを増やす。 ローカルディスクとして暗号化、マウント、S.M.A.R.T.、共有設定を一体で管理できる。 ケース、SATA、電源、冷却の制約を受ける。 ローカルで直接管理したい場合に向く。
外付け DAS 現在のデータサーバーへ USB などで外付けする。 ケース内の制約を緩和できる。 外付け筐体と接続経路に依存する。 臨時接続や補助ストレージを増やしたい場合に向く。
別筐体 NAS ストレージ管理を別サーバーへ移す。 台数、冷却、設置場所、共有機能を分離できる。 ローカルディスクではなくネットワーク越しの資源になる。 常時共有を専用機へ分離したい場合に向く。

これらの拡張方法を並べると、最初に決めるべきことは、何を増やしたいのかである。SATA データポートが足りないのか、HDD を固定するベイが足りないのか、前面から交換したいのか、S.M.A.R.T. を確実に見たいのか、外へ逃がしたいのか、別機械へ分離したいのかで、選ぶ方法は変わる。SATA ポートだけを増やしても、ケースに 3.5-inch ベイがなければ HDD は安全に置けない。ベイだけ増やしても、SATA ポートがなければ接続できない。USB で外へ逃がしても、観測可能性と長時間安定性を確認しなければ常用経路にはしにくい。

不足しているもの 有力な方法 避けたい方法 理由
SATA ポートが 1 本から 2 本足りない PCIe SATA 増設カード、M.2-SATA 変換カード USB 常用化 少数の内蔵 HDD なら、内蔵接続のまま増やしたほうが観測しやすい。
SATA ポートが 4 本以上足りない SAS/SATA HBA 安価な多ポートカードの無検証運用 多ドライブ構成では、発熱、ケーブル、OS からの見え方を含めた設計が必要である。
3.5-inch ベイが足りない ストレージ重視ケース、5.25-inch リムーバブルケージ ケース内の仮置き HDD は固定、冷却、振動、交換性を含めて扱う必要がある。
一時接続だけしたい USB-SATA ドック 内部配線の頻繁な抜き差し 臨時作業では手軽さが重要であり、USB ドックが有効である。
常用共有領域を増やしたい ネイティブ SATA、PCIe SATA、HBA 未検証の USB DAS 暗号化、マウント、Samba、NFS を重ねるため、接続経路の再現性が重要である。
本体ケースに収まらない ストレージ重視ケースへの移行、別筐体 NAS 化、検証済み DAS 無理な内蔵増設 冷却、電源、配線、交換性が限界に達しているなら、筐体設計を変える必要がある。

拡張方法を評価する最終基準は、便利さではなく、運用時に説明できるかどうかである。どの物理ディスクがどの暗号化デバイスに対応するのか。どの SATA ポート、どの HBA、どの USB ブリッジ、どのベイに接続されているのか。S.M.A.R.T. はどの経路で取得できるのか。エラーが出たとき、ディスク本体、ケーブル、電源、カード、ブリッジ、ファイルシステム、共有サービスのどこを疑うのか。この説明ができなければ、接続口が増えても運用は安定しない。

したがって、汎用データサーバーでの優先順位は明確である。常用ディスクは、まずネイティブ SATA を使う。足りなければ、信頼できる PCIe SATA 増設カードまたは HBA を検討する。多台数構成なら、HBA とストレージ向きケースまたはリムーバブルケージを組み合わせる。RAID コントローラは、RAID をカード側で明確に使いたい場合に限定する。USB-SATA ドックや USB DAS は、臨時接続、整理、救済、補助用途として使う。別筐体 NAS 化は、同一筐体内での拡張ではなく、設計の分離として扱う。

この章の結論は、拡張手段はあるが、すべて同じ信頼度ではないということである。接続口を増やすだけなら方法は多い。しかし、暗号化された複数の HDD を、S.M.A.R.T. で観測し、マウントポイントと共有設定に結びつけ、長時間安定して運用するには、経路の単純さと説明可能性が必要になる。古い多 SATA マザーボードと HDD 向きケースの価値は、拡張できないから残すのではない。追加層を増やさずに、複数の 3.5-inch HDD を素直に扱えるから残す価値がある。

10. 古いケースとマザーボードは、運用基盤として再評価できる

古いケースとマザーボードを残す理由は、十年以上前の構成が常に新しい構成より優れているからではない。CPU 性能、消費電力、NVMe、USB4、2.5GbE 以上の有線 LAN、Wi-Fi 7、UEFI、Secure Boot、ファームウェア更新、microcode、GPU 対応、メモリ容量では、新しい構成が有利になりやすい。Debian のリリースライフサイクルは、通常の security support と LTS を合わせて約 5 年という単位で説明されており、OS 側の保守も永遠ではない[82]。Intel も管理者向けに microcode update guidance を提供しており、CPU やプラットフォームの更新は性能だけでなくセキュリティや安定性にも関係する[83]。したがって、古い機材を大切にすることは、新しい技術を否定することではない。

それでも、ストレージ中心の汎用データサーバーでは、古い構成が持つ価値がある。価値の中心は、CPU の速さではなく、ストレージを安定して収め、接続し、観測し、交換し、共有サービスの下層として説明できることである。現行の一般向けマザーボードでは SATA が 4 本前後に整理され、現行の主流ケースでは 3.5-inch HDD が 1 基から 2 基に抑えられやすい。一方、古い ATX ケースや古い多 SATA マザーボードには、複数の 3.5-inch HDD を収める空間、前面から HDD に風を当てる構造、複数 SATA ポート、5.25-inch ベイ、SATA 電源ケーブルを引き回す余裕、手を入れて交換できる作業空間が残っていることがある。

評価軸 新しい構成が有利な点 古い構成が有利になりうる点 汎用データサーバーでの判断
CPU 性能 新しい CPU は単体性能、効率、命令セット、内蔵機能で有利である。 ファイル共有、暗号化済み領域の通常利用、軽い GUI 操作では古い CPU でも足りる場合がある。 動画変換や多数 VM を主目的にしないなら、CPU 性能だけで退役を決める必要はない。
消費電力 新しい CPU とチップセットはアイドル時効率で有利になりやすい。 常時稼働台数を抑え、HDD 数を限定すれば、古い構成でも許容できる場合がある。 電気代、発熱、稼働時間を見て、役割に対して過剰かどうかを判断する。
SATA 直結 新しい一般向けマザーボードでは SATA は 4 本前後に整理されやすい。 古いマザーボードには 6 本以上の SATA や、HDD 運用に十分な内蔵接続が残っていることがある。 複数 HDD を暗号化デバイスとして直接扱うなら、古い多 SATA 構成には実用価値がある。
3.5-inch 搭載性 新しい主流ケースは GPU、ラジエータ、裏配線、見た目を重視しやすい。 古いケースには複数 HDD ベイ、5.25-inch ベイ、広い内部空間が残っていることがある。 HDD を常用保存層にするなら、ケースの物理的余裕は性能値以上に重要である。
高速 I/O 新しい構成は USB4、Thunderbolt、PCIe 5.0、2.5GbE 以上の LAN で有利である。 古い構成でも Gigabit LAN、SATA HDD、ローカル GUI、SSH が主なら十分な場合がある。 必要な転送経路が LAN 共有中心か、高速外部 I/O 中心かで評価が変わる。
保守性 新しい部品は入手性、保証、ファームウェア更新で有利である。 古いケースは作業空間が広く、HDD 交換やケーブル確認がしやすいことがある。 部品の新しさだけでなく、故障時に手を入れて直せるかを評価する。
セキュリティ 新しい構成は最新 UEFI、Secure Boot、microcode、ファームウェア更新で有利である。 古い構成でも、ネットワーク公開範囲を限定し、OS を保守し、役割を絞れば運用できる場合がある。 外部公開する機械か、LAN 内のデータサーバーかで必要水準を分ける。

この表から分かるのは、古い構成を評価する軸を間違えてはならないという点である。古い CPU と新しい CPU をベンチマークで比べれば、多くの場合は新しい CPU が勝つ。古いマザーボードと新しいマザーボードを USB や NVMe や LAN の仕様で比べても、新しい構成が勝つ。しかし、複数の 3.5-inch HDD を SATA で直結し、S.M.A.R.T. で状態を観測し、LUKS で暗号化し、所定のマウントポイントへ載せ、Samba や NFS で共有する用途では、ベンチマークに出ない価値がある。ここで効くのは、経路の単純さ、物理的な余裕、交換性、説明可能性である。

古いケースの価値は、外装ではなく、HDD を運用するための空間にある。3.5-inch HDD は、M.2 SSD のように基板へ挿して終わる部品ではない。ベイへ固定し、振動を抑え、前面から風を当て、SATA ケーブルと電源ケーブルを接続し、交換時にはラベルと配線を確認する必要がある。ケースに余裕があれば、HDD の増設、退役、検査、交換が作業として成立しやすい。反対に、ケースが狭く、HDD ベイが少なく、ラジエータや GPU と干渉する構造では、同じ HDD 台数でも運用負荷が高くなる。

ケース側の要素 残す価値がある状態 劣化または不足の兆候 対応方針
3.5-inch ベイ 複数 HDD をねじ止めまたはトレイ固定でき、振動が大きくない。 固定部が割れている、トレイが欠けている、HDD が傾く、共振音が大きい。 トレイ、ねじ、防振部品を補修し、無理な仮置きは避ける。
5.25-inch ベイ リムーバブルケージや前面アクセス用途に転用できる。 ベイカバーや固定レールが欠品し、ケージを固定しにくい。 必要なら 5.25-inch 用ケージを使い、前面から交換できる構成にする。
前面吸気 HDD ケージへ直接または間接に風が当たる。 前面フィルタが詰まる、ファンが劣化する、HDD 温度が高止まりする。 フィルタ清掃、ファン交換、ケーブル整理で風路を確保する。
内部空間 SATA ケーブルと電源ケーブルを無理なく曲げられる。 ケーブルが強く折れる、HDD 交換時に GPU や電源ケーブルへ触れすぎる。 短すぎるケーブルや硬すぎるケーブルを避け、交換作業の動線を作る。
サイドパネル 開閉しやすく、定期清掃とディスク確認が容易である。 爪やねじ穴が傷み、開閉が面倒になっている。 工具なしで開けられる範囲を保ち、清掃頻度を落とさない。
フロント I/O 最低限の USB、電源ボタン、リセット、LED が安定して使える。 電源ボタンの接触不良、USB ポートの破損、LED 配線の断線がある。 サーバー用途では致命度を分け、必要ならマザーボード直結や背面ポートで代替する。

古いマザーボードの価値は、最新機能ではなく、ストレージ接続基盤としての単純さにある。複数 SATA ポートがあり、Linux で安定して認識し、S.M.A.R.T. が取れ、PCIe スロットに必要な拡張カードを挿せるなら、汎用データサーバーとしての役割は残る。さらに、古いチップセットやオンボードデバイスは、Linux で枯れていることがある。枯れているとは、古くて劣っているという意味ではなく、長期間使われ、ドライバやトラブル事例が蓄積し、予測しやすいという意味である。ストレージ運用では、この予測しやすさが価値になる。

ただし、古いマザーボードは無条件に信用できない。コンデンサ、SATA ポート、メモリスロット、PCIe スロット、VRM、オンボード NIC、USB ポート、CMOS 電池、UEFI/BIOS、ファンヘッダは劣化や不具合の対象になる。CPU そのものより、周辺の接点、電源系、冷却、ファームウェアのほうが問題になることも多い。古いマザーボードを使い続けるなら、機能が足りているかだけでなく、故障時に切り分けられるかを基準にする必要がある。

マザーボード側の要素 残す価値がある状態 退役を検討する状態 判断理由
SATA ポート 複数ポートが安定して認識し、ケーブル交換後もエラーが出ない。 特定ポートだけリンクリセットや I/O エラーが出る。 常用ディスクの接続経路として不安定なら、データサーバーの基盤として危うい。
PCIe スロット NIC、HBA、SATA 増設カードなどを安定して認識する。 カードの認識が揺れる、負荷時に切れる、物理スロットが破損している。 拡張余地があっても、接続が不安定なら意味がない。
オンボード NIC LAN 内共有に必要な速度と安定性を満たす。 リンクダウン、速度低下、ドライバ不安定がある。 Samba や NFS の共有機能はネットワーク安定性に依存する。
メモリスロット 必要容量を安定して認識し、長時間稼働でエラーが出ない。 メモリ認識が揺れる、スロットごとに不安定、容量不足が解消できない。 ファイル共有と GUI だけなら大容量は不要でも、不安定なメモリは避けるべきである。
ファンヘッダ ケースファンと CPU ファンを制御でき、HDD 冷却を維持できる。 ファン回転数が読めない、制御できない、ヘッダが破損している。 HDD 常用では冷却と監視が運用条件になる。
UEFI/BIOS 起動設定が安定し、ディスク順序やブートデバイスが説明できる。 設定が保持されない、ブート順が揺れる、最新 OS との相性が悪い。 暗号化ディスクを扱う機械では、起動経路の安定性が重要である。
CMOS 電池 時刻と BIOS 設定が保持される。 再起動や電源断後に時刻や設定が戻る。 小さな部品だが、起動順序や時刻の乱れは運用上の混乱を生む。

電源は、古い機材を残すときに最も軽視してはいけない部品である。ケースやマザーボードを残しても、電源まで無条件に残す必要はない。HDD は起動時にスピンアップし、複数台が同時に動くと 12 V 系に負荷がかかる。古い電源は、出力容量だけでなく、コンデンサ劣化、ファン劣化、コネクタ不足、SATA 電源ケーブルの取り回し、保護回路、効率、待機電力の点で不利になることがある。Intel の ATX 電源設計ガイドは、電源設計が構成依存であり、すべての構成を一律に支えるものではないという前提を置いている[84]。このことは、HDD を複数扱うデータサーバーでは、電源を独立した保守対象として見るべきことを示している。

消耗部品 劣化すると起きること 優先度 対応方針
電源ユニット 起動失敗、HDD の瞬断、負荷時の不安定、異音、発熱が起きる。 高い。 古いケースを残しても、電源は状態次第で交換する。
ケースファン HDD 温度上昇、異音、回転停止、ほこり堆積が起きる。 高い。 前面吸気と排気を優先して交換する。
SATA ケーブル リンクリセット、I/O エラー、接触不良、ディスク認識失敗が起きる。 高い。 不安定なポートを疑う前に、ケーブル交換で切り分ける。
SATA 電源ケーブル HDD の瞬断、スピンアップ失敗、接触不良が起きる。 高い。 無理な分岐を避け、電源側のケーブル構成を確認する。
CMOS 電池 時刻、ブート順、BIOS 設定が保持されなくなる。 中程度である。 安価な部品なので、古い機材では予防的に交換する価値がある。
CPU グリス CPU 温度上昇、ファン回転増加、負荷時の不安定が起きる。 中程度である。 長期間未交換なら、清掃と合わせて交換する。
ほこりとフィルタ 吸気低下、HDD 温度上昇、ファン騒音、電源内部の熱こもりが起きる。 高い。 定期清掃を運用手順に含める。

古い機材を残すかどうかは、感情ではなく、役割とリスクを分けて判断するのがよい。すべてを新しくする必要はないが、すべてを古いまま使う必要もない。ケースは残す。マザーボードは残す。電源は交換する。ファンは交換する。SATA ケーブルは交換する。起動用 SSD は新しくする。HDD は S.M.A.R.T. と long test を見て個別判断する。このように、部品ごとに役割と寿命を分ければ、古い機材を合理的に延命できる。

分類 該当部品 扱い方 理由
残す価値が高いもの 3.5-inch ベイの多いケース、5.25-inch ベイ、作業空間、前面吸気構造 清掃し、ファンを交換し、HDD 運用向けの筐体として使い続ける。 現行主流ケースでは失われやすい物理的余裕を持つためである。
状態を見て残すもの マザーボード、CPU、メモリ、オンボード NIC、PCIe スロット 長時間稼働、再起動、S.M.A.R.T. 取得、共有動作を確認して判断する。 性能より安定性と観測可能性が重要であるためである。
交換を前提に見るもの 電源、ファン、SATA ケーブル、CMOS 電池、起動用 SSD 古さを理由に残さず、消耗部品として扱う。 安価に交換できる部品の劣化で、データサーバー全体を不安定にするべきではないためである。
用途次第で追加するもの HBA、PCIe SATA 増設カード、2.5GbE NIC、リムーバブルケージ 不足している機能を明確にしてから追加する。 追加層は便利だが、発熱、ドライバ、ケーブル、設定という保守対象も増やすためである。
退役を検討するもの 不安定なマザーボード、認識が揺れる SATA ポート、交換不能な劣化ケース、異常のある電源 無理に延命せず、部品単位または筐体単位で役割を外す。 データサーバーでは、原因不明の不安定さが最も危険であるためである。

定量的に判断するなら、古いデータサーバーを 10 項目で採点すると分かりやすい。各項目を 0 点から 2 点で評価し、合計 20 点満点で見る。0 点は運用に支障がある状態、1 点は条件付きで使える状態、2 点は用途に対して十分な状態である。この採点は厳密な工業規格ではないが、古い機材を残す判断を感覚から切り離すには有効である。

評価項目 0 点 1 点 2 点
SATA ポート 常用ディスク数に足りず、認識も不安定である。 足りるが余裕が少ない、または一部ポートに不安がある。 常用ディスクと作業用ディスクを同時に扱える余裕がある。
3.5-inch ベイ HDD を安全に固定できない。 最低限固定できるが、交換性や冷却に難がある。 複数 HDD を固定し、冷却し、交換できる。
冷却 HDD 温度が高止まりし、ファンも劣化している。 通常時は使えるが、夏場や長時間 I/O で不安がある。 前面吸気、排気、清掃性が確保されている。
電源 古く、不安定で、コネクタや容量に不安がある。 動作するが、HDD 増設時の余裕が小さい。 HDD 台数に対して余裕があり、ケーブルも整理できる。
Linux 対応 主要デバイスの認識に問題がある。 基本動作するが、一部機能に回避策が必要である。 ストレージ、NIC、GPU、センサーが安定して認識する。
ネットワーク 共有用途に必要な安定性を満たさない。 Gigabit LAN は安定するが、高速化には拡張が必要である。 用途に対して十分な速度と安定性がある。
GUI と管理性 画面出力や入力に問題があり、ローカル保守が難しい。 通常時は使えるが、表示系やリモート操作に代替が必要である。 GUI、SSH、ログ確認、ディスク管理が無理なく行える。
拡張余地 PCIe、ベイ、電源、冷却の余裕がない。 少数の追加なら可能である。 HBA、NIC、追加 HDD を計画的に入れられる。
保守部品 交換部品の入手や代替が難しい。 一部は交換できるが、固有部品に依存する。 ファン、ケーブル、電源、SSD などを一般部品で交換できる。
安定稼働実績 原因不明の停止や I/O エラーがある。 通常時は動くが、負荷時や再起動時に確認が必要である。 長時間稼働、再起動、S.M.A.R.T.、共有動作が安定している。

この 20 点満点の評価では、16 点以上ならデータサーバーとして残す価値が高い。12 点から 15 点なら、電源、ファン、SATA ケーブル、起動用 SSD、NIC などの交換で延命できる可能性がある。8 点から 11 点なら、用途を限定し、常用機ではなく検査用、臨時接続用、移行用に役割を下げる判断が現実的である。7 点以下なら、データサーバーの中心から外すべきである。重要なのは、古いか新しいかではなく、役割に対して必要な条件を満たしているかである。

合計点 判断 扱い方 理由
16 点から 20 点 主力データサーバーとして維持できる。 消耗部品を交換しながら、SATA 直結のストレージ基盤として使い続ける。 古い構成でも、観測可能性、搭載性、保守性が用途に合っているためである。
12 点から 15 点 補修前提で維持できる。 電源、ファン、ケーブル、SSD、NIC などを交換し、弱点を潰す。 本体構成の価値は残るが、消耗部品が足を引っ張る可能性があるためである。
8 点から 11 点 用途限定で残す。 常用共有機ではなく、HDD 検査、移行、臨時接続、予備機として使う。 常時稼働には不安があるが、物理的な SATA 環境として役割が残る可能性があるためである。
0 点から 7 点 退役を検討する。 データサーバーの中心から外し、使える部品だけを回収する。 不安定な古い機材を常用すると、データ運用全体のリスクになるためである。

古い機材を再評価するときに、もう一つ重要なのは役割分担である。古いデータサーバーを、最新のメイン PC と同じ役割で比べる必要はない。最新のメイン PC は、開発、ブラウジング、仮想マシン、GPU 処理、高速 NVMe 作業に使えばよい。古い多 SATA 構成は、暗号化された複数 HDD を直接扱うストレージ中心の機械として使えばよい。両者を役割で分けると、古い機材の弱点と強みが整理される。

役割 新しいメイン PC 古い多 SATA データサーバー 分ける理由
日常作業 向いている。 必須ではない。 CPU、メモリ、GPU、NVMe、表示環境は新しい機械が有利である。
大容量保存 内蔵台数が限られることがある。 向いている。 SATA ポートと 3.5-inch ベイが多ければ、HDD 保存層として使いやすい。
暗号化ディスク管理 可能だが、HDD 多台数では制約が出やすい。 向いている。 物理ディスク、暗号化名、マウント先を固定しやすい。
LAN 内共有 可能である。 向いている。 常時稼働し、Samba や NFS を提供する機械として役割を固定できる。
HDD 検査と交換 USB ドック頼みになりやすい。 向いている。 SATA 直結で S.M.A.R.T. と long test を扱いやすい。
高速一時作業 向いている。 限定的である。 NVMe SSD と新しい CPU を使う処理は新しい機械へ寄せるほうがよい。

この役割分担を取ると、古いケースとマザーボードは「時代遅れのメイン PC」ではなく、「ストレージ中心の汎用データサーバー」として再定義できる。性能競争から外れた機械でも、SATA 直結、HDD ベイ、前面吸気、Linux での安定認識、ローカル GUI、SSH、Samba、NFS が成立するなら、まだ役割はある。特に暗号化ストレージを扱う環境では、物理ディスクとマウント構造を説明できることが重要であり、その説明可能性は最新性能とは別の価値である。

ただし、再評価は延命のための自己正当化であってはならない。原因不明の I/O エラーがある。SATA ポートの認識が揺れる。電源が不安定である。HDD 温度が下がらない。ファンが止まる。再起動後に BIOS 設定が戻る。Linux の更新後に主要デバイスが不安定になる。こうした症状があるなら、古い機材を大切にする段階ではなく、退役、部品交換、役割縮小を検討する段階である。データサーバーはデータを扱う機械であり、原因不明の不安定さを抱えたまま常用するべきではない。

この章の結論は、古いケースとマザーボードは、条件付きで運用基盤として再評価できるということである。条件は、古いことではなく、役割に対して必要な機能を満たしていることである。複数 HDD を安全に固定できる。SATA で直結できる。S.M.A.R.T. を観測できる。冷却できる。電源を安定させられる。暗号化デバイス、マウントポイント、共有設定を説明できる。消耗部品を交換できる。これらを満たすなら、十年以上前のケースとマザーボードは、単なる古い部品ではなく、ストレージ中心の汎用データサーバーを支える運用資産である。

11. 結論として、データサーバーの価値は市場の主流とは別に決まる

現在の PC 市場は、NVMe SSD、大型 GPU、高効率な冷却、ガラスパネル、LED、USB4、Thunderbolt、高速無線 LAN、2.5GbE 以上の有線 LAN を中心に進んでいる。この方向は自然である。OS やアプリケーションを高速に起動し、ゲームや制作アプリケーションを快適に動かし、配線を隠し、冷却を強め、見た目を整える用途では、現在のケースとマザーボードは合理的に進化している。したがって、本稿の結論は、最近の PC パーツが悪くなったという話ではない。問題は、現在の主流設計が、暗号化された複数の HDD を直接扱う汎用データサーバーという用途とは別の方向へ最適化されていることである。

ストレージ中心の汎用データサーバーでは、評価軸が変わる。重要なのは、最高速の NVMe SSD を何本載せられるかだけではない。3.5-inch HDD を何台安全に固定できるか、SATA でどれだけ素直に直結できるか、S.M.A.R.T. によって状態を観測できるか、暗号化デバイスをどの名前で開き、どのマウントポイントへ載せ、どの共有サービスへ渡すかを説明できるかである。LUKS、cryptsetup、dm-crypt、crypttab、fstab、Samba、NFS は、ばらばらの部品ではない。物理ディスクから暗号化デバイス、ファイルシステム、マウントポイント、ローカル権限、共有サービスまでを積み上げることで、初めてデータサーバーとして成立する[1][18][19][21][23][63][65]。

評価軸 現在の主流 PC が重視するもの 汎用データサーバーが重視するもの 結論
ストレージ性能 NVMe SSD の速度、PCIe 世代、M.2 スロット数が重視される。 HDD の容量、SATA 直結、状態観測、長時間運用が重視される。 高速作業領域と大容量保存領域は、同じ媒体で統一する必要はない。
ケース設計 大型 GPU、ラジエータ、前面メッシュ、裏配線、ガラスパネルが重視される。 3.5-inch ベイ、前面吸気、HDD 交換性、ケーブル余裕、作業空間が重視される。 ケースは外装ではなく、ストレージの運用条件である。
接続方式 M.2、USB4、Thunderbolt、高速外部 I/O が訴求される。 SATA 直結、S.M.A.R.T.、安定した電源、障害時の切り分けが重視される。 速い経路より、説明できる経路が必要になる場面がある。
共有機能 個人利用ではローカル作業が中心になりやすい。 ローカル操作と LAN 内共有が同時に必要になる。 データサーバーは、ローカル機であり共有機でもある。
保守性 新品部品、保証、最新規格、見た目の整った構成が有利である。 交換できる HDD、追跡できるケーブル、確認できる S.M.A.R.T.、分かるマウント構造が有利である。 運用基盤では、性能値より保守可能性が効く。

ここまでの議論から、第一に確認できるのは、SATA が不要になったわけではないということである。SATA は、現在の一般向け PC では主役ではなくなった。OS やアプリケーションの置き場としては NVMe SSD が中心になり、マザーボード上の訴求点も M.2、PCIe、USB4、Wi-Fi 7 へ移っている。しかし、3.5-inch HDD を大容量の保存層として扱う場合、SATA 直結はなお実用的である。SATA 直結は派手ではないが、ディスクを OS から素直に見せ、S.M.A.R.T. を確認し、long test を扱い、暗号化デバイスとして管理し、ファイルシステムとしてマウントするための単純な経路を提供する。

第二に確認できるのは、HDD が過去の媒体ではないということである。HDD は、OS 起動やアプリケーションの体感速度では NVMe SSD に劣る。しかし、大容量の写真、動画、文書、アーカイブ、スキャンデータ、作業済みデータ、LAN 内共有データを常時接続しておく保存層としては、今も現実的である。NAS 向け HDD や高ワークロード向け HDD が現在も製品系列として存在し、数十万台規模の HDD が実運用で観測され続けている事実は、HDD が単なる過去の遺物ではなく、大容量保存媒体として役割を残していることを示している[69][70][71][72][74]。

第三に確認できるのは、ケースとマザーボードの価値は、年式だけでは判断できないということである。新しいケースは冷却、外観、組みやすさ、大型 GPU 対応では有利である。新しいマザーボードは NVMe、USB、ネットワーク、ファームウェア、セキュリティ更新では有利である。しかし、3.5-inch HDD を複数固定し、前面から風を当て、SATA 電源と SATA ケーブルを無理なく引き回し、ディスク交換時に手を入れられる構造は、現在の主流設計ではむしろ減っている。古いケースとマザーボードが、ストレージ中心の用途に対して必要な余裕を持っているなら、その古さはただちに欠点にはならない。

結論項目 短い判断 理由 運用上の意味
SATA まだ必要である。 3.5-inch HDD を直結し、状態を観測し、暗号化デバイスとして扱うための単純な経路になる。 常用 HDD は、可能な限り SATA 直結を基本にする。
NVMe SSD 高速作業層として使う。 OS、アプリケーション、一時領域、仮想マシンでは低遅延とランダム I/O が効く。 HDD を置き換えるのではなく、HDD と役割分担する。
USB-SATA 変換 補助経路として使う。 接続は便利だが、S.M.A.R.T.、UAS、ブリッジ、電源、長時間 I/O が製品依存になる。 内容確認、短期コピー、退避、救済用途に回す。
HBA と増設カード 必要に応じて選ぶ。 SATA が不足する場合の拡張手段になるが、発熱、ケーブル、OS からの見え方を確認する必要がある。 接続口の増加ではなく、観測できる経路の増加として設計する。
古いケース 条件付きで残す価値がある。 3.5-inch ベイ、5.25-inch ベイ、前面吸気、交換作業空間が残っていることがある。 清掃、ファン交換、ケーブル整理によりストレージ向き筐体として再利用できる。
古いマザーボード 条件付きで残す価値がある。 複数 SATA、枯れた Linux 対応、必要十分な PCIe スロットが残っていることがある。 不安定なポートや電源系を除外し、安定する範囲でデータサーバーに使う。

この結論は、古い機材を無条件に肯定するものではない。古い電源、劣化したファン、不安定な SATA ケーブル、認識が揺れるポート、設定を保持できない CMOS 電池、熱のこもるケース、更新できないファームウェア、原因不明の I/O エラーは、データサーバーにとって明確なリスクである。データを扱う機械では、不安定な部品を「まだ動くから」という理由だけで使い続けてはならない。古い機材を大切にするとは、劣化を無視することではなく、残す部品、交換する部品、役割を下げる部品、退役させる部品を分けることである。

したがって、古いデータサーバーを評価するときは、年数ではなく条件を見るべきである。複数 HDD を安全に固定できるか。HDD に風が当たるか。SATA ポートは安定しているか。S.M.A.R.T. は取れるか。電源は複数 HDD のスピンアップに耐えられるか。SATA 電源ケーブルを無理なく配線できるか。Linux で安定して認識するか。暗号化デバイス、マウントポイント、共有設定を説明できるか。再起動後も同じ構成で戻ってくるか。これらを満たすなら、古い機材にはまだ役割がある。満たせないなら、古いことを理由に残すべきではない。

判断 残す条件 交換する条件 退役する条件
ケース HDD を固定でき、冷却でき、交換作業が成立する。 ファン、フィルタ、ねじ、トレイ、ケーブルを交換すれば改善できる。 HDD を安全に固定できず、冷却も作業性も確保できない。
マザーボード SATA、PCIe、NIC、メモリ、ファン制御が安定している。 CMOS 電池、ケーブル、拡張 NIC、HBA で弱点を補える。 原因不明の I/O エラー、認識揺れ、再起動時の不安定さが残る。
電源 HDD 台数に対して余裕があり、コネクタも無理なく足りる。 古く、負荷時の余裕やコネクタに不安がある。 瞬断、異音、発熱、起動失敗がある。
ストレージ接続 SATA 直結で S.M.A.R.T.、long test、ログ確認が安定して行える。 ケーブル交換、ポート変更、増設カード導入で安定化できる。 接続経路が不安定で、ディスク本体と経路不良を切り分けられない。
共有サービス 暗号化解除、マウント、権限、Samba、NFS の順序を説明できる。 設定整理と命名規則の修正で改善できる。 共有対象が不明確で、再起動後に構成が再現しない。

最終的に、古い SATA 環境の価値は「古いからよい」でも「新しいものが悪い」でもない。価値は、用途に対する適合性から生まれる。現在の主流 PC は、高速な NVMe SSD と大型 GPU を中心にした個人用計算機として優れている。しかし、暗号化された複数の HDD を直接扱い、GUI でも操作でき、LAN 内で共有し、ローカルで S.M.A.R.T. とログを確認し、必要に応じてディスクを交換する汎用データサーバーでは、別の適合性が求められる。その適合性の中核にあるのが、SATA 直結、3.5-inch HDD ベイ、冷却、電源、物理的な作業空間、Linux からの観測可能性である。

この視点に立つと、十年以上前に買ったケースとマザーボードを大切にする判断は、懐古ではなく、用途に基づく選別である。最新のパーツ市場が重視しなくなった機能が、特定の運用ではまだ必要である。3.5-inch HDD を複数扱う空間、SATA で直結できる余裕、ケーブルを追える構造、ディスクを交換できる作業性は、現在ではむしろ意識して選ばなければ得にくい。すでにそれを満たす環境を持っているなら、簡単に捨てる理由はない。

ただし、維持するなら、保守する責任も引き受ける必要がある。ほこりを取り、ファンを替え、電源を疑い、SATA ケーブルを交換し、CMOS 電池を替え、HDD の S.M.A.R.T. を確認し、マウント構造を記録し、共有設定を整理する。古い機材を残すとは、放置することではない。むしろ、何が古く、何がまだ機能し、何を交換すべきかを明確にすることである。その手入れができる限り、古いケースとマザーボードは、ストレージ中心の汎用データサーバーを支える現役の運用基盤であり続ける。

本稿の結論は、次の一文にまとめられる。データサーバーの価値は、市場の主流や部品の新しさだけでは決まらない。暗号化された複数のストレージを観測でき、説明でき、保守できるなら、古い SATA 環境は今でも合理的な選択肢である。

参考文献

  1. id774, 暗号化ディスク運用手順を整理する（2026-05-31）. https://blog.id774.net/entry/2026/05/31/4829/
  2. id774, LUKS 暗号化の手順と運用（2026-05-11）. https://blog.id774.net/entry/2026/05/11/4746/
  3. id774, 自由ソフトウェアだけで暗号化媒体をどこまで扱えるか（2026-06-03）. https://blog.id774.net/entry/2026/06/03/4849/
  4. id774, 暗号化ディスクを長期運用するための設計（2026-05-30）. https://blog.id774.net/entry/2026/05/30/4818/
  5. id774, デバイス管理とマウントの基本方針を整理する（2025-09-01）. https://blog.id774.net/entry/2025/09/01/2977/
  6. id774, A Practical Lifecycle Guide to Operating LUKS Encrypted Disks（2026-06-07）. https://blog.id774.net/entry/2026/06/07/4864/
  7. id774, iMac の Fusion Drive を LVM cache として再利用する（2026-02-10）. https://blog.id774.net/entry/2026/02/10/3530/
  8. LVM2, lvmcache(7) – Linux manual page. https://man7.org/linux/man-pages/man7/lvmcache.7.html
  9. id774, Quadro K600 搭載マシンに Debian 13 を導入した際の画面出力問題とその解決（2025-09-02）. https://blog.id774.net/entry/2025/09/02/2980/
  10. id774, macOS から Debian へのリモートデスクトップ接続（2025-09-09）. https://blog.id774.net/entry/2025/09/09/2999/
  11. id774, Debian + Xfce4 でログイン中の GUI セッションを制御する（2026-02-08）. https://blog.id774.net/entry/2026/02/08/3493/
  12. id774, GNU/Linux で XRDP とローカル GUI を同時に使う（2026-03-12）. https://blog.id774.net/entry/2026/03/12/3969/
  13. id774, Using xrdp and Local GUI Together on GNU/Linux（2026-03-23）. https://blog.id774.net/entry/2026/03/23/4085/
  14. id774, Xfce 設定ファイルの構造を理解する（2026-03-13）. https://blog.id774.net/entry/2026/03/13/3976/
  15. id774, Understanding How Xfce Stores and Manages Its Settings（2026-03-24）. https://blog.id774.net/entry/2026/03/24/4087/
  16. id774, Wayland はいつ枯れるのか（2026-02-27）. https://blog.id774.net/entry/2026/02/27/3832/
  17. ArchWiki, dm-crypt/Encrypting an entire system. https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system
  18. cryptsetup project, cryptsetup(8) – Linux manual page. https://man7.org/linux/man-pages/man8/cryptsetup.8.html
  19. Linux Kernel documentation, dm-crypt. https://docs.kernel.org/admin-guide/device-mapper/dm-crypt.html
  20. Debian, cryptsetup package. https://packages.debian.org/ja/sid/cryptsetup
  21. systemd, crypttab(5) – Linux manual page. https://man7.org/linux/man-pages/man5/crypttab.5.html
  22. systemd, systemd-cryptsetup(8) – Linux manual page. https://man7.org/linux/man-pages/man8/systemd-cryptsetup.8.html
  23. ArchWiki, fstab. https://wiki.archlinux.org/title/Fstab
  24. SATA-IO, Purchase SATA Specification. https://sata-io.org/developers/purchase-specification
  25. NVM Express, NVM Express Base Specification. https://nvmexpress.org/specification/nvm-express-base-specification/
  26. USB Implementers Forum, USB4® Specification v2.0. https://www.usb.org/document-library/usb4r-specification-v20
  27. ASUS, TUF GAMING B650-PLUS WIFI – Tech Specs. https://www.asus.com/motherboards-components/motherboards/tuf-gaming/tuf-gaming-b650-plus-wifi/techspec/
  28. ASUS, TUF GAMING X870-PLUS WIFI – Tech Specs. https://www.asus.com/motherboards-components/motherboards/tuf-gaming/tuf-gaming-x870-plus-wifi/techspec/
  29. ASUS ROG, ROG STRIX X870E-E GAMING WIFI – Tech Specs. https://rog.asus.com/motherboards/rog-strix/rog-strix-x870e-e-gaming-wifi/spec/
  30. MSI, MAG B850 TOMAHAWK MAX WIFI – Specification. https://www.msi.com/Motherboard/MAG-B850-TOMAHAWK-MAX-WIFI/Specification
  31. ASRock, B850 Steel Legend WiFi. https://www.asrock.com/mb/AMD/B850%20Steel%20Legend%20WiFi/
  32. GIGABYTE, X870 AORUS ELITE WIFI7 – Specification. https://www.gigabyte.com/Motherboard/X870-AORUS-ELITE-WIFI7/sp#sp
  33. MSI, MAG B760 TOMAHAWK WIFI – Specification. https://jp.msi.com/Motherboard/MAG-B760-TOMAHAWK-WIFI/Specification
  34. ASUS, PRIME B860M-A WIFI – Tech Specs. https://www.asus.com/motherboards-components/motherboards/prime/prime-b860m-a-wifi/techspec/
  35. MSI, B860 GAMING PLUS WIFI – Specification. https://www.msi.com/Motherboard/B860-GAMING-PLUS-WIFI/Specification
  36. ASRock, B860 Steel Legend WiFi. https://www.asrock.com/mb/Intel/B860%20Steel%20Legend%20WiFi/
  37. GIGABYTE, B860M AORUS ELITE WIFI6E – Specification. https://www.gigabyte.com/Motherboard/B860M-AORUS-ELITE-WIFI6E/sp#sp
  38. MSI, MAG Z890 TOMAHAWK WIFI – Specification. https://www.msi.com/Motherboard/MAG-Z890-TOMAHAWK-WIFI/Specification
  39. ASUS ROG, ROG STRIX Z890-E GAMING WIFI – Tech Specs. https://rog.asus.com/motherboards/rog-strix/rog-strix-z890-e-gaming-wifi/spec/
  40. GIGABYTE, Z890 AORUS ELITE WIFI7 – Specification. https://www.gigabyte.com/Motherboard/Z890-AORUS-ELITE-WIFI7/sp#sp
  41. NZXT Support, H5 Flow (2024) Specs. https://support.nzxt.com/hc/en-us/articles/40225168535451-H5-Flow-2024-Specs
  42. NZXT, H7 Flow. https://nzxt.com/product/h7-flow
  43. Corsair, 4000D AIRFLOW Tempered Glass Mid-Tower ATX Case. https://www.corsair.com/us/en/p/pc-cases/cc-9011200-ww/4000d-airflow-tempered-glass-mid-tower-atx-case-black-cc-9011200-ww
  44. Corsair, FRAME 5000D RS ARGB Mid-Tower PC Case. https://www.corsair.com/us/en/p/pc-cases/cc-9011288-ww/frame-5000d-rs-argb-mid-tower-pc-case-black-cc-9011288-ww
  45. LIAN LI, LANCOOL 216. https://lian-li.com/product/lancool-216/
  46. MONTECH, AIR 903 MAX. https://www.montechpc.com/en/products_detail.php?nid=355&s_ok2=
  47. DeepCool, CH560. https://www.deepcool.com/products/Cases/fulltowercases/CH560-Airflow-Mid-Tower-ATX-Case/2023/17118.shtml
  48. be quiet!, PURE BASE 501. https://www.bequiet.com/en/case/5321
  49. Fractal Design, North. https://www.fractal-design.com/products/cases/north/north/chalk-white/
  50. Fractal Design, Pop Air. https://www.fractal-design.com/products/cases/pop/pop-air/rgb-orange-core/
  51. LIAN LI, O11 Dynamic EVO. https://lian-li.com/product/o11-dynamic-evo/
  52. Fractal Design, Define 7. https://www.fractal-design.com/products/cases/define/define-7/black/
  53. Fractal Design, Define 7 XL. https://www.fractal-design.com/products/cases/define/define-7-xl/black/
  54. Cooler Master, MasterBox CM694. https://www.coolermaster.com/en-global/products/masterbox-cm694.html
  55. Fractal Design, Pop XL Air. https://www.fractal-design.com/products/cases/pop/pop-xl-air/rgb-black-tg-clear/
  56. LIAN LI, O11 Dynamic EVO XL. https://lian-li.com/product/o11-dynamic-evo-xl/
  57. Linux Kernel documentation, libATA Developer’s Guide. https://docs.kernel.org/driver-api/libata.html
  58. smartmontools, smartmontools. https://www.smartmontools.org/
  59. smartmontools, USB. https://www.smartmontools.org/wiki/USB
  60. smartmontools, Supported USB-Devices. https://www.smartmontools.org/wiki/Supported_USB-Devices
  61. smartmontools, SAT with UAS under Linux. https://www.smartmontools.org/wiki/SAT-with-UAS-Linux
  62. Linux Kernel documentation, Kernel parameters. https://docs.kernel.org/admin-guide/kernel-parameters.html
  63. Samba, Samba – opening windows to a wider world. https://www.samba.org/
  64. Samba, smb.conf. https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html
  65. Ubuntu Server documentation, Network File System (NFS). https://ubuntu.com/server/docs/how-to/networking/install-nfs/
  66. Linux manual page, exports(5). https://man7.org/linux/man-pages/man5/exports.5.html
  67. systemd, systemd.mount(5) – Linux manual page. https://man7.org/linux/man-pages/man5/systemd.mount.5.html
  68. ArchWiki, Access Control Lists. https://wiki.archlinux.org/title/Access_Control_Lists
  69. Western Digital, WD Red Plus Internal NAS HDD 3.5. https://www.westerndigital.com/ja-jp/products/internal-drives/wd-red-plus-sata-3-5-hdd
  70. Toshiba, N300 NAS Hard Drive. https://www.toshiba-storage.com/products/toshiba-internal-hard-drives-n300/
  71. Western Digital, WD Red Pro NAS Hard Drive. https://www.westerndigital.com/products/internal-drives/wd-red-pro-sata-hdd
  72. Seagate, IronWolf Pro. https://www.seagate.com/products/nas-drives/ironwolf-pro-hard-drive/
  73. Seagate, Mozaic 3+. https://www.seagate.com/innovation/mozaic-3-plus/
  74. Backblaze, Backblaze Drive Stats for 2025. https://www.backblaze.com/blog/backblaze-drive-stats-for-2025/
  75. ASMedia, ASM1166. https://www.asmedia.com.tw/product/45aYq54sP8Qh7WH8/58dYQ8bxZ4UR9wG5.html
  76. SilverStone, ECS07. https://www.silverstonetek.com/en/product/info/expansion-cards/ECS07/
  77. Broadcom, HBA 9500-8i. https://www.broadcom.com/products/storage/host-bus-adapters/sas-nvme-9500-8i
  78. Broadcom, MegaRAID 9560-8i. https://www.broadcom.com/products/storage/raid-controllers/megaraid-9560-8i
  79. Sabrent, USB 3.2 3.5-inch SATA Hard Drive Tray-less Docking Station. https://sabrent.com/products/ds-uctb
  80. ICY DOCK, FatCage MB155SP-B. https://global.icydock.com/product_128.html
  81. SilverStone, FS305. https://www.silverstonetek.com/en/product/info/storage/FS305/
  82. Debian, Debian Releases. https://www.debian.org/releases/
  83. Intel, Microcode Update Guidance. https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/microcode-update-guidance.html
  84. Intel, ATX Version 3.0 Multi Rail Desktop Platform Power Supply Design Guide. https://edc.intel.com/content/www/jp/ja/design/ipla/software-development-platforms/client/platforms/alder-lake-desktop/atx-version-3-0-multi-rail-desktop-platform-power-supply-design-guide/2.1a/