How to review Linux disk cleanup safely over SSH
Review Linux logs, caches, backups, packages, containers, and temporary data with separate evidence, inspection, cleanup, risk, and verification steps.
Direct answer
Do not start with rm. Identify what owns the data, inspect its current size and retention settings, prefer the owning service or package manager's documented cleanup operation, read the exact scope and risk, and verify afterward. Keep backups review-only unless their retention and recoverability are independently confirmed.
When this guide applies
- A scan highlights logs, caches, backups, packages, or container data.
- You need a command draft that another administrator can review.
- You want to reduce disk use without granting a GUI automatic deletion authority.
Step-by-step review
Read the classification evidence
Treat path and tool matches as hints with confidence and possible false positives, not as permission to remove data.
Run an inspection first
Measure the exact target and, where available, use a dry-run or inventory command such as docker system df -v.
Find the owning retention mechanism
Use journal retention, log rotation, package-manager cache handling, container lifecycle, or the backup system's own policy.
Review the exact draft
Check command, privileges, target, exclusions, expected effect, rollback limits, and the official source before copying anything.
Execute outside the app and verify
If an authorized operator chooses to proceed, run it in their own terminal and then re-check both the target and filesystem capacity.
Technical context
Linux paths express purpose, not disposability
FHS gives /var/log and /var/cache defined roles, while XDG defines a default user cache location. Those conventions help route investigation but do not authorize bulk deletion.
Logs need retention, not surprise removal
systemd journal and traditional log files have different management paths. Deleting an active log can conflict with rotation and may not release space while a process keeps it open.
Container storage has shared relationships
Docker distinguishes images, containers, local volumes, shared size, unique size, and reclaimable estimates. Review those relationships before any prune operation.
Backups require the highest caution
A filename or /var/backups location does not prove that a copy is expired, redundant, restorable, or outside a compliance retention period.
Category is a routing hint, not a delete rule
| Category | Useful evidence | Safer owner path |
|---|---|---|
| Logs | /var/log, journal usage, service log path | Retention, journalctl, logrotate, or service settings |
| Caches | /var/cache, XDG cache path, CACHEDIR.TAG | Application or package-manager cache command |
| Backups | Configured backup root, archive naming, catalog | Backup retention and restore verification |
| Packages | Detected APT, DNF, APK, or pacman cache | Matching package-manager cleanup |
| Containers | Docker or Podman inventory and ownership | Container runtime's scoped lifecycle command |
| Temporary data | Known temp root, age, owner, active handles | Service-specific lifecycle or a reviewed policy |
Risks and actions to avoid
Cleanup commands can be irreversible
Package, journal, container, and backup operations can remove data needed for rollback, audit, debugging, or recovery.
sudo expands impact
A privileged command can cross ownership boundaries. The app never supplies credentials or executes sudo.
Reclaim estimates are not promises
Shared layers, snapshots, sparse allocation, open handles, and filesystem metadata can make the observed free-space change differ from a displayed item size.
What the Omuuz product can—and cannot—do
What it can do
SSH Disk Visualizer can classify metadata evidence and present inspection, cleanup, and verification commands with explanations and sources for the user to copy.
What it cannot do
It cannot execute a cleanup command, provide sudo credentials, decide that a backup is expired, guarantee rollback, or promise how many bytes an action will free.
Product evidence
