How do you back up and restore local AI model files?
. Sources checked November 3, 2026.
Back up the whole local model store, with its manifests and blobs, plus a list of installed models, then test the restore on a clean machine before you need it. A local model is not a single file you can copy by name alone. In Ollama's layout, a model tag points to a manifest, and that manifest points to several content-addressed blobs for weights, configuration, templates, and other layers. Copying only the manifest, or only one large blob, does not preserve the model.
What to include in a backup
Include the entire models directory for the runtime you use, not just the model you use most. For Ollama, that directory contains manifests and blobs together, and a restore that is missing any blob a manifest references will fail when the model is loaded, even if the model appears in a list. Include the runtime version, the model inventory, and any custom Modelfiles or configuration that created a custom model, because a custom model that was created from a local file cannot be re-downloaded from a registry.
Record the inventory before you copy anything. Run the runtime's list command and save the output to a text file in the backup, with the date and the runtime version. That inventory is how you verify the restore: the restored machine should show the same tags, and each tag should load and answer a test prompt, not just appear in the list.
Also back up the configuration that tells the runtime where the models live. If the service uses a custom models path, the restore must either use the same path or set the same variable on the restored machine. A backup restored to a different path, without updating the service configuration, will look empty to the service even though the files are present on disk.
How to copy the store safely
Stop the model service before copying, so no file is being written while it is copied. Copy the whole directory to external storage or to another machine, and keep the copy separate from the live store. Do not move the live store and call the move a backup; a backup is a second copy that remains after the original is gone.
After the copy, create a hash inventory of the backup files and store that inventory separately from the backup itself. A hash inventory does not prove the original model was trustworthy, but it does prove whether the restored files match the backup. If a later restore fails, the hash inventory tells you whether the backup itself changed or whether the restore process changed the files.
For a selective backup, copy the manifest for the chosen tag and every blob that manifest references, and keep the directory structure the runtime expects. That selective copy is harder to get right than a whole-directory copy, because a missing blob is not obvious until the model is loaded. Prefer the whole-directory copy unless storage forces a selective one, and test a selective restore the same way you test a whole-directory restore.
How to restore and test
On the restored machine, stop the service, place the models directory at the path the service uses, restore the configuration, and start the service. Then run the list command and compare it to the saved inventory. Then run each restored model with a short, controlled prompt and confirm it answers without downloading anything. The decisive test is a restore on a clean target while network egress is denied: if the model loads and answers without a pull, the backup has passed a recovery test.
If a model appears in the list but fails to load, check the manifest and blob paths first, then check file permissions and the service account. A service that runs as a different user may not be able to read files copied by a personal account, and a service that uses a different models path will not see files placed in a personal home directory.
For custom models, also restore the Modelfile and any local files it referenced. Re-creating a custom model from its Modelfile is a fallback when the blob copy fails, but it requires the original model file to still exist. Keep the Modelfile and the original file together in the backup, so the fallback is available.
What a backup does not prove
A backup does not prove that a model was correctly licensed, that its weights are the version you intended, or that it will run on a different operating system without adjustment. A store copied between operating systems may need path or filename adjustments, and a future runtime version may not read an older store in exactly the same way. Test the restore on the same kind of machine and runtime version you will actually use, and re-test after a runtime upgrade.
A backup also does not protect against a corrupted source. If the live store was already missing a blob, copying it preserves the corruption. That is why the restore test, with a real prompt and no network, matters more than the copy itself. A backup that has never been restored is a hope, not a recovery plan.
Finally, keep more than one backup generation. A backup made after a bad model update will overwrite a good backup if only one generation is kept. Keep at least two generations, with dates in the folder names, so a bad update does not destroy the last good copy.
Frequently asked questions
What is the safest Ollama backup?
Copy the whole models directory, with manifests and blobs, plus the model inventory and runtime version, and test the restore with network egress denied.
Why does a model appear in the list but fail to load?
Because the list shows manifests, not blobs. A missing blob, wrong path, or permission problem can leave a tag listed but unloadable.
Should you back up custom models differently?
Yes, also keep the Modelfile and any local files it referenced, because a custom model cannot always be re-downloaded from a registry.
Sources
This page is general information, not legal advice. Check the linked official source for the rule that applies to a specific home.
Adults only (18+). Private uncensored AI · Terms · Privacy · All guides