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 directory paths apply with Windows equivalents.

Tier 2: Offsite cloud backup

For configs and databases — the irreplaceable stuff — a cloud sync to Backblaze B2 or AWS S3 Glacier Instant Retrieval makes sense. B2 charges $0.006/GB/month for storage, which for 10 GB of configs and databases costs roughly $0.06/month. Not a budget concern.

Tools to consider:

• restic — encrypted, deduplicated backups with direct B2/S3 support. One-time setup, automatic deduplication means a ComfyUI workflow that changes 10% doesn’t re-upload 100% of the data.
• rclone — simpler, good for syncing specific directories to any cloud provider without encryption by default.

For model files (the 40–100 GB blobs): cloud backup at $0.006/GB/month means a 60 GB model library costs $0.36/month to store. That’s negligible. If your internet upload is slow, skip it on the first pass and add it once the config backup is confirmed working.

---

Restoring from backup

Restoration is where most backup setups reveal their gaps — test this before you need it.

Ollama models: Stop Ollama, copy the blobs/ and manifests/ directories back to ~/.ollama/models/, restart Ollama. Run ollama list to verify all models show up.

ComfyUI: Copy the backup directory back to your ComfyUI install path. If custom nodes were included, run python install.py inside custom_nodes/ComfyUI-Manager to reinitialize the Manager, then reinstall any nodes the backup didn’t capture.

Open WebUI: Stop the container, restore with:

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

Continue.dev: Copy config.yaml back to ~/.continue/, restart VS Code or your editor. The Continue extension picks up the new config automatically.

---

The cloud GPU angle

If your backup strategy feels unwieldy because of model sizes, there’s a structural alternative: use a cloud GPU service for the heavy inference and keep your local setup minimal.

With RunPod, you spin up a pod with Ollama or vLLM pre-loaded, pull models from HuggingFace on the pod’s fast datacenter connection (often 10+ Gbps), run inference, and tear down the pod when done. There’s nothing to back up locally because nothing lives locally. The pods are not persistent by default — treat them as ephemeral. This fits the use case covered in the RunPod vs local GPU guide: high-VRAM models (70B+) that you run infrequently enough that local storage doesn’t justify the backup overhead.

If you’re somewhere between fully local and fully cloud, the practical split is: configs and workflows always local + backed up (they’re tiny and define your workflow), model files local if you run them daily, cloud if occasional.

---

Quick-reference: file locations

Tool	Linux path	Windows path
Ollama models	~/.ollama/models/	C:\Users\<user>\.ollama\models\
ComfyUI workflows	~/ComfyUI/my_workflows/	C:\...\ComfyUI\my_workflows\
ComfyUI checkpoints	~/ComfyUI/models/checkpoints/	C:\...\ComfyUI\models\checkpoints\
Open WebUI (Docker)	/var/lib/docker/volumes/open-webui/_data	—
Open WebUI (bare)	~/.local/share/open-webui/	%APPDATA%\open-webui\
Continue.dev	~/.continue/	%USERPROFILE%\.continue\

---

Honest take

The single most common mistake is backing up model files and skipping configs. Model files are big but usually re-downloadable. Your custom ComfyUI workflow — the one with 40 nodes wired together for a specific img2img pipeline — lives in a 30 KB JSON file that took you three hours to build. webui.db with two months of conversations and carefully tuned system prompts fits in a few MB. These are the files you actually can’t replace.

Start there: a weekly docker cp of Open WebUI data and a git commit of your Continue.dev ~/.continue/ directory gets you 80% of the value in under 10 minutes of setup. Add model file backup once the critical-data layer is solid.

---

Sources

• Ollama Windows documentation — Ollama
• Ollama model storage path and migration guide — knightli.com
• Open WebUI backups tutorial — docs.openwebui.com
• ComfyUI installation folder structure — comfyui-wiki.com
• Continue.dev configuration deep dive — docs.continue.dev
• Linux backup strategies: rsync, Borg, restic (2026) — dasroot.net
• GGUF model sizes and storage requirements — enclaveai.app
• Llama 3.3 70B GGUF — bartowski on Hugging Face
• Open WebUI data persistence guide — ruianding.com
• Backblaze B2 cloud storage pricing — backblaze.com

Last updated May 17, 2026. Storage paths may change across tool versions — verify against current documentation before restoring.