The failure mode was simple: backups were technically running, but the system had stopped being sane. Archive files had become enormous, timeout behaviour was creeping in, temp files were getting stranded, and nobody would have called the setup healthy with a straight face.
The main lesson
The biggest operational lesson is also the least glamorous: never store backup outputs inside the tree being backed up.
If your backup command snapshots a directory like ~/.openclaw, and you save the resulting archives under something like ~/.openclaw/backups, you have built a recursion machine. Each new archive starts absorbing the previous archives. Sizes creep, then jump, then become ridiculous. Jobs start timing out. Temp files get marooned. Your backup policy becomes a disk-usage experiment.
Backups should not be roommates with the thing they are backing up.
What a sane split looks like
A useful local setup has two backup layers with different jobs:
- GitHub backup layer: source-ish material — docs, memory, notes, config, and lightweight workspace files.
- Archive backup layer: broader runtime and operational state — things that make sense as snapshots, not as Git history.
Problems usually start when those layers bleed into each other. If Git starts carrying temp artifacts and generated sludge, the history becomes noisy. If the archive layer starts recursively swallowing itself, the runtime turns pathological.
The housekeeping fixes
1. Move archive output outside the source tree
The clean move is to push archive outputs to a separate destination. Cloud-synced storage is perfectly fine for this if it is stable enough for your setup. The key property is separation, not glamour.
2. Add verification
A backup that merely exists is not the same as a backup that has been checked. The system should verify each new archive as part of the job, not as an afterthought when something is already on fire.
3. Add retention
Unlimited retention is usually just another way of saying “nobody has made a decision yet.” In many local setups, keeping the newest two current nightly archives is enough. It buys you one fallback without turning the backup folder into a museum.
4. Keep Git clean
If a workspace repo is intended as a memory-and-docs layer, treat it that way. tmp/, generated images, zip files, tarballs, and similar artifacts usually belong in the archive layer, not in Git history.
Paperclip specifics
For a local solo setup, embedded PostgreSQL is a sensible default. External PostgreSQL exists as an option, but it should be chosen because you need it, not because it sounds more adult.
The default Paperclip database backup policy — hourly backups with 30-day retention — is valid, but often more churn than most people need on a local machine. A quieter setting such as every 6 hours with 7-day retention is often a better fit.
The logging story is similar. File logging is fine. The missing piece is usually rotation, not mode choice. If the tool does not provide useful built-in log rotation, a small nightly copy-truncate + gzip job is a pragmatic answer. Boring wins.
What “good” looks like
A healthy local ops setup is not the one with the most knobs. It is the one where:
- backups complete in a predictable amount of time
- archive sizes make intuitive sense
- retention is explicit
- verification happens automatically
- logs do not grow without limit
- Git history reflects source and decisions, not operational spillage
Final word
Most local ops problems do not need a grand redesign. They need a few careful boundaries, a couple of retention rules, and the humility to make things boring again.