はじめに
- 本記事は「Ubuntuで謎のフリーズに悩まされた末、原因特定→対処→復旧→Qiitaに記事投稿」というリアルタイム地獄ログ＋復活物語を記録したものです
- 本記事は詳細版です。ダイジェスト版を読みたい方はこちら：UbuntuでHDDから大量ファイルコピー中にフリーズしたので、原因と対処法だけまとめておく【ダイジェスト版】
環境
| 項目 | 内容 |
|---|---|
| OS | Ubuntu 24.04 LTS |
| GPU | NVIDIA RTX 4090 |
| ディスプレイ | HDMI接続（IODATA） |
| 外部HDD | TOSHIBA HDTB540AK3CA（4TB／USBバスパワー） |
| コピー元 | 約72GBの画像ディレクトリ |
| コピー先 | 内部NVMe SSD |
| コピー方法（当初） | GUIのドラッグ＆ドロップ |
第1章：最初のフリーズと異変の始まり
Ubuntu 24.04上で、外付けHDDに保存していた約72GBの画像データを本体ストレージへコピー中に、最初の異常が発生しました。
※コピー元には、研究用途で扱っているデータが含まれているため、
本記事ではディレクトリ名やファイル名など、特定につながる情報は伏せています。
構造や処理フローが伝わるよう、仮想的なディレクトリ名を用いて説明しています。
構成としては、複数の画像ファイルとそれに対応するメタデータを含むフォルダ群です。
コピー元ディレクトリは以下のような構成でした（例）：
/media/USER/EXTERNAL_DRIVE/
└── project_data/
├── images/（数万枚の画像ファイル）
├── metadata/（CSV・JSON形式の補足情報）
└── log_files/
操作は単純で、HDD内の2つのディレクトリをGUI（ファイルマネージャ）経由でドキュメントフォルダへドラッグ＆ドロップしただけです。
そして異常が発生：
コピー開始から数分後、画面の反応がなくなりました。
マウスポインタが消失し、キーボード操作も受け付けず、ショートカット（Ctrl + Alt + F2等）によるTTY切り替えも無反応。
いわゆるフリーズ状態で、デスクトップ環境も含めて完全に操作不能になりました。
やむを得ず電源ボタンによる強制シャットダウンを実行。
PCを再起動しましたが、次に表示されるはずのログイン画面が現れず、画面全体が真っ暗なままとなりました。
起動音は鳴っており、OS自体は立ち上がっている様子。
ここで試したのが、ディスプレイ本体の電源を一度オフ→オンにする方法（いわゆる“電源芸”）。
この操作により、ログイン画面が正常に表示され、画面表示の復帰に成功しました。
第2章：復帰と再発 ― 表示問題とコピー地獄の始まり
ディスプレイの電源を一度オフにしてから再度オンにすることで、ログイン画面の表示が復活。
ログイン後、デスクトップ環境も通常通り操作可能となり、一時的にフリーズからの復帰に成功しました。
再起動後は特に問題がなかったため、再度コピー作業を実施。
同様に、外付けHDDから内蔵SSDへ画像ファイル（合計約72GB）を転送しようとしたところ、数十分後に再びフリーズが発生。
現象は1回目とほぼ同様で：
- マウスが反応しなくなる
- キーボードも無反応（TTY切り替え不可）
- 画面は静止状態で、操作不能
このときも再起動後にログイン画面が表示されない状態となりましたが、前回と同じくディスプレイの電源を入れ直すことで映像出力が復活しました。
この「ディスプレイ電源芸」は以降、再起動後の表示問題に対する有効な暫定対処法として扱うことになります。
※なお、フリーズ後にディスプレイが黒い状態でも、
ディスプレイ本体の電源を一度OFF→ONすることで表示が復帰するケースがありました。
原因は明確ではないものの、再現性が高かったため、本記事では「ディスプレイ電源芸」として暫定対処法に含めています。
✔ 観察時点での仮説
- フリーズのきっかけはファイルコピー中
- 原因の可能性として、外付けHDDとのI/O関連の問題が疑われる
- GPUやディスプレイ側の物理的問題ではなく、処理待ち or デバイス応答不良によるフリーズの可能性が高まる
第3章：原因調査とrsyncへの移行
複数回のフリーズを経て、コピー作業中に何かしらの負荷または処理待ちが発生していると推定。
同じHDDから、同じディレクトリをコピーしようとした際にフリーズが再現したことから、原因の切り分けを始めました。
実行した調査コマンド：
xrandr # ディスプレイ認識状況の確認
nvidia-smi # GPUドライバ・プロセス確認
journalctl -b # 起動ログ・エラーログ確認
df -h / du -sh # ストレージの使用状況・転送量の確認
→ これらの出力から、GPUや出力の異常はなし。OS・GUI自体は起動しており、I/O系の問題と推定。
✔ 本格的な仮説
- USBバスパワーHDDの処理遅延・オーバーヒート
- 回転式で冷却なしのHDDが72GBの一括コピーに耐えきれず、処理詰まり
- 応答遅延が蓄積し、Ubuntu側がハングと誤認 → フリーズ発生
rsyncへの移行（第1の処置）
GUIのドラッグ＆ドロップをやめ、端末上でrsyncによる制御付きコピーに切り替え：
rsync -avh --progress /source/ /destination/
- -a：アーカイブモード（タイムスタンプやシンボリックリンク等を維持）
- -v：詳細表示（転送ログ）
- -h：人間に読みやすい表示
- --progress：転送進行状況を表示
結果：
しばらく安定していたが、やはり途中でフリーズ再発。
→ コピー方法の切替だけでは根本解決せず。
第4章：帯域制限と安定化 ― rsyncによる低負荷転送
最終的に有効だったのが、rsyncに帯域制限オプション--bwlimitを加える構成。
rsync -avh --progress --bwlimit=1024 --partial --inplace /source/ /destination/
オプション解説（追加分）：
-
--bwlimit=1024：最大帯域を1024KB/s（＝1MB/s）に制限 → HDDのI/O負荷を抑えて熱や処理詰まりを防ぐ -
--partial --inplace=：中断したファイルを再利用しつつ再開できるようにする
他の構成例
# 転送速度制限なし（高速だけど不安定になる可能性あり）
rsync -avh --progress /source/ /destination/
# 帯域制限あり（推奨・今回使用）
rsync -avh --progress --bwlimit=1024 --partial --inplace /source/ /destination/
# コピー中断→再開のための構成（安全な運用）
rsync -avh --progress --partial --inplace --append /source/ /destination/
→ 目的に応じて使い分け可能。 この柔軟性がrsyncの強み。
✔ 状況の変化
この帯域制限付きrsyncにより：
- 転送速度は抑えられる（例：1GB ≒ 約17分）
- しかし、フリーズしない・マウスが止まらない
- 「進行中」が可視化され、心理的にも安定
→ 最初の安定動作を確認！
第5章：犯人はHDDだった ― バスパワーの限界
ここまでの検証で、Ubuntuのフリーズ原因は外付けHDDのI/O処理の詰まりによるものとほぼ断定できました。
問題となったHDDの情報
| 項目 | 内容 |
|---|---|
| 製品名 | TOSHIBA HDTB540AK3CA |
| 容量 | 4TB |
| 接続方式 | USB 3.0（バスパワー） |
| 特徴 | 2.5インチポータブル／回転式（おそらく5400rpm）／ファンレス |
✔ 問題点①：バスパワー供給の限界
- USBポートからの給電だけで動くため、電力が不安定。
- 高負荷時に処理が鈍化・遅延しやすい。
✔ 問題点②：回転式（HDD）によるアクセス遅延
- 回転ディスクのため、 小ファイルやランダムアクセスが極端に遅くなる。
- I/O待ちが爆発的に増加 → システム応答不能へ。
✔ 問題点③：長時間連続動作時の発熱
- 冷却性能が低く、長時間アクセスで高温に。
- これがさらに処理遅延を誘発し、Ubuntu側が“フリーズ”と誤認。
✔ 対処の方向性
バスパワーHDD → セルフパワーHDD or SSD に切り替える
高速大量コピーは 内部SSD経由で処理してから移動
-
rsync + --bwlimitを常用ツール化する
結論：
UbuntuやGPUが壊れていたわけではなく、ボトルネックはHDDだった。
単なる構成ミスによるI/Oオーバーロードであり、 “事故ではあるが故障ではない” という厄介なパターンでした。
第6章：まとめと教訓 ― フリーズを越えて
✔ 今回の主な原因
- 回転式・バスパワーHDDのI/O詰まり
- 過負荷でUbuntuが完全フリーズ
- GUIコピー・rsync標準設定では対処不可
✔ 効果があった対策
| 対処法 | 内容 |
|---|---|
rsync使用 |
コピー制御が可能、再開もスムーズに |
--bwlimit=1024 |
転送負荷の抑制に効果的 |
--partial --inplace |
再開時の処理効率UP |
| ディスプレイ電源芸 | 黒画面時の復旧に高い成功率 |
✔ 今後の運用指針
- セルフパワー or SSD の活用を優先
- GUIコピーは非推奨、rsyncの標準運用へ
- フリーズ時は焦らず、ログと観察で対処
✔ 補足：再起動・復旧時の安全手順
1. Ctrl + Alt + F2 → 反応を確認
2. 反応なければ電源ボタンでシャットダウン
3. 起動後、画面が黒い場合 → ディスプレイ電源OFF→ON
4. それでも映らない場合は別ディスプレイや再起動を検討
表示されない＝壊れてる、ではない。
Ubuntuは案外、中でちゃんと生きてる。
あとがき：これは未来の自分へのメモです
Ubuntuを使っていて「突然何も動かなくなった」「ファイルコピーしただけでPCが沈黙した」
そんな経験を、 “原因不明の事故”として片付けたくなかった。
だから今回、フリーズのたびに再起動して、ログを取り、原因を探し、解決法を試し続けました。
その結果として得られた知見をこうしてまとめておきます。
※本記事は、将来また同じ事故を起こすであろう自分に向けた手紙です。
そして、同じようにUbuntuとHDDに挟まれて困っている誰かの参考になれば幸いです。
最後に：便利なコマンドまとめ
# ディスク容量確認
df -h
du -sh /path/to/directory/
# 転送
rsync -avh --progress --bwlimit=1024 --partial --inplace /src/ /dst/
# GPU確認（NVIDIA系）
nvidia-smi
# 映像出力確認
xrandr
# 起動ログ・異常検出
journalctl -b | grep -Ei 'nvidia|xorg|hdmi'
# コピー中プロセス確認
ps aux | grep rsync