「モデルファイルを別のHDDに移したいが、どのディレクトリを操作すれば壊れないのかわからない」
そんな悩みを抱えるLinuxサーバー管理者は多いはずです。この記事では、Ollamaのモデルファイルがどこに保存されているかを確認する手順から、OLLAMA_MODELS環境変数を使った保存先変更、外付けHDDやNASへの移転、不要モデルの削除と容量回収、さらにバックアップと別サーバーへの復元まで、実務視点で一通り解説します。
70B級モデルを2～3本抱えると、数百GBはあっという間に溶けます。計画的なストレージ管理が、ローカルLLM運用を長続きさせる鍵です。
この記事のポイント
・OLLAMA_MODELS環境変数でモデル保存先を任意のパスに変更できる
・外付けHDDへの移転はrsyncとサービス停止で安全に実施できる
・ollama rmで削除してもblobsに孤立ファイルが残る場合がある
・バックアップはblobsとmanifests両方を対象にしないと復元できない
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
まずモデルファイルがどこに保存されているかを確認する
Ollamaのモデルファイルは、インストール方式によって保存先が変わります。公式スクリプト（curl https://ollama.com/install.sh | sh）でインストールした場合は、`ollama` ユーザーが自動作成されてサービスが起動し、モデルは `/usr/share/ollama/.ollama/models` 以下に保存されるのが一般的です。
一般ユーザーが手動で起動している場合は `~/.ollama/models` になります。
まず現在の保存先を確認しましょう。Ollamaの起動時の環境変数を調べるのが確実な方法です。
# ollamaサービスの環境変数を確認する（systemdサービスとして動いている場合） $ sudo systemctl show ollama | grep -i environment # または、ollamaサービスの設定ファイルを直接確認する $ sudo cat /etc/systemd/system/ollama.service
モデルファイルは `models/blobs/` にSHA256ハッシュ名で保存され、`models/manifests/` にバージョン情報が入ります。blobsがディスクの大半を占め、manifestsは数MB程度です。
Ollamaのインストールとsystemdサービス化の手順については、Ubuntu ServerでローカルLLMを構築する方法で詳しく解説しています。
1. ollama listで現在のモデル一覧とサイズを確認する
どのモデルがどれほどのディスクを占有しているかを一覧で把握します。$ ollama list NAME ID SIZE MODIFIED llama3.3:70b-instruct-q4_K_M 1a2b3c4d5e6f 42 GB 2 hours ago mistral:7b-instruct-q8_0 7f8e9d0a1b2c 7.7 GB 1 day ago gemma3:27b-instruct-q4_0 3c4d5e6f7a8b 16 GB 3 days ago
複数モデルを試し続けると、100GBはあっという間に超えます。
サイズ列を見て、実際の用途で使っていないモデルがないか定期的に確認する習慣をつけておきましょう。
2. blobsディレクトリで実際のファイルサイズを確認する
ollama listのSIZEとblobsの実ファイルサイズを突き合わせます。差が大きい場合は孤立ファイルを疑います。# blobsの合計サイズを確認する $ sudo du -sh /usr/share/ollama/.ollama/models/blobs/ 66G /usr/share/ollama/.ollama/models/blobs/ # modelsディレクトリ全体のサイズを確認する $ sudo du -sh /usr/share/ollama/.ollama/models/ 66G /usr/share/ollama/.ollama/models/
manifestsは10MB程度であるため、ディスク圧迫の原因はほぼblobsです。
ディスク使用量を定期的に把握してストレージの肥大化に気づく
システムドライブの残量が枯渇すると、Ollamaのモデルダウンロード途中でプロセスが異常終了したり、Linuxシステム全体が不安定になります。70Bモデルは42GBを一気に消費するため、ダウンロード前に残量を確認する習慣が欠かせません。
定期的なチェックを怠ると、気づいたときには残り数GBという状況になりがちです。現場のインフラエンジニアに聞いた話では、ローカルLLMを導入してから半年も経たないうちにシステムドライブを使い果たしたケースも珍しくないそうです。
モデルを試すたびにダウンロードしてそのまま放置するのが最大の要因です。
1. dfコマンドでシステム全体のディスク残量を確認する
$ df -h ファイルシス サイズ 使用 残り 使用% マウント位置 /dev/sda1 200G 162G 38G 82% / /dev/sdb1 2.0T 820G 1.2T 41% /mnt/data tmpfs 16G 1.2G 15G 8% /dev/shm
cronで週次に `df -h` の結果をメールに送る仕組みを作っている現場もあります。
システムドライブとデータドライブを分離しているサーバーでは、/mnt/dataのような別パーティションをOLLAMA_MODELSに指定するだけでシステムドライブへの影響をゼロにできます。
2. watchコマンドでダウンロード中の残量変化をリアルタイム確認する
70Bモデルのダウンロード中は、GB単位で残量が減るのが目視できます。ダウンロード前に残量を確認し、十分な余裕がある状態で実行してください。
# 30秒ごとにdfを更新表示する（Ctrl+Cで終了） $ watch -n 30 df -h
ダウンロード完了前にディスクが枯渇すると、中途半端なファイルが残ってblobsを圧迫します。
OLLAMA_MODELS環境変数で保存先ディレクトリを変更する
保存先を変更するもっともシンプルな方法は、OLLAMA_MODELS環境変数に任意のパスを指定することです。Ollamaをsystemdサービスとして動かしている場合は、override.confに記述するのが定石です。再起動後も設定が維持されます。
この方法でOLLAMA_MODELSを変更すると、以降のモデルダウンロードは新しいパスに保存されます。ただし、すでにダウンロード済みのモデルは自動的には移動しません。移転手順は次のセクションで説明します。
override.confを使ったsystemd設定の詳細については、OllamaのsystemdサービスをUbuntuで設定する方法を参考にしてください。
1. override.confを作成してOLLAMA_MODELSを設定する
# override.conf格納ディレクトリを作成する $ sudo mkdir -p /etc/systemd/system/ollama.service.d # override.confを作成してOLLAMA_MODELSを設定する $ sudo tee /etc/systemd/system/ollama.service.d/override.conf << 'EOF' [Service] Environment="OLLAMA_MODELS=/mnt/data/ollama-models" EOF # 設定内容を確認する $ cat /etc/systemd/system/ollama.service.d/override.conf [Service] Environment="OLLAMA_MODELS=/mnt/data/ollama-models"
権限の設定を後回しにすると、再起動後に「permission denied」が発生します。
2. 新しい保存先ディレクトリを作成して権限を設定する
# ディレクトリを作成する $ sudo mkdir -p /mnt/data/ollama-models # ollamaユーザーに所有権を付与する $ sudo chown -R ollama:ollama /mnt/data/ollama-models # 権限を確認する $ ls -la /mnt/data/ | grep ollama-models drwxr-xr-x 2 ollama ollama 4096 Jul 29 17:00 ollama-models
chownを忘れずに実行してください。
3. systemdを再読み込みしてollamaを再起動する
# systemdの設定を再読み込みする $ sudo systemctl daemon-reload # ollamaサービスを再起動する $ sudo systemctl restart ollama # 設定が反映されたことを確認する $ sudo systemctl show ollama | grep OLLAMA_MODELS Environment=OLLAMA_MODELS=/mnt/data/ollama-models
試しにモデルをpullして新しいパスに保存されることを確認しましょう。
外付けHDDやNASにモデルを安全に移転する手順
OLLAMA_MODELSを変更しても、既存のモデルは旧パスに残ります。手動でblobsとmanifests両方を移転する必要があります。移転中にollamaが起動していると、ファイルが破損するリスクがあるため、必ずサービスを停止してから作業してください。
移転先の外付けHDDは、あらかじめext4でフォーマットしてLinuxの権限管理が使えるようにしておくのが基本です。NTFSではLinuxの所有者情報が正しく扱えず、chownが効かないことがあります。
また、Ollamaのモデルを複数用意してチームで利用する際の考え方は、社内でChatGPTが使えないときの代替手段に情シス向けの視点でまとまっています。合わせて参照してください。
1. ollamaサービスを停止する
# ollamaサービスを停止する $ sudo systemctl stop ollama # 完全に停止したか確認する（Active: inactive (dead) と表示されればOK） $ sudo systemctl status ollama
Ollamaが動いているとblobsへの書き込みが行われる場合があり、コピー中のデータ整合性が保証されません。
2. rsyncで既存モデルを新しい保存先にコピーする
`cp -r` でもコピーできますが、rsyncは進捗表示・中断再開・整合性確認が優れています。42GBの70Bモデルをコピーする場合、途中でネットワーク断や電源断が起きても再開できる点でrsyncが実務で選ばれます。
# blobsとmanifestsをまとめてコピーする $ sudo rsync -ah --progress \ /usr/share/ollama/.ollama/models/ \ /mnt/data/ollama-models/ # コピー後にサイズを比較して確認する $ sudo du -sh /usr/share/ollama/.ollama/models/ 66G /usr/share/ollama/.ollama/models/ $ sudo du -sh /mnt/data/ollama-models/ 66G /mnt/data/ollama-models/
HDDへのコピーは、70Bモデルで10分以上かかることがあります。
3. ollamaを起動して新しい保存先からモデルが使えるか確認する
# ollamaサービスを起動する $ sudo systemctl start ollama # モデル一覧を確認する（新しい保存先のモデルが表示されるはず） $ ollama list # テスト実行する $ ollama run mistral:7b-instruct-q8_0 "テスト実行"
削除は慎重に行い、新しい保存先で十分確認してから実施してください。
不要なモデルを削除してディスク容量を回収する
モデルを整理するには `ollama rm` コマンドが基本ですが、削除後もblobsに孤立ファイルが残るケースがあります。また、複数モデルがblobsの同一ファイルを共有する構造のため、blobsを直接手動削除するのは危険です。必ずollamaのコマンド経由で削除してください。
どのモデルを残すか迷う場合は、ローカルLLMのモデルを比較する方法を参考にしてください。Llama3.3・Mistral・Gemma 3・Phi-4の用途別の使い分けが整理されています。
1. ollama rmで不要なモデルを削除する
# 削除対象を確認する $ ollama list # モデルを削除する（モデル名:タグまで指定する） $ ollama rm llama3.3:70b-instruct-q4_K_M deleted 'llama3.3:70b-instruct-q4_K_M' # 削除後に残りのモデルを確認する $ ollama list
blobsの実ファイルはOllamaが参照カウントを管理し、他のモデルと共有されていない場合は自動削除されます。
削除後はdfコマンドで実際に容量が回収されているか確認しましょう。
2. 孤立したblobsファイルが残っていないか確認する
まれに `ollama rm` 後もblobsに不要ファイルが残り、ディスクが期待通りに解放されないことがあります。ollama listの合計サイズとblobsの実ファイルサイズを比較して確認します。
# blobsのファイル数と合計サイズを確認する $ sudo ls /usr/share/ollama/.ollama/models/blobs/ | wc -l 12 $ sudo du -sh /usr/share/ollama/.ollama/models/blobs/ 24G /usr/share/ollama/.ollama/models/blobs/ # ollama listで残りモデルの合計を確認し、上記のサイズと比較する $ ollama list
それでも解消しない場合は、manifestsから必要なモデルのblobハッシュを特定し、参照されていないblobsを慎重に手動削除する方法もあります。
モデルファイルをバックアップして別サーバーへ復元する
70Bモデルのダウンロードは数十分かかります。バックアップがあれば、ディザスタリカバリや新規サーバー構築の時間を大幅に短縮できます。同じ環境を複数のUbuntu Serverに展開したい場合も、tarで固めてscpで転送するのが確実な方法です。
モデルファイルのバックアップで重要なのは、blobsとmanifestsを必ずセットで保存することです。blobsだけでは `ollama list` にモデルが表示されず、Ollamaから利用できません。
1. tarでモデルディレクトリをアーカイブする
# ollamaを停止してからアーカイブする（ファイル破損防止） $ sudo systemctl stop ollama # blobsとmanifests両方を一括アーカイブする（非圧縮・高速） $ sudo tar -cf /mnt/backup/ollama-models-20260729.tar \ -C /usr/share/ollama/.ollama models/ # アーカイブサイズを確認する $ ls -lh /mnt/backup/ollama-models-20260729.tar -rw-r--r-- 1 root root 66G Jul 29 17:15 ollama-models-20260729.tar
ネットワーク転送速度がボトルネックになる場合のみ圧縮を検討してください。
非圧縮であれば圧縮・展開のCPU負荷がないため、コピーが速く完了します。
2. 別サーバーへscpで転送して復元する
# 転送先サーバーに送信する（転送先IPが192.168.1.102の場合） $ scp /mnt/backup/ollama-models-20260729.tar \ user@192.168.1.102:/tmp/ # 転送先サーバーで展開する（ollamaインストール済みで停止中の状態で実施） $ sudo tar -xf /tmp/ollama-models-20260729.tar \ -C /usr/share/ollama/.ollama/ # 権限を設定してollamaを起動する $ sudo chown -R ollama:ollama /usr/share/ollama/.ollama/models/ $ sudo systemctl start ollama # モデルが認識されているか確認する $ ollama list
Ollamaを新規インストールした直後の状態でも、この手順でモデルをそのまま引き継げます。
同一ネットワーク内であれば、scpの代わりにrsyncを使うとネットワーク断時の再開が可能です。
よくあるトラブルと対処法｜権限エラー・マウント消失・起動失敗
保存先を変更したときに遭遇しやすいトラブルを3つまとめます。症状ごとに原因と対処が対応しているので、エラーが出たら順番に確認してください。
ほとんどのトラブルは権限の設定ミスとfstabの未設定の2パターンに集約されます。落ち着いて確認すれば解決できます。
1. 「permission denied」でモデルが読み込めない
OLLAMA_MODELSを変更した後に「permission denied」が出る原因のほとんどは所有者の設定ミスです。特に外付けHDDをマウントした直後はrootが所有者になっているため、chownが欠かせません。
# 新しい保存先ディレクトリの所有者を確認する $ ls -la /mnt/data/ | grep ollama-models drwxr-xr-x 3 root root 4096 Jul 29 17:00 ollama-models # ollamaユーザーに所有権を修正する $ sudo chown -R ollama:ollama /mnt/data/ollama-models # ollamaを再起動して確認する $ sudo systemctl restart ollama $ ollama list
2. 再起動後にマウントが消えてollamaが起動しない
外付けHDDに保存先を変更した後にサーバーを再起動したら、マウントが消えてollamaがエラーになるケースがあります。`/etc/fstab` に自動マウントの設定がなければ、再起動後はアンマウント状態になります。
# 外付けHDDのUUIDを確認する $ sudo blkid /dev/sdb1 /dev/sdb1: UUID="1a2b-3c4d" TYPE="ext4" # /etc/fstabに自動マウントを追記する（UUIDは上記の実際の値に置き換える） $ echo 'UUID=1a2b-3c4d /mnt/data ext4 defaults 0 2' | sudo tee -a /etc/fstab # 設定を反映してマウントされているか確認する $ sudo mount -a $ df -h | grep /mnt/data /dev/sdb1 2.0T 820G 1.2T 41% /mnt/data
ollamaサービスがマウント完了後に起動するよう、override.confの `After=` に `local-fs.target` を追加しておくとより確実です。
3. 「model not found」でモデルが見つからない
OLLAMA_MODELS変更後に `model not found` が出る場合は、移転が未完了か環境変数が反映されていないかのどちらかです。# 環境変数が正しく反映されているか確認する $ sudo systemctl show ollama | grep OLLAMA_MODELS Environment=OLLAMA_MODELS=/mnt/data/ollama-models # 新しい保存先にmanifestsが存在するか確認する $ sudo ls /mnt/data/ollama-models/manifests/registry.ollama.ai/library/ llama3.3 mistral gemma3
manifestsが空の場合は rsync で旧パスから転送し直してください。
旧パスでは `ollama list` でモデルが見えていても、OLLAMA_MODELSが別パスに向いていれば参照されません。
まとめ：Ollamaストレージ管理のベストプラクティス
Ollamaのモデルファイルは、OLLAMA_MODELS環境変数で保存先を柔軟に変更できます。外付けHDDやNASへの移転もrsyncで確実に実施でき、別サーバーへのバックアップと復元もtarとscpで完結します。
ディスク使用量の定期確認と、モデル削除後のblobs孤立ファイル確認、この2点を習慣にするだけで、ストレージが原因の障害は大幅に減ります。
長期運用を見越して、最初からOLLAMA_MODELSを大容量ドライブに向けておくのがもっとも楽な方法です。構築時の設定1つで、後の管理コストを大きく削減できます。
| 操作 | コマンド例 | ポイント |
|---|---|---|
| 保存場所の確認 | sudo systemctl show ollama | grep OLLAMA_MODELS |
デフォルトは /usr/share/ollama/.ollama/models |
| モデル一覧とサイズ確認 | ollama list |
70B級は40GB超えが普通 |
| ディスク残量確認 | df -h |
使用率80%超えで整理を検討 |
| 保存先の変更 | OLLAMA_MODELS=/mnt/data/ollama-models（override.conf記載） |
daemon-reload＋restart必須 |
| モデルの移転 | sudo rsync -ah --progress /usr/share/ollama/.ollama/models/ /mnt/data/ollama-models/ |
サービス停止後に実施 |
| 不要モデルの削除 | ollama rm モデル名:タグ |
blobs孤立ファイルの残存を要確認 |
| バックアップ | sudo tar -cf アーカイブ名.tar -C /usr/share/ollama/.ollama models/ |
blobsとmanifests両方が必要 |
| 別サーバーへ復元 | sudo tar -xf アーカイブ名.tar -C /usr/share/ollama/.ollama/ |
展開後にchownで権限設定 |
ローカルLLMのストレージ管理を実機で体験する
外付けHDDへのモデル移転や複数サーバーへのバックアップ復元を、実際のLinuxサーバーで操作するのが最短の習得ルートです。実機GPU環境で手を動かしながら習得したい方向けに、「ローカルAIマスターセミナー」を開催しています。
少人数（最大8名）ZOOMハンズオン形式で実施しています。
・Ubuntu ServerでローカルLLMを構築する方法｜Ollamaで機密データを外に出さず業務AIを動かす完全ガイド
・社内でChatGPTが使えないときの代替手段｜機密データを守るローカルLLMという選択肢
・ローカルLLMのモデルを比較する方法｜Llama3.3・Mistral・Gemma・Phi-4をUbuntuで使い分けるポイント
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：OllamaをAnsibleで複数Linuxサーバーに一括デプロイする方法｜Playbookで本番クラスターを統一管理する手順
- この記事の属するカテゴリ：ローカルLLMへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます