Can You Back Up Ollama Models For An Air-Gapped Restore Without Pulling Them Again?

August 29, 2026

Back up Ollama manifests, blobs, hashes, runtime, and configuration so an air-gapped restore works without pulling model weights again.

Yes—you can back up Ollama models and restore them to an air-gapped computer without pulling the weights again. The most reliable current method is to preserve the entire Ollama models directory, including both manifests and blobs, record the Ollama version and model inventory, verify the backup with hashes, restore it under the account that runs Ollama, and test the model while outbound internet access is blocked.

Watch The 30-Second Summary

Watch this video on YouTube

Do not assume that one very large blob, a model name, or the output of ollama show --modelfile is a complete backup. An Ollama-managed model can depend on a manifest plus several content-addressed blobs for weights, configuration, templates, parameters, licenses, and other layers. Blobs may also be shared by more than one model.

The important limitation is that Ollama still does not document a first-class per-model export and import command. A whole-directory copy is simple and defensible. A selective copy is possible only if you correctly preserve the selected manifest and every blob it references—and then prove the restore works with no network route available.

The Short Answer

Use this five-part VAULT process:

1. Version the Ollama runtime and record the installed model inventory.
2. Archive the complete active models directory, not just a visible weight file.
3. Validate every copied file with a cryptographic hash.
4. Load the backup under the correct service account, path, and permissions.
5. Test listing, inspection, and inference while public egress remains denied.

If storage permits, back up the complete directory. That captures shared blobs and avoids having to reverse-engineer which layers belong to one tag. Keep the Ollama installer or package for the approved version in the same recovery set so the destination does not need the internet to obtain a compatible runtime.

What Is Confirmed

Ollama's current FAQ lists these default model locations:

The same FAQ says OLLAMA_MODELS can point Ollama to another directory. On Linux, the ollama user must have read and write access to that location. That ownership requirement matters during restoration: files can be present and correct while the service still behaves as though the model is missing because it is reading another path or cannot access the restored directory.

Ollama's local list-models API returns a model name, size, digest, format, family, parameter size, and quantization level. The show-model API returns additional model metadata such as parameters, template, license, capabilities, and model information. Those interfaces are useful for recording and comparing an inventory before and after restoration.

Ollama also documents ollama show --modelfile. Its example shows a generated FROM line pointing to a content-addressed blob under the local models directory, along with the template and parameters used by the model. That output is valuable recovery evidence, but it is not a promise that one FROM blob represents every layer for every model type.

An Ollama project member answered a direct no-internet migration question by saying that zipping the complete ~/.ollama/models directory and moving it to the other computer was the easiest approach. The issue was closed in March 2024, but the underlying export gap remains visible in a newer request.

The July 2026 per-model offline export feature request explains why selective copies are difficult: blob filenames are hashes, one model may reference multiple blobs, and different models may share layers. The proposed ollama export or ollama copy workflow remains a request, not a documented command users can rely on today.

What Is Still Unclear

Ollama does not publish one supported backup-and-restore procedure covering every runtime version, model engine, operating system, container layout, service wrapper, custom path, and cross-platform migration.

The current documentation establishes where models are normally stored and how to inspect installed models. It does not guarantee that a model store created by any future version will be readable forever, or that a directory copied between Windows, macOS, and Linux will require no path or filename adjustments.

There is also a difference between restoring an Ollama-managed model store and importing a separately obtained model artifact. Ollama's import guide documents creating models from supported Safetensors directories, GGUF files, and adapters. That workflow is appropriate when you intentionally retain a source artifact. It is not a universal conversion or export path for every model already stored in Ollama's internal blob layout.

Finally, a matching model name does not prove complete recovery. A stale manifest can exist while one referenced blob is missing or corrupt. A command may also attempt to contact a registry when local content is incomplete. The restore must be tested under the same network restriction the destination will actually enforce.

What An Ollama Model Backup Must Preserve

A useful recovery set has four parts.

1. The Active Models Directory

First determine which directory the running Ollama service actually uses. Do not infer it only from the interactive user's home directory.

Check:

• whether OLLAMA_MODELS is configured;
• which account runs the Ollama process or service;
• the model path visible to that account;
• the manifests and blobs subdirectories;
• filesystem ownership and permissions; and
• whether a container volume or network-mounted path sits underneath the directory.

Back up the complete active directory when practical. A partial copy made from the wrong home directory can look plausible and still contain none of the production models.

2. A Model Inventory

Before the copy, record:

ollama --version
ollama list

If the local API is enabled, save the response from:

curl http://localhost:11434/api/tags

For each important model, save details with:

curl http://localhost:11434/api/show -d '{"model":"MODEL:TAG"}'
ollama show --modelfile MODEL:TAG

Store this evidence outside the directory being backed up. If the directory becomes unreadable, a manifest trapped inside the same failed backup is not useful.

The inventory should include exact tags. model:latest, model:q4_K_M, and a locally customized copy can resolve to different content even when their names look related.

3. The Compatible Runtime And Configuration

Preserve the approved Ollama installer, archive, container image, or internal package needed to rebuild the service. Record its version, platform, architecture, SHA-256, and source.

Also preserve the service configuration that controls:

• OLLAMA_MODELS;
• the service account;
• listening address;
• proxy variables;
• network policy;
• GPU or accelerator dependencies; and
• any front end that expects a particular Ollama endpoint.

The model weights are not a complete recovery plan if the destination cannot start a compatible runtime or locate the restored directory.

4. A File-Integrity Manifest

Create a SHA-256 inventory after the backup copy completes. On Windows PowerShell, one option is:

$modelRoot = 'D:\OllamaBackup\models'
Get-ChildItem -LiteralPath $modelRoot -File -Recurse |
  Sort-Object FullName |
  ForEach-Object {
    $hash = Get-FileHash -Algorithm SHA256 -LiteralPath $_.FullName
    [pscustomobject]@{
      Path = $_.FullName.Substring($modelRoot.Length).TrimStart('\')
      Length = $_.Length
      SHA256 = $hash.Hash
    }
  } | Export-Csv -NoTypeInformation -Encoding UTF8 'D:\OllamaBackup\models-sha256.csv'

On Linux or macOS, run the equivalent with an approved hashing tool and preserve paths, sizes, and digests in a separate manifest.

A hash inventory proves whether the restored files match the backup. It does not prove the original model was trustworthy, correctly licensed, or free of malicious content. Those are separate provenance questions.

How To Create The Backup Safely

Stop Writes Or Take A Consistent Snapshot

The safest copy is taken while Ollama is stopped and no process is pulling, creating, copying, or deleting models. If operational requirements prevent downtime, use a storage snapshot mechanism that provides a consistent point-in-time view.

Do not start a large ollama pull and copy the same directory simultaneously. A manifest can arrive before all referenced blobs, or a cleanup operation can remove content while the backup tool is reading it.

Copy The Complete Directory

Copy the active models directory into a versioned backup location. Preserve filesystem metadata where your tooling supports it. Avoid “move” operations; keep the source intact until restoration is proven. Snapshot or deduplicating storage can reduce repeated copies, but do not manually discard duplicate-looking hashes.

Verify The Copy Before Transfer

Compare file counts, total bytes, and SHA-256 values between the source snapshot and backup. Investigate every mismatch. Protect removable media according to the sensitivity and license terms of the weights, and use the organization's approved cross-domain process.

How To Restore Without Pulling Again

Install The Recorded Ollama Version

Use the preserved runtime package. A same-version restore reduces avoidable uncertainty. If you must upgrade during recovery, first prove the backup on the recorded version, then perform the upgrade as a separate controlled change.

Keep the air-gapped host disconnected or under an independently enforced deny-egress policy. Do not reconnect it temporarily to make a failed restore “work.” That hides missing backup content by allowing a new pull.

Restore To The Path The Service Uses

Restore the models directory to the documented default or configure OLLAMA_MODELS to the restored location. Confirm the variable is applied to the service, not merely to one interactive shell.

On Linux, assign read and write access to the documented ollama service account when using the standard installer. On Windows and macOS, confirm that the process identity can traverse the parent directory and read all manifests and blobs.

Start Ollama only after the copy and integrity verification finish.

Compare The Inventory

Run:

ollama --version
ollama list

Compare every required name, tag, size, digest, format, parameter size, and quantization level with the source inventory. Then use ollama show or /api/show for the most important models.

The digest returned by /api/tags is a useful comparison field for the model manifest. It is not a substitute for hashing every backup file.

Run A Real Inference Test With Egress Blocked

For each critical model, submit a short deterministic test prompt. Confirm that Ollama loads the model and returns a response while the firewall, gateway, or physical network boundary prevents public access.

Watch the logs during the test. A successful local response proves the manifest and required blobs are usable. A failed registry connection suggests incomplete content or a tag mismatch. Test through the actual application too; a local API can work while a front end still uses a cloud model, remote embeddings, or web search.

Whole-Directory Backup Versus Selective Per-Model Backup

For most individuals and small teams, full-directory backup is the least surprising choice. A selective enterprise pipeline should parse manifests rather than guess from file sizes. Do not delete blobs merely because their hash filenames are not human-readable.

Common Restore Failures

Prefer a same-version, same-platform recovery first. Treat cross-platform migration or an upgrade as a separate test so the source of failure remains clear.

What This Means For Privacy

Backing up a local model can help preserve a private, repeatable inference environment. It does not automatically make the complete AI workflow private.

A local Ollama process can still be paired with:

• a browser UI that sends telemetry;
• remote web search;
• cloud embeddings or reranking;
• external speech or image services;
• plug-ins and agents with network access;
• remote logging or crash reporting; or
• a missing tag that triggers a pull attempt.

Use the restore test to verify both model availability and network behavior. The relevant question is not only “Did the model load?” but also “Which components attempted to communicate, and what enforced the denial?”

The local-only verification guide explains how to test that boundary. The offline update guide covers runtime packages. For the larger product choice, see private AI chat versus local AI.

What This Means For OpenVeil

OpenVeil is a hosted, privacy-focused AI workspace for adults. Normal chat history is stored in the browser rather than as a normal server-side chat-history record. Active prompts, selected local history, uploads, searches, and media still require processing by OpenVeil and necessary providers.

OpenVeil is not fully offline, an Ollama host, a model-backup tool, or a substitute for an air-gapped system. It does not verify model hashes, restore local runtimes, block network egress, or protect a compromised computer.

The tradeoff is operational. If policy requires model inference to remain on controlled hardware with no public network path, use and verify a local or air-gapped deployment. If you want a narrower hosted conversation without maintaining model weights and backup media, you can try OpenVeil within its documented boundaries. Review the OpenVeil privacy policy before sending sensitive material, and never submit data you are not authorized to share with a hosted service.

Frequently Asked Questions

Can I Copy My Ollama Models To Another Computer?

Yes. The simplest current approach is to copy the complete active models directory and restore it under a compatible Ollama runtime. Preserve the directory structure, permissions, service configuration, and exact model tags, then test with network egress blocked.

Does Ollama Have An Export Command?

Ollama does not currently document a first-class per-model export/import command. The project has open feature requests for that workflow. Do not run commands from a feature proposal as though they already exist in a released CLI.

Is The Largest Blob The Whole Model?

Not necessarily. The largest blob may contain the primary weights, but the model manifest can reference other layers. Preserve the manifest and every referenced blob, or copy the complete models directory.

Can I Use ollama show --modelfile As My Backup?

Use it as inventory evidence, not as the only backup. It captures a useful blueprint and may point at a major model blob, but it does not establish that every layer required by every engine or model type is included.

How Do I Know The Restore Did Not Download Anything?

Enforce the network boundary independently, monitor Ollama logs and outbound traffic, and run the model. A successful inference with public egress denied shows that the required local content was available. Merely seeing the model in ollama list is not enough.

Should I Back Up Ollama Chat History Too?

The model directory is not a universal backup for its front end. Back up the UI's conversations, databases, settings, retrieval indexes, and uploads separately.

Can I Restore To A Newer Ollama Version?

It may work, but a recovery plan should preserve and first test the recorded version. Treat an upgrade as a separate change so you can distinguish backup failure from runtime compatibility failure.

Does A Local Model Backup Contain My Prompts?

The models directory is primarily model content and manifests. A connected UI may store prompts elsewhere; inspect each component separately.

Bottom Line

A complete Ollama model backup is the active models directory plus inventory, hashes, runtime, configuration, permissions, and a tested restore—not one blob copied to a USB drive.

Whole-directory backup is currently the safest general method because Ollama models use manifests and content-addressed blobs that may be shared across tags. Selective copies can save space, but the project still lacks a documented first-class per-model export command.

Restore under the right service account, compare model digests and metadata, and run a real inference test while outbound internet access is denied. If that test fails and Ollama tries to pull, fix the backup; do not reconnect the air-gapped host and quietly replace recovery with a new download.

NIST's June 2026 backup quick-start guidance emphasizes creating backups regularly, integrating them with change management, and testing them during recovery exercises. CISA likewise recommends offline backups with regular integrity and restoration testing. The same principle applies here: a model archive becomes a recovery asset only after you prove it can restore the service you need.

Sources

• Ollama FAQ: model locations, OLLAMA_MODELS, and Linux permissions
• Ollama API: list installed models and digests
• Ollama API: show model details
• Ollama Modelfile reference
• Ollama model-import guide for GGUF and Safetensors
• Ollama issue #2947: whole-directory no-internet migration guidance
• Ollama issue #17115: current per-model offline export request
• NIST SP 1339: Operational Technology Backup Quick Start Guide
• CISA StopRansomware Guide: offline backup and restoration testing