Back up configuration, not 500 GB of weights
On my home server the model directory dwarfs everything else on the disk, and it is also the one directory I do not lose sleep over.
Weights are a download. A 14B-class GGUF or a stack of quants for a coding model is a public artifact somebody else already hosts, and if the drive dies I pull it again and I am back where I started within an hour or two. What does not come back that easily is the small pile of files sitting next to it: system prompts, sampler configs, RAG indexes, chat templates I hand-edited to stop a model from arguing with itself, and the launch command that actually reproduces the setup. None of that lives on anyone else's server. Lose it and there is no redownload option, only reconstruction from memory, which is a worse version of the same afternoon.
This matters because the instinct under time pressure runs the other way. Storage is cheap, so people back up the folder that is easiest to point a tool at, which is usually the model cache, because it is the biggest number on the disk and backing it up feels like doing something. Meanwhile the eight-line prompt template that took a weekend of trial and error to get right sits in a scratch directory with no backup at all.
the stuff a redownload won't give you back
Sort what's on the machine into two piles before you back up anything.
- Reproducible: model weights, quantization files, anything with a public URL and a checksum you can re-verify
- Irreplaceable: system prompts, chat templates, sampler and context settings, RAG indexes built from your own documents, the launch script, and any fine-tune or LoRA you trained yourself
The first pile does not need a backup strategy, it needs a manifest: name, source, quant, and a hash so a re-fetch can be checked against what you had. The second pile is what actually breaks a rebuild when it goes missing, and it usually adds up to a few hundred kilobytes, not gigabytes.
backup/
manifest.json # model name, quant, source url, sha256
configs/ # sampler settings, system prompts
templates/ # chat templates, prompt formats
rag-index/ # your own documents, not the model
launch.sh # the exact command that starts it
weights/ # skipped, refetched on rebuild
Notice what is absent. The weights themselves get a line in the manifest and nothing else, because their whole value is that they are replaceable by definition.
rehearse the rebuild before you need it
A backup you have never restored is a belief, not a plan. Once or twice a year, wipe the model cache on purpose and rebuild from the manifest and configs alone on the hardware you would actually run this on, timing how long it takes and writing down anything the manifest failed to capture. This is also where the real failure mode shows up: a model changed upstream, a template referenced a chat format the new runtime quietly deprecated, or a sampler default shifted between point releases and nobody wrote down what you had been relying on. Checking the runtime logs after a rebuild tells you far more than trusting that the flags you passed did what you assumed they did. If two rebuilds behave differently on the same manifest, that is a gap in what you decided was worth saving, not something to write off as noise.
Loading without errors is not the same claim as working correctly, and a template that "looks fine" in one short chat is not the same claim as a template that survives a long session. Test with the same handful of prompts every time, including at least one that has burned you before, and keep the result next to the manifest so the next rebuild has something to compare against.
what I stopped backing up on purpose
I gave up preserving every fine-tuned checkpoint and every intermediate quant I ever experimented with. Most of them were small, fragile wins that would not have survived the next driver or runtime upgrade anyway, and keeping them around just meant more disk churn and a manifest nobody could audit with a straight face. What stays in scope now is deliberately narrow: the configs, the templates, the handful of eval prompts I use to sanity-check a rebuild, and the script that starts everything. That is a backup job measured in megabytes that finishes before the coffee is ready, instead of one measured in the hundreds of gigabytes a full local model cache can reach.
The tradeoff is real and I accept it on purpose: if I ever need last month's exact quant again, byte for byte, I do not have it sitting on a drive anywhere. What I have is a manifest that tells me what it was and where to get it again, and one extra download standing between me and the setup I actually rely on.