Backing Up Your Local AI Setup

What actually needs backing up

A local AI setup has a mix of things that are trivial to recreate and things that genuinely aren't. Getting this distinction right saves you from wasting space backing up the wrong stuff, and from losing the stuff that actually matters.

Don't bother backing up: the models themselves. They're large, and pulling them again is one command and a few minutes - re-downloading is faster than most backup-and-restore processes anyway.

Do back up:

• Your Open WebUI chat history and settings - see What Happens to Your Data for where this actually lives
• Any Modelfiles you've written for custom system prompts (see Giving Your AI Memory) - small text files, but not stored anywhere that survives a full reinstall
• The original source documents behind any RAG knowledge collections (see Talking to Your Own Documents with RAG) - the indexed copy inside Open WebUI is rebuildable from these, so the originals are what actually matter
• If you're running OpenClaw, the ~/.openclaw/workspace/ directory - the memory files it reads on every turn

Backing up Open WebUI

Your chat history lives in a Docker volume, not a folder you can just copy directly. Archive it to a plain tarball like this:

docker run --rm -v open-webui:/data -v $(pwd):/backup alpine \
  tar czf /backup/open-webui-backup.tar.gz -C /data .

This starts a temporary throwaway container that mounts your actual data volume, packs it into a compressed archive, and saves that archive to your current folder - then removes itself. Your running Open WebUI container is untouched by this.

Restoring from a backup

If you're restoring onto a fresh install, create the volume first by running Open WebUI's normal install command once (see Getting a Proper Chat Interface Running), then stop it and restore the archive into that same volume:

docker stop open-webui
docker run --rm -v open-webui:/data -v $(pwd):/backup alpine \
  tar xzf /backup/open-webui-backup.tar.gz -C /data
docker start open-webui

Your chat history and settings come back exactly as they were at backup time.

What actually goes wrong

The backup file is tiny, way smaller than expected

Double-check the volume name in the command actually matches yours - docker volume ls lists what's really there. A typo in the volume name silently archives an empty or wrong volume instead of erroring out.

The backup is sitting on the same drive as everything else

A backup that lives on the same machine, same drive, protects against almost nothing - if that drive fails, both copies are gone at once.

Copy the archive to an external drive (see our external SSD pick) or a cloud storage folder you already use for other backups.

You want to back up while actively using the setup

Running the backup command while the container is mid-write is low-risk for a quiet single-user setup, but not zero-risk - a rare bad-timing snapshot could catch the database mid-write. For anything you'd genuinely be upset to lose, stop the container for the few seconds the backup command takes, then start it again right after.

Common questions