Backing Up Your Local AI Setup: Models, Configs, and Workflows (2026)

This article was originally published on runaihome.com

Drive failures are not a "if" — they're a "when." A home lab running local AI 24/7 is spinning rust or filling NAND cells around the clock. Most people spend an afternoon setting up Ollama, tuning their Continue.dev config, building out a ComfyUI workflow, and accumulating conversation history in Open WebUI — then never think about where any of that actually lives on disk.

This guide covers exactly that: what files matter, where to find them across each major tool, and a practical rsync + offsite backup strategy that takes under an hour to set up. Models get separate treatment from configs and workflows, because the backup calculus is different for each.

---

What's worth backing up vs. what isn't

Not all local AI data is equally irreplaceable. Split it into three buckets:

Back up immediately — you can't re-create these:

• ComfyUI workflows (JSON files you've built and iterated on)
• Open WebUI conversation history, system prompts, and uploaded documents
• Continue.dev config.yaml (custom model endpoints, context providers, slash commands)
• Any fine-tuned LoRA adapters or custom checkpoints you've trained
• Ollama Modelfile custom system-prompt templates

Back up if you have slow internet or large model count — re-downloading is painful but possible:

• Ollama model blobs (GGUF files pulled from the Ollama registry or HuggingFace)
• ComfyUI base checkpoint files (SDXL, Flux) downloaded from HuggingFace

Skip — re-download in 30 seconds:

• ComfyUI generated output images (unless you care about provenance)
• Ollama model manifests (regenerated on next pull)
• Docker image layers (always pull fresh)

The practical consequence: if your internet is fast (500 Mbps+), the model files are borderline. A Llama 3.3 70B Q4_K_M clocks in at roughly 40–43 GB, a Qwen2.5-Coder 7B at around 4–5 GB. With a typical US home connection, re-pulling 60 GB costs you 15–20 minutes. If you have a dozen models, that's several hours — worth backing up.

---

Where each tool stores its data

Ollama

On Linux, Ollama stores everything under ~/.ollama/:

~/.ollama/
├── models/
│   ├── blobs/      ← actual GGUF/tensor data (the large files)
│   └── manifests/  ← metadata linking model names to blobs
└── id_ed25519      ← Ollama identity key (not critical, regenerates)

On Windows, the same structure lives at C:\Users\<username>\.ollama\.

If you moved model storage via the OLLAMA_MODELS environment variable (common on Windows to avoid filling C:), check that custom path instead.

The blobs/ directory is where the size lives. A single sha256-… blob can be a 40 GB file for a large model. Manifests are kilobytes each. Back up both: blobs without manifests can't be loaded, and you can't regenerate a blob hash to re-link a manifest.

Custom model definitions created with ollama create are stored as manifests. If you wrote a Modelfile, back that file up separately — it's a plain text file you probably saved somewhere in your home directory.

ComfyUI

ComfyUI's file layout is contained within its install directory (wherever you cloned it):

ComfyUI/
├── models/
│   ├── checkpoints/   ← SDXL, Flux, SD1.5 base models
│   ├── loras/         ← LoRA adapters
│   ├── controlnet/
│   ├── vae/
│   └── clip/
├── custom_nodes/      ← installed extensions (git repos)
├── my_workflows/      ← your saved workflow JSON files
└── user/              ← per-user settings, API keys in some plugins

The irreplaceable files are my_workflows/ and any custom LoRA you trained yourself. Everything in custom_nodes/ can be reinstalled from the ComfyUI Manager, but the reinstall is tedious — include it in the backup. Checkpoint files in models/checkpoints/ can be re-downloaded from HuggingFace; whether you back them up depends on file sizes and your connection speed.

If you're using the --base-directory flag to store ComfyUI data outside the install directory, check that path too.

Open WebUI

The backup target depends on whether you're running via Docker (common) or as a bare Python install.

Docker install — the data lives in a named volume:

# Host path (Linux):
/var/lib/docker/volumes/open-webui/_data

# What's inside:
webui.db       ← SQLite: all conversations, settings, users, model configs
uploads/       ← files you've uploaded for RAG
cache/         ← embedding cache (can be regenerated, skip it)
vector_db/     ← ChromaDB for RAG search (large, but regenerable from uploads)
audit.log

The official Open WebUI docs backup tutorial recommends this one-liner:

docker cp open-webui:/app/backend/data ./open-webui-backup

That copies the entire data/ directory out of the container to your current directory. webui.db is the critical file — it's your entire chat history, system prompts, and multi-user configuration. At minimum, snapshot that SQLite file regularly.

For a running production Open WebUI with multiple family members (covered in the multi-user setup guide), losing webui.db means recreating all accounts, system prompts, and model access groups from scratch. Back it up daily.

Bare Python install — data lives at ~/.local/share/open-webui/ on Linux or %APPDATA%\open-webui\ on Windows.

Continue.dev

Continue stores its entire configuration in a single directory:

• Linux/macOS: ~/.continue/
• Windows: %USERPROFILE%\.continue\

The files worth backing up:

~/.continue/
├── config.yaml          ← your model endpoints, context providers, slash commands
├── config.json          ← older format, may coexist with config.yaml
└── prompts/             ← custom prompt files if you've written any

This directory is tiny (a few KB). If you spent time configuring a dual-model setup — say, Qwen2.5-Coder 1.5B for autocomplete and a 32B model for chat as described in the Continue.dev + Ollama tutorial — losing config.yaml means manually recreating every custom endpoint, keybind, and context provider. It takes 20 minutes you'd rather not repeat. Stick it in a git repo or include it in your regular backup.

---

A practical rsync backup strategy

For most home lab users, a two-tier setup works well: external USB drive for fast local recovery, cloud object storage for disaster recovery.

Tier 1: External drive with rsync

rsync's --link-dest flag creates hard-link-based incremental snapshots — each backup looks like a full copy, but files that haven't changed are hard links pointing to the previous backup's file. Storage overhead for unchanged files is near zero.

A working backup script for Linux:

#!/bin/bash
BACKUP_DEST="/mnt/external/ai-backups/$(date +%Y-%m-%d)"
PREV_BACKUP=$(ls -d /mnt/external/ai-backups/20* 2>/dev/null | tail -n 1)

LINK_DEST_ARG=""
if [ -n "$PREV_BACKUP" ]; then
  LINK_DEST_ARG="--link-dest=$PREV_BACKUP"
fi

# Ollama models (adjust path if OLLAMA_MODELS is set)
rsync -av --progress $LINK_DEST_ARG \
  ~/.ollama/models/ \
  "$BACKUP_DEST/ollama-models/"

# ComfyUI configs and workflows (skip large checkpoint files if short on space)
rsync -av --progress $LINK_DEST_ARG \
  --exclude='models/checkpoints/*.safetensors' \
  --exclude='models/checkpoints/*.ckpt' \
  ~/ComfyUI/ \
  "$BACKUP_DEST/comfyui/"

# Open WebUI database (stop container first for consistency)
docker stop open-webui
docker cp open-webui:/app/backend/data "$BACKUP_DEST/open-webui-data/"
docker start open-webui

# Continue.dev config
rsync -av $LINK_DEST_ARG \
  ~/.continue/ \
  "$BACKUP_DEST/continue-config/"

Schedule this with a cron job:

# Run nightly at 2 AM
0 2 * * * /home/youruser/scripts/ai-backup.sh >> /var/log/ai-backup.log 2>&1

On Windows, swap rsync for robocopy with /MIR or use a PowerShell script. The same