Бэкап моделей Ollama и перенос на другой сервер

MAATRIX

Модель на 30-40 ГБ качается часами, и если сервер надо переехать, менять тариф или просто продублировать окружение для теста, повторное скачивание — это потерянный трафик и время простоя. На деле файлы моделей Ollama — это обычные файлы на диске, которые прекрасно копируются штатными rsync или scp. Разберём, где они лежат, что из них можно переносить, а что нужно пересобрать, и как убедиться, что на новом сервере всё действительно работает.

Где физически хранятся файлы моделей

Ollama хранит модели не одним файлом, а деревом из двух частей: манифесты (метаданные) и blobs (сами веса, слои GGUF). При установке через официальный скрипт (curl -fsSL https://ollama.com/install.sh | sh) сервис работает под системным пользователем ollama, и данные лежат в:

/usr/share/ollama/.ollama/models/
├── blobs/
│   ├── sha256-2a1e...  (файлы весов, по одному на слой)
│   └── sha256-8f3c...
└── manifests/
    └── registry.ollama.ai/
        └── library/
            └── llama3.1/
                └── 8b   (текстовый файл-манифест с ссылками на blobs)

Если Ollama ставили вручную под обычным пользователем, каталог будет ~/.ollama/models. Проверить фактический путь на любом сервере можно так:

sudo systemctl show ollama -p Environment   # ищем OLLAMA_MODELS, если задан явно
sudo du -sh /usr/share/ollama/.ollama/models 2>/dev/null
du -sh ~/.ollama/models 2>/dev/null

Ключевая деталь: имена файлов в blobs/ — это их SHA-256 хеш содержимого. Одна и та же модель (тот же слой весов) у разных моделей на диске хранится один раз — Ollama дедуплицирует блоки автоматически. Это удобно и для бэкапа: копируете весь каталог models/ целиком, а не разбираетесь, какой файл к какой модели относится.

Что переносится вместе с моделью, а что — нет

Перенос каталога models/ целиком решает 90% задачи, но есть нюансы:

• blobs и manifests — переносятся один в один, это и есть модель. После копирования ollama list на новом сервере покажет ровно то же, что было на старом.
• Modelfile кастомных моделей — если вы делали ollama create mymodel -f Modelfile (свой системный промпт, параметры temperature, LoRA-адаптер), сам текстовый Modelfile нигде не хранится отдельно — он "разворачивается" в манифест и blobs при создании. Модель скопируется и будет работать, но у вас не останется читаемого исходника, если понадобится его снова редактировать. Экспортируйте его отдельно (ниже, в отдельном разделе).
• История чатов Open WebUI или другого фронтенда — это отдельная БД (обычно SQLite или Postgres), к каталогу моделей Ollama отношения не имеет и переносится отдельно.
• Конфигурация сервиса — OLLAMA_HOST, OLLAMA_MODELS, OLLAMA_NUM_PARALLEL и другие переменные окружения задаются в systemd override (/etc/systemd/system/ollama.service.d/override.conf) и не копируются автоматически вместе с моделями — их нужно перенести или прописать заново на целевом сервере.

Способ 1: rsync — основной вариант для переноса

rsync — правильный инструмент здесь: докачивает при обрыве (-P), сжимает поток на лету, не трогает файлы, которые уже совпадают (полезно, если переносите модели не разом, а частями). Перед переносом стоит остановить сервис на источнике, чтобы Ollama не дописывала blobs во время копирования:

# на исходном сервере
sudo systemctl stop ollama

# перенос напрямую между серверами по SSH
sudo rsync -avz --progress -e ssh \
  /usr/share/ollama/.ollama/models/ \
  root@new-server:/usr/share/ollama/.ollama/models/

Флаги: -a сохраняет права и время модификации, -v — подробный вывод, -z включает сжатие (для уже сжатых GGUF-весов выигрыш небольшой, но не мешает), --progress показывает прогресс по каждому файлу — на файле в 4-5 ГБ это важно, чтобы видеть, что процесс не завис.

Если канал между серверами нестабильный (например, перенос между локациями RU и UK), добавьте --partial — тогда при обрыве недокачанный файл не удалится, и rsync продолжит с того же места при повторном запуске:

sudo rsync -avzP --partial -e ssh \
  /usr/share/ollama/.ollama/models/ \
  root@new-server:/usr/share/ollama/.ollama/models/

После переноса на целевом сервере — права. Каталог должен принадлежать пользователю, под которым работает служба Ollama:

sudo chown -R ollama:ollama /usr/share/ollama/.ollama/models
sudo systemctl start ollama

Способ 2: scp — когда rsync недоступен

Если на одном из серверов нет rsync (бывает на минимальных образах) и ставить его не хочется, scp справится с той же задачей, но без докачки и без пропуска уже совпадающих файлов — при обрыве соединения на модели в 20 ГБ придётся начинать заново:

scp -r /usr/share/ollama/.ollama/models/ root@new-server:/usr/share/ollama/.ollama/models/

Для больших моделей практичнее сначала заархивировать в tar (одним потоком меньше накладных расходов на множество мелких файлов манифестов), передать один файл, потом распаковать на месте:

# источник
sudo tar -C /usr/share/ollama/.ollama -czf /tmp/ollama-models.tar.gz models/
scp /tmp/ollama-models.tar.gz root@new-server:/tmp/

# новый сервер
sudo tar -C /usr/share/ollama/.ollama -xzf /tmp/ollama-models.tar.gz
sudo chown -R ollama:ollama /usr/share/ollama/.ollama/models
rm /tmp/ollama-models.tar.gz  # на обоих серверах, место освободить

Учтите: GGUF-веса уже сжаты квантованием, так что gzip в tar -z даст на них небольшую экономию (обычно единицы процентов) — время на упаковку не всегда окупается. Если счёт идёт на десятки гигабайт и сеть не узкое место, можно опустить -z и передавать tar без сжатия — так быстрее за счёт процессора.

Перенос кастомных Modelfile

Если хотя бы одна модель на сервере создавалась через ollama create со своим Modelfile (системный промпт, PARAMETER temperature, ADAPTER для LoRA), сохраните исходник отдельно от бинарных blobs — это единственный человекочитаемый артефакт настройки:

ollama show --modelfile mymodel > mymodel.Modelfile
scp mymodel.Modelfile root@new-server:/root/

На новом сервере, если каталог models/ уже скопирован, модель mymodel там уже будет — пересоздавать её не нужно, Modelfile нужен только как резервная копия конфигурации на случай, если понадобится изменить параметры или пересобрать модель с нуля на сервере без готовых blobs:

ollama create mymodel -f mymodel.Modelfile

Держите Modelfile рядом с остальными конфигами проекта (в git или в общем бэкапе), а не только на сервере — это тот файл, который проще всего потерять, потому что сам по себе он много места не занимает и не бросается в глаза на фоне многогигабайтных blobs.

Настройка каталога моделей на новом сервере

Если на новом сервере хочется держать модели не в стандартном месте (например, на отдельном диске с бóльшим объёмом — см. мониторинг диска на VPS), путь задаётся переменной OLLAMA_MODELS через systemd override, а не переносом в дефолтный каталог:

sudo mkdir -p /etc/systemd/system/ollama.service.d
sudo tee /etc/systemd/system/ollama.service.d/override.conf <<'EOF'
[Service]
Environment="OLLAMA_MODELS=/data/ollama-models"
EOF

sudo mkdir -p /data/ollama-models
sudo chown -R ollama:ollama /data/ollama-models

Именно в этот каталог и нужно копировать blobs/ и manifests/ вместо стандартного /usr/share/ollama/.ollama/models. После правки — обязательно:

sudo systemctl daemon-reload
sudo systemctl restart ollama

Без daemon-reload systemd не подхватит новый override, и сервис продолжит смотреть в старый путь — частая причина, когда «модели скопировали, а ollama list пустой».

Проверка, что перенос прошёл успешно

Три уровня проверки, от быстрой к полной:

1. Список моделей. ollama list на новом сервере должен показать те же имена, размеры и даты, что были на исходном.

ollama list
# NAME              ID              SIZE      MODIFIED
# llama3.1:8b       46e0c10c039e    4.9 GB    2 minutes ago

1. Целостность файлов. Сверьте контрольные суммы каталога blobs на обоих серверах — расхождение сразу укажет на повреждённый при передаче файл:

sha256sum /usr/share/ollama/.ollama/models/blobs/* | sort > /tmp/checksums.txt
# перенести файл на другой сервер и сравнить
diff /tmp/checksums-old.txt /tmp/checksums-new.txt

1. Реальный запуск. Тест на модель, а не на файлы — запустите инференс и убедитесь, что ответ приходит без ошибок и в разумное время:

ollama run llama3.1:8b "Ответь одним словом: два плюс два?"

Если модель отвечает не сразу, а с ошибкой вида Error: an unknown error was encountered while running the model, чаще всего дело либо в неверных правах на каталог (chown не выполнили), либо в несовпадении версии Ollama на двух серверах — GGUF-формат иногда меняется между релизами. Актуальный список типовых ошибок и их причин собран в статье Ollama на сервере: частые ошибки и решения.

Частые вопросы