バックアップ媒体の設計では、暗号化方式、ファイルシステム、媒体種別、同期方式を論理的に整えることが重要である。しかし、論理的に整った構成が、実際の媒体性能の上でも正しいとは限らない。バックアップの本質は、保存されたファイルが存在することではなく、必要な時点で復元できる状態を維持することである[1]。また、物理媒体管理は、媒体単体の正常性ではなく、復元可能性を支える役割分担として設計する必要がある[2]。この前提に立つと、暗号化バックアップで重要なのは、LUKS + ext4 が理屈として正しいかどうかだけではなく、その構成をどの媒体に適用したときに実用的な更新性能を維持できるかである。
今回の発端は明確である。従来の TrueCrypt + FAT 構成では許容できていたバックアップ処理を、LUKS + ext4 へ移行したところ、特に 2.5-inch 2TB HDD で実用に耐えない性能低下が発生した。この移行は、外付けバックアップ媒体だけを置き換える作業ではなかった。TrueCrypt 資産を LUKS 構成へ移していくため、サーバー側でもバックアップ元、中継領域、退避領域を確保できるように HDD を大容量へ換装し、暗号化バックアップ全体を現代的な構成へ寄せる意図があった。
一方で、Seagate Expansion Portable 5TB（STKM5000400）では同じような致命的性能問題は発生しなかった。さらに、コピー処理に cp ではなく rsync を使っても同様の傾向が出ているため、この記事ではコピーコマンドの種類を主要因から除外する。問題は、TrueCrypt から LUKS へ変えたことだけでも、cp と rsync の違いでもなく、サーバー側容量の拡張、バックアップ媒体の再編、2.5-inch HDD、SMR、ext4、LUKS、初回投入、メタデータ更新が重なった複合事象として扱う。
LUKS の手順と運用は、暗号化媒体を安全に扱うための基礎として整理済みである[3]。また、TrueCrypt 資産は新規採用ではなく既存資産の保全対象として扱うべきであり、旧媒体を直ちに全廃すべきかどうかは、復元可能性、媒体性能、移行コスト、更新頻度を合わせて判断する必要がある[4]。暗号化バックアップは、鍵、ヘッダー、環境、手順が揃って初めて将来の自分が開けるものであり、保存したという事実だけでは意味を残せない[5]。したがって、この記事では「安全そうだから全媒体を LUKS + ext4 に統一する」という机上の論理が、2.5-inch HDD の現実の性能制約にぶつかった事例として、要因をひとつずつ定量的に分解する。
1. 2.5-inch HDD で性能問題が発生した
事象を最初に固定する。旧構成は TrueCrypt + FAT であり、新構成は LUKS + ext4 である。媒体は 2.5-inch HDD を含み、特に Transcend StoreJet 25M3S 2TB（TS2TSJ25M3S）で性能問題が顕著だった。一方、Seagate Expansion Portable 5TB（STKM5000400）では、同じ LUKS + ext4 移行後でも顕著な性能問題は発生しなかった。Seagate Expansion Portable の資料では、STKM5000400 は 5TB モデルとして列挙され、容量 4TB 以上の筐体寸法は長さ 115.3 mm、幅 80 mm、奥行き 20.9 mm、重量 0.257 kg とされている[6]。同じ 2.5-inch 外付け HDD であっても、筐体厚、内蔵ドライブ世代、記録方式、ファームウェア、キャッシュ処理、USB ブリッジの差があり、「2.5-inch HDD」という分類だけでは性能を予測できない。
| 観測対象 | 容量 | 構成 | 観測結果 | 分析上の意味 |
|---|---|---|---|---|
| Transcend StoreJet 25M3S | 2TB | LUKS + ext4 | 性能問題が顕著に発生した。 | 2.5-inch HDD の中でも、低 IOPS、SMR、初回投入、ext4 メタデータ更新の影響が強く出た可能性がある。 |
| Seagate Expansion Portable STKM5000400 | 5TB | LUKS + ext4 | 顕著な性能問題は発生しなかった。 | 容量が大きい 2.5-inch HDD でも一律に遅いわけではなく、個別媒体の設計差が大きい。 |
| Stick SSD | 2TB 級 | LUKS + ext4 | 2.5-inch 2TB HDD ほど極端ではなかった。 | 暗号化方式単体ではなく、媒体層の機械的レイテンシと小書き込み耐性が支配要因であることを示す。 |
この比較から、単純な結論は 2 つ否定できる。第一に、LUKS + ext4 は常に遅い、という結論は誤りである。5TB HDD と Stick SSD では同じような致命的問題が出ていないためである。第二に、2.5-inch HDD は常にだめだ、という結論も粗い。5TB の 2.5-inch HDD では実用上の問題が目立たなかったためである。したがって、正しい問いは、「なぜ特定の 2.5-inch 2TB HDD で、LUKS + ext4 の大量バックアップ更新が破綻したのか」である。
2. 変更された要素を分解する
今回の移行では、暗号化方式だけが変わったわけではない。TrueCrypt + FAT から LUKS + ext4 へ変えた時点で、ブロック暗号化層、ファイルシステム層、メタデータ管理、ジャーナリング、書き込み順序保証、初期化処理、媒体上の更新パターンが同時に変わっている。したがって、「LUKS が遅い」と短絡すると、原因の大部分を見誤る。
| 層 | 旧構成 | 新構成 | 性能上の変化 |
|---|---|---|---|
| 暗号化層 | TrueCrypt | LUKS / dm-crypt | 暗号化処理の実装、I/O キュー、ブロックデバイスの見え方が変わる。 |
| ファイルシステム層 | FAT | ext4 | journal、inode、Unix 権限、所有者、タイムスタンプ、barrier が加わる。 |
| 初期化状態 | 既存媒体 | mkfs.ext4 直後 | inode table や journal の遅延初期化が初回書き込みと競合しうる。 |
| 媒体層 | 2.5-inch HDD | 同じ 2.5-inch HDD | 媒体は同じでも、要求される I/O パターンが変わる。 |
| ワークロード層 | 大量ファイルバックアップ | 同じ大量ファイルバックアップ | 総容量だけでなく、ファイル数、ディレクトリ数、メタデータ更新回数が効く。 |
この構造では、原因は単一ではなく、弱い層が直列に積み重なる。暗号化層で少し遅くなり、ext4 でメタデータ更新が増え、journal commit と barrier で待ちが入り、HDD の seek と回転待ちが累積し、さらに SMR で内部再配置が発生すると、合計の遅延は線形ではなく段階的に悪化する。とくに 2.5-inch HDD は公称転送速度だけでは評価できない。バックアップのような長時間書き込みでは、瞬間的な MB/s よりも、持続書き込み、小書き込み、メタデータ更新、キャッシュ枯渇後の挙動が支配的になる。
3. 2.5-inch HDD の公称性能を確認する
Seagate BarraCuda 2.5-inch HDD のデータシートは、5TB、4TB、3TB、2TB、1TB モデルを並べ、5TB から 2TB までのモデルについて、論理 / 物理セクターを 512 / 4096、インターフェイスを SATA 6Gb/s、データ転送速度を最大 140 MB/s、キャッシュを 128 MB、回転数を 5400 rpm、記録方式を SMR としている[7]。ここで重要なのは、5TB と 2TB が同じく最大 140 MB/s、128 MB cache、5400 rpm、SMR とされている点である。つまり、仕様表上は近い数値に見えるが、実運用では 5TB で問題が出ず 2TB で問題が出た。この差は、公称転送速度だけでは説明できない。
| 指標 | Seagate BarraCuda 5TB | Seagate BarraCuda 2TB | 読み取り方 |
|---|---|---|---|
| データ転送速度 | 最大 140 MB/s | 最大 140 MB/s | 大きな連続 I/O 寄りの目安であり、小ファイル大量更新の期待値ではない。 |
| 回転数 | 5400 rpm | 5400 rpm | 機械的レイテンシは SSD より大きく、ランダム I/O では不利である。 |
| キャッシュ | 128 MB | 128 MB | 短時間の吸収には効くが、TB 級の長時間投入では枯渇後の挙動が重要になる。 |
| 記録方式 | SMR | SMR | 順次書き込みには強いが、更新混在やランダム書き込みで失速しうる。 |
| 筐体厚 | 15.0 mm | 7.0 mm | 同じ 2.5-inch でも物理設計が異なり、熱、プラッター構成、実装余裕が異なる。 |
| 重量 | 190 g | 90 g | 5TB と 2TB は同じ分類でも実体として別の機械である。 |
この表から読み取るべきことは、5TB HDD で問題が出なかった事実は、2TB HDD の問題を否定しないという点である。むしろ、同じ 2.5-inch HDD、同じ 5400 rpm、同じ最大 140 MB/s、同じ SMR という表面的な近似にもかかわらず、片方だけで性能問題が出たことは、外付け筐体、USB ブリッジ、ファームウェア、media cache、内部ドライブ世代、プラッター構成、熱制御、電源制御の差が効くことを示している。したがって、容量階層と個別型番を無視して「2.5-inch HDD」と一括りにするのは不十分である。
4. 2TB HDD と 5TB HDD の差を媒体設計として見る
Transcend StoreJet 25M3 は、耐衝撃構造と USB 3.1 Gen 1 を特徴とする 2.5-inch 外付け HDD である[8]。製品資料では 3 段階の耐衝撃保護、シリコンラバーケース、内部サスペンションダンパー、強化筐体を特徴としており、設計の重点は「落下や持ち運びに対する保護」である[9]。一方、販売仕様情報では TS2TSJ25M3S 2TB が 2.5-inch、USB 3.2 Gen 1、5400 rpm とされている[10]。この媒体は、堅牢な持ち運び用途としては合理的でも、LUKS + ext4 で TB 級の大量ファイル更新を長時間連続投入する用途に最適化されているとは限らない。
| 観点 | Transcend StoreJet 25M3S 2TB | Seagate Expansion Portable 5TB | 性能分析上の意味 |
|---|---|---|---|
| 容量階層 | 2TB | 5TB | 同じ 2.5-inch でも内部ドライブの世代、厚み、ファームウェア、キャッシュ設計が異なる可能性がある。 |
| 筐体厚 | 16.1 mm 程度の製品情報が流通している。 | 20.9 mm とされる。 | 厚い筐体は内部ドライブや熱設計の余裕が異なる可能性がある。 |
| 回転数 | 5400 rpm とされる。 | 内蔵ドライブにより異なるが、2.5-inch 大容量 HDD は 5400 rpm 級が多い。 | 回転数だけでは差を説明できない。 |
| 接続 | USB 3.x Gen 1 系 | USB 3.0 | バス規格の上限より、HDD 内部の書き込み挙動が支配的になる。 |
| 観測結果 | 性能問題あり | 性能問題なし | 媒体個体またはモデル固有の挙動を検証対象にする必要がある。 |
USB 3.0 や USB 3.1 Gen 1 の公称帯域は、今回の主因ではない。外付け HDD の最大転送速度は 100 MB/s 台であり、USB 3.x Gen 1 のリンク帯域はそれより大きい。したがって、問題が 10 MB/s 台から数十 MB/s 台の実効速度として現れる場合、USB の規格上限ではなく、HDD 内部の seek、回転待ち、SMR の再配置、ext4 の journal、dm-crypt の I/O 経路、USB ブリッジの flush 処理を疑うべきである。
5. SMR は第一容疑者だが、それだけでは説明しない
SMR は、記録密度を上げるためにトラックを瓦のように重ねる方式である。Western Digital の SMR white paper は、drive-managed SMR が従来のブロックデバイスをエミュレートして互換性を保つ一方、特定ワークロードでは性能が予測しにくくなると説明している[11]。Toshiba の技術解説は、SMR は CMR と同じランダムアクセス性能を持たず、media cache と shingled band を使い、更新時には旧データと新データを merge して新しい band に書き戻す構造を説明している[12]。また Toshiba MQ04AB 系列は 2.5-inch、5400 rpm、最大 2TB、Drive-Managed SMR の製品例として示されており、2TB 級モバイル HDD で SMR を疑うことには合理性がある[13]。
| SMR の性質 | 性能問題としての意味 | LUKS + ext4 との関係 |
|---|---|---|
| Drive-managed SMR | OS からは通常 HDD に見えるため、ファイルシステムは SMR を意識しない。 | ext4 は通常のブロックデバイスとして扱い、内部の再配置コストを予測できない。 |
| Media cache | 短時間は書けても、長時間大量書き込みで枯渇すると失速する。 | 初期は速く、その後急に遅くなる現象と整合する。 |
| Band rewrite | 小さい更新が大きい内部書き換えに増幅される。 | journal、directory、inode、mtime 更新が細かい書き換えを誘発する。 |
| Sequential preference | 完全な順次投入では比較的有利だが、更新混在で崩れる。 | バックアップは総容量が大きくてもメタデータ更新が混ざる。 |
ただし、SMR だけを単独主因にしてはいけない。Seagate BarraCuda 2.5-inch の 5TB と 2TB は、データシート上はいずれも SMR とされる[7]。それにもかかわらず 5TB では問題が顕著でなく、2TB では顕著だった。このため、SMR は第一容疑者ではあるが、SMR であることだけでは差を説明できない。実際には、media cache の容量と制御、ファームウェアの書き込み整理、USB ブリッジの flush 伝播、温度制御、個体差、経年劣化、内部ドライブモデルが重なっている可能性が高い。
6. ext4 は FAT より重いが、その重さは設計上の機能である
ext4 は、単純なファイル置き場ではなく、Linux のネイティブなメタデータ、整合性、クラッシュ復旧を支えるファイルシステムである。Linux kernel documentation は、ext4 の data=ordered を標準の journaling mode とし、メタデータが journal に commit される前に関連データを main filesystem へ書き出すと説明している[14]。ext4 の journal は、クラッシュ時のメタデータ不整合を防ぐための領域であり、重要な書き込みを一度 journal に着地させる[15]。また ext4 は delayed allocation を使い、dirty buffer が書き出される時点までブロック割り当てを遅らせることで、より連続した配置を狙う[16]。
| ext4 要素 | 定量または仕様 | 性能上の意味 |
|---|---|---|
| data=ordered | 標準の journaling mode | メタデータ commit 前に関連データの書き出し順序を制御する。 |
| commit interval | 既定値は 5 秒 | 一定間隔でデータとメタデータの同期が発生する。 |
| journal | メタデータ不整合を防ぐための領域 | FAT にはない追加書き込みが発生する。 |
| delayed allocation | 書き戻し時までブロック割り当てを遅延 | 連続配置には有利だが、sync やメモリー圧迫で一気に書き出しが発生する。 |
| inode / permission | ファイルごとに管理 | 小ファイル大量バックアップではメタデータ更新回数が支配的になる。 |
この重さは、ext4 の欠陥ではない。FAT が省いていた整合性、所有者、権限、inode、journal、barrier を ext4 が持っているために発生するコストである。SSD や 3.5-inch CMR HDD ではこのコストを許容できても、2.5-inch 2TB HDD、特に SMR や低 IOPS が重なる媒体では、journal とメタデータ更新が表面化する。つまり、TrueCrypt + FAT が軽かったのは、旧構成が保持していない情報が多かったからであり、LUKS + ext4 が遅くなったのは、保持すべき情報と整合性が増えたからである。
7. journal、barrier、commit は HDD で待ち時間として見える
ext4 の barrier は、書き込み順序を守るための仕組みであり、man page では ext4 が write barrier を既定で有効にすると説明されている[17]。この機構は、揮発性 write cache を持つディスクでメタデータの順序を守るためには重要である。しかし、HDD では書き込み順序保証、flush、journal commit が物理的な待ち時間として見えやすい。とくに 5400 rpm HDD では、seek と回転待ちが SSD より大きく、細かい同期点が増えるほど待ち時間が累積する。
| 機構 | 安全性への効果 | 2.5-inch HDD での副作用 |
|---|---|---|
| journal commit | メタデータ更新を一貫した単位として確定する。 | 一定間隔で書き込み待ちが発生する。 |
| write barrier | ディスクへの到達順序を制御する。 | HDD のキャッシュや並べ替え自由度を制限する。 |
| flush | 揮発性キャッシュに残るデータを媒体へ押し出す。 | USB ブリッジや SMR firmware を巻き込んだ待ちになる。 |
| metadata update | 所有者、権限、サイズ、時刻、ディレクトリを整合させる。 | ファイル数が多いほど IOPS 支配になる。 |
この章での重要点は、速度低下の一部は「悪い遅さ」ではなく「安全性のための遅さ」だということである。ただし、運用上は安全性のためならいくら遅くてもよい、とはならない。24 時間以上かかる、日次運用に乗らない、更新が終わらない、ログが肥大化する、媒体を長時間接続し続ける必要があるという状態は、復元可能性の設計として失敗である。安全な構成であっても、運用可能でなければバックアップとしては不十分である。
8. mkfs.ext4 直後の初回大量投入は悪条件になり得る
mke2fs の man page は、lazy_itable_init が有効で uninit_bg feature が有効な場合、inode table は mke2fs 時点では完全には初期化されず、最初にマウントされたときに kernel がバックグラウンドで初期化を完了すると説明している[18]。mke2fs.conf の man page も、lazy_itable_init が true の場合に inode table が完全には初期化されず、ファイルシステム初期化が速くなる一方で kernel によるバックグラウンド初期化が必要になると説明している[19]。
| 状態 | 内部処理 | 性能上の意味 |
|---|---|---|
| mkfs.ext4 直後 | inode table 初期化が残っている可能性がある。 | ファイルシステム作成は速いが、初回利用時に追加 I/O が残る。 |
| 初回マウント直後 | kernel がバックグラウンド初期化を進める。 | ユーザーのコピー処理と内部初期化が競合する。 |
| TB 級大量投入 | データ書き込み、inode 作成、directory 更新が同時に発生する。 | HDD では seek と回転待ちが増え、SMR では再配置が重なる。 |
| 2.5-inch 2TB HDD | 低 IOPS、低電力設計、USB 接続が重なる。 | 初回投入で最悪条件が揃う。 |
この要因は、5TB HDD で問題が出なかった事実とも矛盾しない。5TB 媒体では firmware、media cache、熱制御、USB ブリッジ、内部ドライブの状態が初回投入に耐えた可能性がある。一方、2TB 媒体では、mkfs.ext4 直後の初回大量投入と ext4 のメタデータ更新が、媒体側の弱点を露出させた可能性がある。したがって、今後同様の検証をするなら、mkfs.ext4 直後にすぐ全量投入する条件と、しばらく idle を置いた後に投入する条件を分ける必要がある。
9. LUKS / dm-crypt は要因だが、単独主因ではない
dm-crypt は Linux の device-mapper target として、ブロックデバイス暗号化を透過的に提供する。kernel documentation には、same_cpu_crypt、submit_from_crypt_cpus、no_read_workqueue、no_write_workqueue、high_priority などのパラメーターが説明されており、暗号処理だけでなく I/O のキューイングや CPU 配置が性能に影響し得ることが分かる[20]。Cloudflare の実験でも、Linux disk encryption の性能は単純な暗号演算速度だけではなく、kernel crypto API、workqueue、I/O 経路の構造に影響され、少なくとも特定環境では大きな改善余地があったと報告されている[21]。
| dm-crypt 要素 | 性能への関係 | 今回の評価 |
|---|---|---|
| 暗号演算 | AES-NI があれば HDD より速い可能性が高い。 | 主因と決めつける根拠は弱い。 |
| workqueue | I/O が追加キューを通ることで latency が増える場合がある。 | HDD でも影響し得るが、SSD で深刻化しないなら単独主因ではない。 |
| flush 伝播 | ext4 の barrier / flush が暗号化層を通って下層へ伝わる。 | journal と HDD の待ちを増幅しうる。 |
| sector size | 512e / 4Kn / LUKS sector size の不一致が効く場合がある。 | 実機確認が必要で、推定だけでは断定できない。 |
cryptsetup benchmark の扱いにも注意が必要である。cryptsetup-benchmark の man page は、この benchmark が memory only であり、実ストレージの暗号化速度を直接予測できないと明記している[22]。cryptsetup 自体は、暗号化デバイスを開くと kernel の dm-crypt driver が透過的に暗号化 / 復号を行う構造である[23]。したがって、cryptsetup benchmark が十分速くても、ext4 journal、HDD、SMR、USB bridge、flush が絡む実コピーが速いとは限らない。逆に、実コピーが遅いからといって、暗号演算そのものが遅いとも限らない。
10. FAT が軽かった理由を性能面だけで説明する
FAT は、MS-DOS 由来の単純で互換性の高いファイルシステムであり、Linux ネイティブな owner、group、permission、inode、journal、xattr、ACL を本質的に持たない。Microsoft の FAT32 specification は FAT を古い設計系譜に位置づけ、FAT 領域で cluster chain を管理する構造を説明している[24]。また exFAT 仕様でも、FAT は cluster chain を singly-linked list として表す構造として説明される[25]。
| FAT の特徴 | 性能上の軽さ | バックアップ上の代償 |
|---|---|---|
| journal なし | journal 書き込みがない。 | クラッシュ時の整合性回復能力は ext4 より弱い。 |
| Unix metadata なし | owner、group、mode の更新がない。 | Linux バックアップとしての情報保存能力は落ちる。 |
| inode なし | ext4 的な inode 管理がない。 | Linux のファイル属性を完全には保持できない。 |
| 単純な cluster chain | 構造が単純で書き込み経路が軽い。 | 大量ファイル、権限、整合性の扱いは限定的である。 |
したがって、TrueCrypt + FAT が速かったことを、「TrueCrypt が LUKS より速い」と読むのは危険である。旧構成では FAT が軽かった可能性が大きい。FAT は保持していない情報が多く、journal による整合性保護もなく、Linux の権限モデルも自然には保持しない。このため、2.5-inch HDD の弱点を露出させにくかった。一方、LUKS + ext4 は、暗号化の安全性、Linux ネイティブなメタデータ、journal、権限、復旧可能性を得る代わりに、書き込みの密度と順序保証を媒体へ要求する。ここに、性能上の負債がある。
11. 総容量ではなく、ファイル数とメタデータ更新回数が効く
バックアップ性能を容量だけで見ると誤る。1TB の大きな単一ファイルを書き込む処理と、1TB 分の小ファイルを数十万個書き込む処理は、同じ 1TB でも HDD に対する負荷がまったく違う。前者は比較的シーケンシャルであり、後者は inode 作成、directory 更新、mtime 更新、journal commit、barrier、flush を大量に発生させる。SMART は媒体の信頼性や自己診断を読むために有用だが、SMART が正常であることは、小ファイル大量書き込みが速いことを意味しない[26]。
定量化の基本式は単純である。実効転送速度は、コピー対象総容量を経過秒数で割って求める。
v = \frac{S}{t}
\]
| 投入量 | 経過時間 | 実効速度 | 公称 140 MB/s との比較 |
|---|---|---|---|
| 1TB | 24 時間 | 約 11.6 MB/s | 約 8.3% に低下している。 |
| 2TB | 24 時間 | 約 23.1 MB/s | 約 16.5% に低下している。 |
| 2TB | 36 時間 | 約 15.4 MB/s | 約 11.0% に低下している。 |
| 2TB | 48 時間 | 約 11.6 MB/s | 約 8.3% に低下している。 |
ここでの比較は、2.5-inch HDD の最大 140 MB/s を実バックアップ速度の期待値にするためではない。むしろ、実効速度が 10 MB/s 台に落ちる場合、それは USB 3.x の規格上限ではなく、HDD の IOPS、SMR の cache 枯渇、ext4 metadata、journal commit、barrier、dm-crypt 経路、初回初期化の複合だと推定するための基準である。fio は random read / random write などの I/O パターンを指定してテストできるツールであり、fio documentation は write / randwrite / rw / randrw などを明示的に指定したときにデバイスを変更することを説明している[27]。Oracle の例でも、IOPS 測定として 4K random read、direct I/O、iodepth、runtime などを指定する形が示されている[28]。また hdparm の -t は、事前キャッシュされていないデータをディスクから buffer cache 経由で読む速度の目安を示すが、意味のある結果には inactive な状態で複数回実行する必要がある[29]。
| 測定対象 | 取得する値 | 切り分けられる要因 |
|---|---|---|
| 総容量 | 対象ディレクトリの合計サイズ | 実効 MB/s を計算できる。 |
| ファイル数 | 通常ファイルの件数 | inode と metadata 更新回数を推定できる。 |
| ディレクトリ数 | ディレクトリの件数 | directory metadata 更新量を推定できる。 |
| 平均ファイルサイズ | 総容量 ÷ ファイル数 | 大ファイル支配か小ファイル支配かを判定できる。 |
| 生ブロック速度 | 暗号化層なし、ファイルシステムなしの速度 | 媒体自体の逐次性能を見られる。 |
| 小ブロック random write | 4K random write IOPS | metadata / journal / SMR に近い弱点を見られる。 |
12. 要因別メタアナリシス
ここまでの情報を統合すると、今回の性能問題は、LUKS 単独、ext4 単独、SMR 単独、HDD 単独のどれか一つではなく、複数の層が重なった結果として説明するのが最も整合的である。特に重要なのは、5TB HDD では問題が発生しなかった一方で、2TB HDD では問題が発生した点である。この差は、「2.5-inch HDD はすべてだめ」とも「LUKS + ext4 はすべてだめ」とも言えないことを示している。正しくは、媒体モデルごとの内部設計、ファームウェア、SMR 実装、USB ブリッジ、キャッシュ、初期化状態、ワークロードの組み合わせで判断する必要がある。
| 要因 | 寄与度 | 確度 | 根拠 |
|---|---|---|---|
| 2.5-inch HDD の低 IOPS | 極大 | 高 | 5400 rpm、機械的 seek、回転待ちが小ファイル大量処理で効く。 |
| SMR | 極大 | 中〜高 | 2TB 級 2.5-inch HDD には Drive-Managed SMR 採用例があり、media cache 枯渇と band rewrite が説明力を持つ。 |
| ext4 journal / metadata | 大 | 高 | data=ordered、journal、inode、permission、mtime 更新が FAT より重い。 |
| barrier / flush | 大 | 中〜高 | write barrier は既定で有効であり、HDD では待ち時間として見えやすい。 |
| mkfs.ext4 直後の lazy init | 中〜大 | 中 | 初回マウント後の inode table 初期化が大量投入と競合しうる。 |
| dm-crypt 経路 | 中 | 中 | workqueue と I/O 経路の影響はあるが、Stick SSD や 5TB HDD で深刻化しないなら単独主因ではない。 |
| FAT の軽さ | 大 | 高 | journal、Unix metadata、inode 管理を持たないため、旧構成では媒体の弱点が露出しにくかった。 |
| コピーコマンド差 | 除外 | 高 | rsync でも同様のため、今回の主要因から外す。 |
この整理から分かるのは、今回の問題を「LUKS が遅い」「ext4 が遅い」「2.5-inch HDD がだめ」と単純化してはいけないということである。LUKS + ext4 は、Linux バックアップ媒体として論理的には整っている。しかし、その整合性は無償ではない。2.5-inch 2TB HDD のような低 IOPS、SMR、低電力、USB 接続、キャッシュ制約を持つ媒体では、ext4 の journal、metadata、barrier、lazy initialization、dm-crypt の I/O 経路が重なり、TrueCrypt + FAT 時代には見えていなかった媒体性能の限界が露出する。
13. 運用上の結論
運用判断としては、LUKS + ext4 を捨てる必要はない。しかし、すべての媒体に一律で LUKS + ext4 を適用するべきでもない。SSD や 3.5-inch CMR HDD では、LUKS + ext4 は暗号化バックアップの主系として妥当である。一方、2.5-inch 2TB HDD、特に SMR の可能性があり、実測で性能問題が出た媒体は、大量更新先ではなく、低頻度アーカイブ、互換バックアップ、持ち出し用、あるいは既存 TrueCrypt + FAT 媒体の更新停止保全先として役割を限定する方が合理的である。
| 媒体 | LUKS + ext4 適性 | 推奨用途 | 判断理由 |
|---|---|---|---|
| SSD | 高い | 更新頻度の高い暗号化バックアップ | seek がなく、小書き込みと metadata 更新を吸収しやすい。 |
| 3.5-inch CMR HDD | 中〜高 | 大容量バックアップ、定期同期 | 電源と筐体に余裕があり、SMR より更新性能が安定しやすい。 |
| Seagate Expansion Portable 5TB | 中 | 実測上問題がない範囲での暗号化バックアップ | 同じ 2.5-inch でも今回の観測では致命的問題が出ていない。 |
| Transcend StoreJet 25M3S 2TB | 低〜中 | 低頻度保管、持ち出し、更新量を絞った用途 | 実測で LUKS + ext4 の大量更新が破綻している。 |
| TrueCrypt + FAT 既存媒体 | 新規主系には不適 | 互換バックアップ、既存資産保全 | 性能面では軽いが、Linux バックアップ完全性と将来運用性は弱い。 |
結論は、LUKS + ext4 が間違っていた、ではない。今回の教訓は、暗号化方式の優劣ではなく、媒体ごとの性能特性を無視して同じ保存構造を一律適用してはいけない、という点にある。バックアップ設計では、暗号化方式、ファイルシステム、媒体種別、更新頻度、復元目的をまとめて評価する必要がある。論理的に正しい構成であっても、更新処理が実用時間内に終わらず、継続運用できないなら、復元可能性を支える設計としては不十分である。
参考文献
- id774, バックアップとは復元可能性を設計することである（2026-05-07）. https://blog.id774.net/entry/2026/05/07/4728/
- id774, バックアップ・リカバリー戦略における物理媒体管理（2026-05-10）. https://blog.id774.net/entry/2026/05/10/4743/
- id774, LUKS 暗号化の手順と運用（2026-05-11）. https://blog.id774.net/entry/2026/05/11/4746/
- id774, TrueCrypt 資産を GNU/Linux で保全する（2026-05-16）. https://blog.id774.net/entry/2026/05/16/4773/
- id774, 未来の自分に意味を残す（2026-05-12）. https://blog.id774.net/entry/2026/05/12/4750/
- Seagate, Expansion Portable Drive Data Sheet. https://www.seagate.com/www-content/datasheets/pdfs/expansion-portable-DS2060-1-2102-WW-en_US.pdf
- Seagate, BarraCuda 2.5-inch HDD Data Sheet. https://www.seagate.com/www-content/datasheets/pdfs/barracuda-2-5-DS1907-3-2005US-en_US.pdf
- Transcend, StoreJet 25M3 Portable Hard Drives. https://us.transcend-info.com/product/external-hard-drive/storejet-25m3
- Transcend, StoreJet 25M3 Product Sheet. https://docs.rs-online.com/a21c/0900766b816fadae.pdf
- Dateks, Transcend StoreJet 25M3 2TB Specification Summary. https://www.dateks.lv/en/cenas/external-hdd/164160-transcend-storejet-25m3-2tb-green
- Western Digital, Shingled Magnetic Recording HDD Technology White Paper. https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/western-digital/collateral/white-paper/white-paper-shingled-magnetic-recording-hdd-technology.pdf
- Toshiba, Shingled Magnetic Recording Technologies for Large-Capacity Hard Disk Drives. https://www.global.toshiba/content/dam/toshiba/migration/corp/techReviewAssets/tech/review/en/01_02/pdf/a08.pdf
- Toshiba, MQ04AB Series Product Overview. https://toshiba.semicon-storage.com/content/dam/toshiba-ss-v3/master/en/storage/product/internal-specialty/cHDD-MQ04AB_product-overview_r2s.pdf
- Linux Kernel Documentation, ext4 General Information. https://docs.kernel.org/admin-guide/ext4.html
- Linux Kernel Documentation, ext4 Journal. https://www.kernel.org/doc/html/latest/filesystems/ext4/journal.html
- Linux Kernel Documentation, ext4 Block and Inode Allocation Policy. https://docs.kernel.org/filesystems/ext4/allocators.html
- man7.org, ext4(5) Linux manual page. https://man7.org/linux/man-pages/man5/ext3.5.html
- man7.org, mke2fs(8) Linux manual page. https://man7.org/linux/man-pages/man8/mke2fs.8.html
- man7.org, mke2fs.conf(5) Linux manual page. https://man7.org/linux/man-pages/man5/mke2fs.conf.5.html
- Linux Kernel Documentation, dm-crypt. https://docs.kernel.org/admin-guide/device-mapper/dm-crypt.html
- Cloudflare, Speeding up Linux disk encryption. https://blog.cloudflare.com/speeding-up-linux-disk-encryption/
- man7.org, cryptsetup-benchmark(8) Linux manual page. https://man7.org/linux/man-pages/man8/cryptsetup-benchmark.8.html
- Debian manpages, cryptsetup(8). https://manpages.debian.org/testing/cryptsetup-bin/cryptsetup.8.en.html
- Microsoft, FAT32 File System Specification. https://www.cs.fsu.edu/~cop4610t/assignments/project3/spec/fatspec.pdf
- Microsoft Learn, exFAT Specification. https://learn.microsoft.com/en-us/windows/win32/fileio/exfat-specification
- Oracle, smartctl(8) Manual Page. https://docs.oracle.com/cd/E75431_01/html/E72377/smartctl-8.html
- fio Documentation, Flexible I/O tester. https://fio.readthedocs.io/en/latest/fio_doc.html
- Oracle Cloud Infrastructure Documentation, Sample FIO Commands for Block Volume Performance Tests. https://docs.oracle.com/en-us/iaas/Content/Block/References/samplefiocommandslinux.htm
- man7.org, hdparm(8) Linux manual page. https://man7.org/linux/man-pages/man8/hdparm.8.html