Storage

The Storage section of a server (/servers/:id/storage) answers “what’s filling this disk, and what can I safely delete?” It shows real df mounts, a breakdown of usage by category, a drill-in tree of the largest paths, and a safe one-click cleanup. It’s available on all plans.

The disk picture is a heavy scan, so the page loads instantly from a cached snapshot and refreshes in the background — you never wait on a live du.

Reclaim space, step by step

1. Scroll to Reclaim space. MZPanel measures each cleanup target with a read-only dry run and shows how much each one would free (Package manager cache, System & rotated logs, Temporary files, Orphaned packages & old kernels, Nginx cache, Expired local backups).
2. Tick the targets you want to clean — nothing is pre-selected, so you opt into exactly what runs. The running total updates as you tick.
3. Click Clean now. The selected targets are cleaned on the box and the panel reports Reclaimed , then re-measures so the numbers reflect the new state.

Expired backups is opt-in for a reason

Expired local backups deletes local backup archives older than 14 days — it’s flagged caution and never pre-selected. Everything else (caches, logs, temp files, apt cruft) regenerates on demand and is safe to reclaim any time.

What else you can do

• Mounts — every real block device (/dev/*) with used / total, percent used (amber ≥ 80%, red ≥ 90%) and free space. tmpfs/overlay/squashfs mounts are filtered out.
• Rescan — force a fresh disk scan now. The button shows Scanning… and the header reads “scanned ago”; when the fresh result lands the numbers update in place.
• Usage by category — a stacked bar plus legend: Sites, Databases, Docker, Logs, Backups and System, each with its size.
• Largest paths — a tree seeded from a real du scan. Click any folder to drill in; expanding a node fetches its immediate children live, so you can walk arbitrarily deep, one cheap step at a time. Directories under 50 MB are omitted.
• Refresh (in Reclaim space) — re-measure reclaimable sizes without cleaning.

How it works

The section is cache-first. The disk snapshot — mounts, composition and the largest-paths seed — is one heavy scan that MZPanel does not run on every visit:

• The page reads the last snapshot from the control-plane inventory cache instantly, tagged with when it was scanned. If that snapshot is older than ~10 minutes when you open the page, MZPanel kicks a silent background rescan; the cached numbers stay on screen until the fresh one arrives. The agent’s own scheduler also refreshes it roughly every 30 minutes.
• Rescan dispatches a storage.usage job to the agent, which runs a single depth-3 du -x traversal of / (feeding both the category composition and the largest list) plus a df for mounts and a few targeted dus. The result is pushed back and the cache updates.
• Drill-in dispatches storage.du for the clicked path — a one-level du -x --max-depth=1 — so it stays cheap and only runs on demand.
• Reclaim dispatches storage.clean. A dry run only measures (find/du, no changes); Clean now re-runs it with apply, which shells out to the standard safe tools per target (apt-get clean, journalctl --vacuum-time=7d
  • delete rotated logs, delete old /tmp files, apt-get autoremove --purge, clear the Nginx cache + reload, delete 14-day-old backup archives).

Action	Job	Agent runs
Load / Rescan	storage.usage	df + depth-3 du -x /
Drill into a path	storage.du	du -x --max-depth=1 <path>
Measure / clean	storage.clean	du/find (measure), then the safe cleanup per target on apply

Everything is real agent data — the agent shells out to public tools only, never to a stored state file.

CLI & automation

Every action maps to an mz storage command on the box — the same engine the dashboard drives. SSH in and run them, or let an on-box AI (ClaudeCode) run them:

mz storage usage --json                                   # mounts + composition + largest paths
mz storage du --path /var/www --json                      # one level down, largest first
mz storage clean --targets apt,logs,tmp --dry-run --json  # measure only, changes nothing
mz storage clean --targets apt,logs --apply --json        # perform the cleanup

Valid --targets are apt, logs, tmp, orphans, caches, backups (comma-separated). Always pass --dry-run first to see the numbers, and add --json for machine output. See The mz CLI and the command catalog.

Gotchas & troubleshooting

• Numbers drift between scans — that’s expected. du sizes are live, so a rescan can show slightly different figures. The shape (which paths are big) is the useful signal, not the last decimal.
• A stale snapshot is normal on first open. The header says “scanned X ago” and a background rescan runs if it’s over ~10 minutes old; the on-screen numbers are the cache until the fresh scan lands. Hit Rescan to force it.
• Offline servers show the last-known cache. Mounts, composition and the largest tree still render from cache when the agent is offline, but Rescan, drill-in and Reclaim space need the agent online — Reclaim is replaced by an “agent offline” note.
• The scan is depth-limited and stays on the root fs. The du traversal is -x (root filesystem only) at depth 3, with a 90-second timeout; separately mounted volumes are measured with their own du -sx. A very deep or huge tree that times out simply contributes 0 rather than blocking the page.
• The live disk % gauge and alert rules live elsewhere. This page is the breakdown + cleanup; the percentage trend over time and threshold alerts are on Monitoring.
• Cleanup is safe but real. Apply actually deletes — caches and logs regenerate, but Expired local backups permanently removes archives older than 14 days. It’s opt-in and flagged; leave it unticked unless you mean it.

Related

• Monitoring — the live disk % gauge, metrics and alert rules.
• Cron jobs — scheduled tasks on the box.
• The mz CLI — driving the box from the command line.