OllamaをLinuxサーバーごと移行する方法|モデル・systemd設定をrsyncで新環境へ移設する完全手順

運営:リナックスマスター.JP(代表 宮崎智広)
HOME > Linux技術 リナックスマスター.JP(Linuxマスター.JP) > ローカルLLM > OllamaをLinuxサーバーごと移行する方法|モデル・systemd設定をrsyncで新環境へ移設する完全手順
「VPSのスペックが足りなくなってOllamaを別サーバーに移したい」
「古いマシンからの乗り換えで、モデルを全部ダウンロードし直さずに済む方法が知りたい」

そんな状況に直面したLinuxエンジニアや情シス担当者は少なくないはずです。この記事では、OllamaをLinuxサーバーごと移行する手順をステップごとに解説します。
モデルファイルのrsync転送、systemdサービス設定の再現、OLLAMA_MODELS環境変数の確認、APIの疎通テストまで順を追ってカバーします。40GB以上になることもあるモデルデータを毎回ダウンロードし直さずに済む方法と、移行後のダウンタイムを最小化する並走確認の進め方も含めて解説します。

この記事のポイント

・OLLAMA_MODELSのパスを確認してモデルファイルの保存場所を特定する
・rsync --progress --partial でGBクラスの大容量モデルを中断再開しながら転送できる
・新サーバーでsystemd override.confを再設定してOllamaを自動起動する
・移行後は旧サーバーをすぐ削除せず最低1週間並走して動作を確認する


OllamaをLinuxサーバーごと移行する方法|モデル・systemd設定をrsyncで新環境へ移設する完全手順

「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Ollamaサーバー移行が必要になる典型的なシナリオ

OllamaはLinuxサーバーに密結合した形でインストールされます。モデルファイルはデフォルトで `~/.ollama/models/` または `OLLAMA_MODELS` 環境変数で指定したパスに保存され、systemdサービスとして常駐します。サーバーを変えるときはこのモデルファイルと設定をまとめて引っ越す必要があります。

移行が必要になる典型的なケースは以下の3つです。
・VPSのスペック不足(VRAM・RAM・CPUが足りなくなりプランを変更する)
・ハードウェアの老朽化(オンプレサーバーの交換・引退)
・クラウドプロバイダーの乗り換え(コスト最適化・リージョン変更)

注意すべきはモデルファイルのサイズです。Llama3.3の70Bモデルで40GB以上、Gemma 3の27Bモデルでも15GB以上あります。毎回インターネット経由でダウンロードし直すと帯域・時間・コストがかかります。rsyncで旧サーバーから直接転送するほうが効率的です。

Ollamaのセットアップそのものがまだの方は、先にUbuntu ServerでローカルLLMを構築する方法でOllamaのインストール手順を確認してください。

移行前に旧サーバーの環境情報を収集する

移行先で同じ動作を再現するために、旧サーバーの設定を事前に記録します。後から「どの環境変数を設定していたか」を調べるために旧サーバーにアクセスし直す手間を省けます。

1. Ollamaのバージョンと起動設定を確認する

まず旧サーバーで動いているOllamaのバージョンとsystemd設定を記録します。

$ ollama --version ollama version is 0.x.x $ systemctl cat ollama # /etc/systemd/system/ollama.service [Unit] Description=Ollama Service After=network-online.target [Service] ExecStart=/usr/local/bin/ollama serve User=ollama Group=ollama Restart=always ... # /etc/systemd/system/ollama.service.d/override.conf [Service] Environment="OLLAMA_HOST=0.0.0.0:11434" Environment="OLLAMA_MODELS=/data/ollama/models" Environment="OLLAMA_NUM_PARALLEL=2"

`systemctl cat ollama` を実行すると、ベースのサービスファイルとoverride.confの内容が両方まとめて表示されます。`Environment=` の行が新サーバーでも再現が必要な設定です。

2. インストール済みモデルを一覧表示する

$ ollama list NAME ID SIZE MODIFIED llama3.3:70b-instruct-q4_0 abc123def456 41.8 GB 2 days ago gemma3:27b-instruct-q4_K_M def456abc123 17.1 GB 5 days ago mistral:7b-instruct-q8_0 789abc012def 7.7 GB 1 week ago

この一覧と合計サイズをメモしておきます。転送後に同じモデルが揃っているかを照合するために使います。

3. OLLAMA_MODELSのパスを確認する

モデルファイルの実際の保存場所を確認します。

# systemdのEnvironmentに設定されているパスを確認 $ sudo systemctl show ollama | grep OLLAMA_MODELS Environment=OLLAMA_MODELS=/data/ollama/models # 環境変数が設定されていない場合はデフォルトパスを確認 $ sudo -u ollama ls ~/.ollama/models/ blobs manifests

`OLLAMA_MODELS` が設定されていればそのパスが、未設定であれば `~/.ollama/models/`(ollamaユーザーのホームディレクトリ直下)がモデルファイルの場所です。

Ollamaのモデルファイルとデータ量を確認する

転送前にデータ量を把握しておくと、rsyncの完了予測時間が立てやすくなります。帯域が100Mbpsであれば40GBの転送に約55分かかる計算です。

1. モデルディレクトリの容量を計測する

# OLLAMA_MODELSが設定されている場合 $ du -sh /data/ollama/models/ 42G /data/ollama/models/ # デフォルトパスの場合(ollamaユーザーのホームが/home/ollama等) $ sudo du -sh /home/ollama/.ollama/models/ 42G /home/ollama/.ollama/models/

2. ディレクトリ構造を確認する

Ollamaのモデルディレクトリは `blobs/` と `manifests/` の2層構造になっています。

$ ls /data/ollama/models/ blobs manifests $ ls /data/ollama/models/manifests/registry.ollama.ai/library/ gemma3 llama3.3 mistral

`blobs/` に実際のモデルウェイトファイル(shaダイジェスト名のファイル)が入り、`manifests/` にモデル名とバージョンのマッピングが入っています。この2ディレクトリをセットで転送しないとモデルが認識されないため注意してください。

モデル選定の背景についてはローカルLLMのモデルを比較する方法も参考にしてください。

rsyncで新サーバーへモデルファイルを転送する

rsyncはファイルの差分だけを転送するため、転送中断後の再開や増分バックアップに向いています。GBクラスのモデルファイルの移行に最適です。

1. 新サーバーの転送先ディレクトリを準備する

Ollamaをインストールする前に、転送先のディレクトリとollamaユーザーを準備します。

# 新サーバーで実行 $ sudo mkdir -p /data/ollama/models $ sudo useradd -r -s /bin/false -m -d /home/ollama ollama $ sudo chown -R ollama:ollama /data/ollama

2. rsyncでモデルファイルを転送する

旧サーバーから新サーバーへrsyncで転送します。`--progress` で進行状況を表示し、`--partial` で中断しても再開できるようにします。

# 旧サーバーで実行(SSH鍵認証済みであること) $ rsync -avz --progress --partial \ /data/ollama/models/ \ user@new-server-ip:/data/ollama/models/

40GB超のモデルファイルは転送に数時間かかることもあります。`--partial` を付けておけば途中でSSH接続が切れても、再実行すると差分だけ転送して続きから完了できます。tmuxやscreenの中で実行しておくとSSH切断のリスクをさらに下げられます。

3. 転送後のファイル数を照合する

# 旧サーバーで確認 $ find /data/ollama/models/blobs -type f | wc -l 24 # 新サーバーで確認(同じ数であること) $ find /data/ollama/models/blobs -type f | wc -l 24

ファイル数が一致しない場合はrsyncを再実行してください。チェックサムレベルで厳密に検証したい場合は `-c` オプションを追加します(処理は遅くなります)。

新サーバーでOllamaをインストールしてsystemd設定を再現する

モデルファイルの転送が完了したら、新サーバーにOllamaをインストールして起動設定を再現します。

1. Ollamaをインストールする

公式インストールスクリプトを使います。

$ curl -fsSL https://ollama.com/install.sh | sh

旧サーバーと同じバージョンを入れたい場合はリリースページから特定バージョンのバイナリを取得します。典型的なケースでは最新版で問題ありませんが、モデルファイルのフォーマット互換性が気になる場合はバージョンを合わせてください。インストール直後はsystemdサービスが自動起動しますが、次のステップでoverride.confを設定するために一度停止します。

$ sudo systemctl stop ollama

2. systemd override.confを再現する

旧サーバーで確認した環境変数をoverride.confに書き込みます。

$ sudo systemctl edit ollama

エディタが開いたら旧サーバーのoverride.confと同じ内容を記入して保存します。

[Service] Environment="OLLAMA_HOST=0.0.0.0:11434" Environment="OLLAMA_MODELS=/data/ollama/models" Environment="OLLAMA_NUM_PARALLEL=2"

3. 権限を設定してOllamaを起動する

rsyncで転送したファイルの所有者をollamaユーザーに設定してから起動します。

$ sudo chown -R ollama:ollama /data/ollama $ sudo systemctl daemon-reload $ sudo systemctl enable ollama $ sudo systemctl start ollama $ sudo systemctl status ollama Active: active (running) since Sun 2026-11-01 10:00:00 JST; 2s ago

`Active: active (running)` が表示されれば起動成功です。

動作確認とAPIの疎通テスト

起動しただけでは転送が完全かどうかわかりません。ollama listとAPIリクエストで実際にモデルが使えることを確認します。

1. モデル一覧を確認する

$ ollama list NAME ID SIZE MODIFIED llama3.3:70b-instruct-q4_0 abc123def456 41.8 GB ... gemma3:27b-instruct-q4_K_M def456abc123 17.1 GB ... mistral:7b-instruct-q8_0 789abc012def 7.7 GB ...

旧サーバーで確認したモデル一覧と同じモデルが表示されれば転送成功です。1本でも欠けていれば、そのモデルの blobs/ と manifests/ が転送漏れしている可能性があります。

2. APIへの疎通確認とレスポンス速度の比較

$ curl http://localhost:11434/api/tags {"models":[{"name":"llama3.3:70b-instruct-q4_0",...},...]} $ curl http://localhost:11434/api/generate \ -H "Content-Type: application/json" \ -d '{"model":"llama3.3:70b-instruct-q4_0","prompt":"Linuxとは","stream":false}' \ -s | python3 -c "import sys,json; d=json.load(sys.stdin); print('eval_duration:', d['eval_duration']//1000000, 'ms')" eval_duration: 980 ms

新サーバーのほうがスペックが上であれば応答速度が改善します。社内システムへOllamaを組み込んでいる場合は、接続先をDNSまたはNginx upstreamで切り替える手順も計画に含めてください。

情シス視点でのローカルLLM導入判断については社内でChatGPTが使えないときの代替手段も参考になります。

よくあるトラブルと対処法

ollama listにモデルが表示されない
OLLAMA_MODELSのパスが旧サーバーと新サーバーで異なっている可能性があります。

# 新サーバーのOllamaが参照しているパスを確認 $ sudo systemctl show ollama | grep OLLAMA_MODELS Environment=OLLAMA_MODELS=/data/ollama/models # 実際にファイルがあるか $ ls /data/ollama/models/blobs/ | head -3 sha256-0a0bebe6... sha256-1f29842d... sha256-c1864a5e...

パスが食い違っていればoverride.confを修正して `sudo systemctl daemon-reload && sudo systemctl restart ollama` を実行します。

rsync転送後に一部モデルが壊れている
大容量ファイルの転送では稀にビット化けが起きます。`--checksum` オプション付きで再度rsyncを実行してください。差分のみ再転送されます。

$ rsync -avz --checksum --progress \ /data/ollama/models/ \ user@new-server-ip:/data/ollama/models/

ollamaサービスが起動しない(permission denied)
ollamaユーザーがモデルディレクトリの所有者になっていない場合に発生します。

$ journalctl -u ollama -n 20 --no-pager | grep -i "permission\|denied\|error" ...permission denied: /data/ollama/models/blobs... $ sudo chown -R ollama:ollama /data/ollama $ sudo systemctl restart ollama

新サーバーのGPUをOllamaが認識しない
CUDAドライバーやROCmのインストールが必要なケースです。GPUのセットアップがまだの場合は、Ollamaのインストール前にNVIDIAまたはAMDのドライバーを先に導入してください。`ollama run llama3.3:70b-instruct-q4_0` 実行時に `GPU 0: NVIDIA` 等の表示が出ればGPUが有効になっています。

移行後に旧サーバーとAPIの挙動が微妙に違う
override.confに設定した `OLLAMA_NUM_PARALLEL` や `OLLAMA_KEEP_ALIVE` 等のパラメーターが旧サーバーと異なっている可能性があります。`systemctl cat ollama` の出力を旧サーバーと照合してください。

まとめ

OllamaをLinuxサーバーごと移行する手順を解説しました。
工程主なコマンドポイント
環境情報の収集 systemctl cat ollama / ollama list バージョン・OLLAMA_MODELS・override.confを記録
モデル容量確認 du -sh /data/ollama/models/ 転送サイズを把握してから作業開始する
rsync転送 rsync -avz --progress --partial 40GB超でも中断再開できる。tmux推奨
Ollamaインストール curl -fsSL https://ollama.com/install.sh | sh インストール直後に一度停止してからoverride.confを設定する
systemd再設定 systemctl edit ollama OLLAMA_MODELS・OLLAMA_HOSTを旧サーバーと同じ値に再現する
権限設定と起動 chown -R ollama:ollama / systemctl start ollama 所有者をollamaユーザーに揃えてから起動する
疎通テスト curl http://localhost:11434/api/tags 旧サーバーと同じモデルが返るか確認する

移行後すぐに旧サーバーを削除せず、少なくとも1週間は並走させることを推奨します。本番トラフィックを新サーバーに切り替えて問題が起きなければ旧サーバーを廃棄してください。接続先の切り替えにはNginxのupstream変更またはDNSの書き換えが使えます。20年以上のLinux運用経験から言っても、移行作業でいちばんリスクが高いのは「移行直後の早まった旧環境削除」です。並走確認は必ず実施してください。

ローカルLLMの構築から移行・運用まで実機ハンズオンで習得する

Ollamaのインストール・systemd設定・rsync移行など、記事で解説した手順は実際のLinuxサーバーで手を動かしながら学ぶと定着が早くなります。実機GPU環境で手を動かしながら習得したい方向けに、「ローカルAIマスターセミナー」を開催しています。
少人数(最大8名)ZOOMハンズオン形式で実施しています。

>> ローカルAIマスターセミナーの詳細を確認する
ローカルLLMの構築・運用に関する関連記事もあわせて参考にしてください。

・Ubuntu ServerでローカルLLMを構築する方法|Ollamaで機密データを外に出さず業務AIを動かす完全ガイド
・社内でChatGPTが使えないときの代替手段|機密データを守るローカルLLMという選択肢
・ローカルLLMのモデルを比較する方法|Llama3.3・Mistral・Gemma・Phi-4をUbuntuで使い分けるポイント

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録

運営

リナックスマスター.JP(代表 宮崎智広)

株式会社イーネットマーキュリーが運営するLinux教育サイトです。代表の宮崎智広は現役のLinuxサーバー管理者として20年以上の実務経験を持ち、累計3,100名以上のエンジニアを指導してきました。実践型のLinuxセミナーや無料マニュアルの配布を通じてLinux人材の育成に取り組んでいます。