Automate disk cleanup only after you can explain the growth

A nearly full disk is a question, not a delete button

Unexpected storage growth creates a nasty kind of urgency. A service starts failing, an update refuses to install, or a dashboard turns red. The tempting response is to schedule the most powerful cleanup command you can find and call the problem solved.

That can turn a capacity problem into a data-loss or recovery problem. “Large” does not mean “disposable”, and “unused” in one tool does not mean “unwanted” by the person who owns the system. A stopped container may be stopped deliberately. An old image may be the quickest rollback. A log may be the only record of an intermittent fault. A directory you do not recognise may belong to the service that is still working.

The safer mental model has six parts: **ownership, growth rate, reclaimability, retention, recovery and verification**. Cleanup becomes a candidate for automation only when each part has an answer.

Start with the shape of the pressure

First establish what is running out. Byte usage and inode usage are different constraints: a filesystem can have free capacity but no room for another file. Netdata's disk-space collector, for example, exposes per-mount space and inode metrics with available, used and reserved dimensions. That makes it a useful observation example, not an endorsement or a deletion engine.

Record the same measurement at two or more times. A single reading says “83% used”; a series says “growing by roughly this much each day”. The second statement is far more useful. It distinguishes a one-off import from a repeating producer and gives you time to act. Keep private mount names and infrastructure details out of anything you share; the decision only needs a neutral label such as “application storage” or “media archive”.

Then attribute the change to an owner. Ask which service, job or person creates the data, and why. Group what you find into five buckets:

Unknown is not another word for disposable. It is a stop sign.

• **Active data:** the current state a service needs.
• **Regenerable data:** caches or build artefacts that can be recreated, with a known time and resource cost.
• **Retained history:** logs, snapshots or old outputs kept for a stated period or recovery purpose.
• **Orphaned artefacts:** data whose former owner and removal condition you can prove.
• **Unknown:** anything you cannot yet explain.

Reclaimable is a technical estimate, not permission

Docker shows the distinction clearly. `docker system df` reports daemon disk usage and an estimate of reclaimable space; its verbose view gives more detail about images, containers and volumes. That is an inventory aid. It does not know whether an operator intended to keep a stopped container or an unused image for rollback.

The companion `docker system prune` command has specific semantics. By default it removes stopped containers, networks unused by any container, dangling images and unused build cache. The broader `--all` option includes all unused images, while `--volumes` also includes anonymous volumes. The confirmation prompt describes the affected classes, and filters can narrow some candidates.

Those facts support a cautious workflow: inspect first, name every class you intend to remove, and use the narrowest action that matches it. Server Attic judgment is that a global prune command does not belong on a blind schedule. If the real problem is an unbounded build cache, automate a bounded cache policy. If it is an application retaining exports forever, fix that retention rule. Delete the cause by contract, not nearby data by coincidence.

Retention should be a policy, not a rescue command

Logs are a good worked example because systemd separates observation, emergency cleanup and ongoing policy. `journalctl --disk-usage` reports the combined usage of active and archived journal files. Vacuum operations remove old archived files; they do not simply make the total fall to an exact target because active files remain.

For the continuing policy, `journald.conf` provides size limits, free-space reservations and maximum retention settings. Its documentation also notes an important limit: journald may stop growing when another process fills the filesystem, but it does not necessarily remove existing files to restore the earlier free-space target. A retention setting bounds one producer; it is not a whole-disk guarantee.

The general pattern is durable:

1. Measure the producer's current footprint. 2. Decide why the history is kept and for how long. 3. Apply the product's own retention mechanism where one exists. 4. Verify what the mechanism can and cannot remove. 5. Recheck the trend after enough time for the policy to act.

A bounded cleanup rehearsal

Use this checklist before turning any deletion into a timer or scheduled job.

Only after repeated manual passes behave as expected should automation be considered. Give it an age or size boundary, an explicit exclusion list, a maximum amount per run, a failure signal and a record of what it removed. Prefer a supported retention option over a hand-written recursive delete. Test the command's selection separately from its deletion behaviour wherever the tool permits.

• **Capture the baseline.** Record free bytes, free inodes, the observation time and the recent growth rate.
• **Name the owner.** Map each large or fast-growing category to the service or workflow that produces it. Stop on unknowns.
• **Define reclaimability.** Write the exact reason each candidate can go: regenerated safely, past an agreed retention period, or proven orphaned.
• **Protect recovery.** Identify what would restore service if the classification is wrong. Do not count the data you are about to delete as its own recovery path.
• **Make one small manual pass.** Remove a bounded class, record what actually changed and avoid unrelated resources.
• **Verify the result.** Check capacity and inodes again, then confirm the owning service still starts, reads expected data and completes one representative operation.
• **Watch the next interval.** If growth resumes unchanged, the cleanup treated a symptom rather than its producer.

Where this advice stops

This is a home-server maintenance method, not a universal retention schedule or forensic-preservation policy. It does not decide how long business, personal or regulated records must be kept. It cannot prove that an unfamiliar file is safe to remove, and it does not make destructive commands reversible. Storage snapshots and backups may help recovery, but they need their own verified restore path.

Named tools here illustrate different signals and controls. They are not endorsements, and their exact behaviour can change by version and configuration. Read the documentation for the version you operate and test with non-essential data first.

What we would do next

Take one read-only storage report today and another tomorrow. Label the three fastest-growing categories by owner, then choose just one whose retention rule you can explain. Fix that rule manually, verify the service and measure again.

The goal is not to keep every disk permanently empty. It is to make storage growth predictable enough that cleanup becomes a narrow, reviewable policy rather than an emergency guess with a timer attached.

Sources and limits

This article synthesises the sources below into a practical explanation. It is not a security standard, legal advice, or a guarantee that guidance current at review time still applies — check the review date above against your own situation.

1. Disk space — Netdata. Documents per-mount space and inode metrics, including available, used and reserved dimensions, as useful observation signals.
2. docker system df — Docker. Shows Docker daemon disk usage and a reclaimable estimate, with a verbose view for more detailed attribution.
3. docker system prune — Docker. Defines the resource classes removed by default, the broader effect of all and volumes options, filters and the confirmation prompt.
4. journalctl manual source, v261.2 — systemd. Defines journal disk-usage reporting and explains that vacuum operations remove archived rather than active journal files.
5. journald.conf manual source, v261.2 — systemd. Documents size, free-space and retention controls for persistent and runtime journals, including their limits.

More from Server Attic

• 2026-08-26

  Local AI stays private only if the whole workflow does

  Running a model on your own machine can remove one remote data path, but prompts, tools, logs, saved outputs, backups and sharing still decide where information travels.

• 2026-08-19

  A health check is not a recovery plan

  A practical home-server guide to separating liveness, readiness and restart signals from the human decisions that make recovery safe.

• 2026-08-14

  Give your AI agent a budget

  Permissions limit what an agent may touch. A separate budget for time, steps, data and queued work limits how much it can consume before it must stop.