by

🗂️ Why I Didn’t Use find – and started retentions

Today, I wanted to delete some old backups.

Nothing fancy. Just the regular backups I keep from my OpenWRT Wi-Fi access point.
And like everyone else, my first instinct was to reach for the shell.

🔧 The Obvious Solutions

The usual commands are well known:

Bash
find backups/ -type f -mtime +30 -delete

or:

Bash
ls -t backups/* | tail -n +21 | xargs rm --

They work.
They are short.
And that’s exactly why almost everyone uses them.

⚠️ Why I Don’t Trust Them

The problem isn’t that these commands are wrong.
The problem is that they are implicit.

After running them, it’s hard to answer even simple questions:

  • Why was this backup deleted?
  • Why was that one kept?
  • Which rule applied here?
  • Would the same thing happen tomorrow?

All the logic lives in your head – not in the system.
Once the files are gone, the reasoning is gone as well.

🧠 What Backup Tools Get Right

Backup tools like borgbackup, restic or vzdump don’t delete “old files”. They apply explicit retention policies.

Each retained backup exists for a specific, explainable reason:

  • because it represents a certain time window
  • because it is the last backup of a given period
  • because removing it would violate a defined rule

The important part is not the exact rule –
it’s that the decision is deterministic and auditable.

🌱 Why retentions Exists

I went looking for a small tool that does exactly this — but for plain files and directories.

Not a backup system.
Just a clear, deterministic retention engine.

I didn’t find one.

So I started retentions.

It doesn’t try to be clever.
It doesn’t rely on timestamps alone.

It simply answers one question:

Should this file still exist — and why?

🧭 Closing Thought

find, xargs and ls are fine tools. They’re just the wrong abstraction for irreversible deletion.

When data matters, retention should be explicit, predictable, and explainable — not a one-liner you vaguely remember writing months ago.