My backup weighed 945 GB. My application code was not in it at all

The backup had been running daily since May. Green status, 41 copies in history, not a single error. It looked healthy.

I opened it not because something broke, but because I was running out of disk space. While I was there I saw that the backup weighed 945 GB against a 1.15 TB limit. The disk it was copying had 537 GB in use at the time.

The copy was fatter than the thing it was copying. That was the first signal.

What had actually happened

I checked what was taking up space in my home directory:

113 GB  Ollama models
 55 GB  LM Studio models
 38 GB  image generator models
 18 GB  ComfyUI models
 19 GB  iOS simulators

More than 220 GB of language and image models. Files that download with a single command and that have no value in a backup at all — after a failure I would pull them from the internet faster than I would restore them from a network drive.

Then I checked what was excluded from the backup. The answer: essentially just the system cache directory. Everything else went into the copy every single day.

The cause

I keep my projects on a separate external disk. I checked its status:

[Excluded]  /Volumes/<project_disk>

Excluded. Not by mistake — the system skips external disks by default, and I had never changed that.

I checked what this meant for the three applications I am working on:

Project	Remote repository	Uncommitted
A	yes	0 files
B	none	13 files
C	none	20 files

Projects B and C existed in one copy, on one disk. In project C, the entire application engine sat outside git — models, controllers, views, tests. The single commit was called "Initial Commit" and was six weeks old.

I never designed this backup. It accreted. I turned the backup on, pointed it at a network drive, clicked "next" — and then spent four months installing tools, each of which laid down tens of gigabytes. The backup dutifully took all of it, because nobody had told it not to.

What I did not do

The simplest way out was to raise the limit. There were 2.4 TB left on the network drive, so one field in the settings would have solved "the backup does not fit" in fifteen seconds.

I did not do it, because that was not the problem. The backup was not too large — it was full of the wrong data. Raising the limit would have made the symptom disappear and left the cause in place: the code still outside the copy, the models still inside it, and the same conversation in six months at bigger numbers.

The repair

Code first, because that was the only irreversible risk. I committed the pending changes, created private repositories for B and C, and pushed. Then I removed the project disk from the exclusions — and with it, twenty-one other projects that have no repositories came into the backup as well.

Then the exclusions. Seventeen paths, roughly 286 GB: models, package manager caches, simulators, container images, debug symbols.

Here I hit something I had not anticipated: an exclusion does not work retroactively. It says "stop copying this from now on", not "delete what you already copied". The models were sitting in the May, June and July copies and would have stayed there for months.

Since in four months I had not once reached for an older version of a file, and the backup was meant to protect me against hardware failure rather than against my own mistake from a quarter ago, I set the old history aside as an archive and built the copy from scratch.

The numbers

	Before	After
Backup size	945 GB	157 GB
Limit used	82%	16%
Code with no safety net	2 projects	0

A sixfold reduction on the same data. The full copy from scratch took thirty minutes.

Afterwards I opened the finished backup and counted the source files in it: 127, 44 and 44. That matched the disk, once I subtracted the files that are produced by compilation.

What follows beyond my disk

"Does it run" and "does it protect" are two different questions. My backup did not report a single error in four months, and for that entire time it was not protecting my code. A green status answers whether the job executed, not whether the right things are inside it.

Default settings have an opinion about your data. External disks are outside the backup by default. That is a reasonable assumption on the vendor's part — and the wrong one in every setup where the external disk is where the work lives.

A backup you did not design will design itself. Without a decision about what belongs inside, the copy fills up with everything you installed last quarter. Fifteen minutes spent on an exclusion list is worth more than any further increase of the limit.

---

The numbers come from a diagnosis and rebuild carried out on 16 August 2026. Backup sizes were read from the backup system's own configuration before the change and after the first full copy under the new one.