CliDeck
PlatformLog in
Workspace

Junos Storage Preflight: Filesystems Before Maintenance

Runbooks
#storage-preflight#operational-evidence#runbooks#remote-operations#Runbooks
← Back to Blog

Short answer

Use show system storage in Junos operational mode to capture free-space information before maintenance. Review each filesystem and its mount point. One comfortable percentage does not establish that the filesystem needed for a package, log or support artifact has sufficient room.

This preflight records a starting condition. It does not delete files or certify that an upgrade will succeed.

Scope and prerequisites

The base command is documented for Junos OS and requires the view privilege. This workflow uses the common output rather than assuming identical storage layout across EX, MX, QFX, SRX and Junos OS Evolved. Record the exact model and release, including the Routing Engine, member or node whose output you captured. The research context included Junos 23.4, but platform-specific selectors require confirmation on the actual system.

Work only on owned or authorized equipment. Establish which maintenance task is proposed and which paths it will use. Package staging, extraction, rollback material and diagnostic collection can involve different locations; use the exact platform's maintenance requirements for the space decision.

Capture the complete filesystem table

From the operational prompt, run:

show version
show system storage

If more detail is required and supported, capture it separately:

show system storage detail

Keep both responses labeled. Standard output presents human-readable sizes; detailed output uses a 1024-blocks size heading. Preserve the actual column labels and units. Avoid converting an unlabeled numeric cell into bytes based on a remembered example.

The important fields are Filesystem, Size, Used, Avail, Capacity and Mounted on. Capacity expresses the used percentage. Retain every row: an overlay, temporary filesystem or separate mount may be relevant even when the main storage row looks comfortable.

Turn the table into a maintenance decision

Start with the destination path specified by the proposed procedure, then identify the applicable mount from the actual layout. If that mapping is unclear, leave it unresolved and ask the maintenance owner to identify it before staging files.

Compare available space with that procedure's requirements, including temporary work and retained recovery material. Do not invent a universal percentage threshold. A large filesystem can have a high utilization percentage yet adequate space for one task; a small filesystem can have a lower percentage yet inadequate space for another.

Record a decision worksheet:

Device / exact release:
Captured engine, member or node:
Proposed task / destination path:
Applicable filesystem / mount point:
Reported available space and units:
Task space requirement and where it came from:
Unresolved scope or unit questions:
Decision owner / next check:

When comparing later captures, retain timestamps and matching scope. A changed row is evidence of a changed reported condition, not automatically proof of a leak or failed cleanup.

Platform and failure exceptions

Virtual Chassis and multi-engine systems need an explicit scope decision. The available selectors vary by platform. Junos OS Evolved offers node selection; other families have different options. Use operational command help and exact-model documentation rather than treating one member selector as portable.

Permission errors, missing output or an unavailable command leave this preflight incomplete. Preserve the error and escalate access through the normal process. Do not switch into a shell or run cleanup commands merely to get a satisfactory result.

If space is insufficient, retain this baseline and have the owner approve a separate cleanup or staging plan. Deleting a support file, image or rollback artifact can remove evidence or recovery options. The inspection workflow has no cleanup step.

Verification note: acceptance criteria for storage evidence

The record should contain full command output, exact platform and release, capture time, system scope, units and the mount relevant to the proposed task. It should either compare that mount with a documented task requirement or explicitly state why the decision remains open. These are criteria for a future operator's check; no device test or log observation is claimed here.

Keep the evidence in a CliDeck workspace. Pair it with the Junos alarm baseline and the uptime context check when preparing a maintenance handoff.

Who this is for

This guide is for operations teams, incident responders, network engineers, and system administrators who need to prepare, run, verify, and document operational terminal work on SSH, serial, browser terminal, and infrastructure operations workflows.

When to use this

Use this guide when:

  • Several commands or checks must be repeated safely.
  • Another engineer, customer, onsite technician, or vendor may need context.
  • The work should produce notes, logs, verification, or a clear handoff.

When not to use this

Do not use this guide when:

  • You do not own or have authorization to work on the device.
  • The device is outside your approved change, recovery, or processing scope.
  • The task may expose customer data, secrets, licenses, or credentials that you are not allowed to view or store.
  • The work requires vendor-specific approval, legal approval, or a customer-specific procedure that is not covered here.

Practical runbook format

A runbook does not need to be a complex script. For many operations, it can be a plain command list with notes, expected output, stop conditions, verification steps, and rollback instructions.

What to include

  • Purpose
  • When to use it
  • When not to use it
  • Target system or device
  • Access path
  • Read-only checks
  • Change steps
  • Expected output
  • Stop conditions
  • Rollback steps
  • Verification steps
  • Handoff notes
  • Final summary format

Workflow

  • Define the purpose, target device, access path, and approved scope.
  • Run read-only checks first and record the expected healthy state.
  • Execute commands from the runbook or handoff plan while watching for stop conditions.
  • Verify the final state with independent checks.
  • Summarize commands run, outputs reviewed, exceptions, and handoff notes.

Verification checklist

  • The target device or system is correct.
  • Read-only checks were captured before the work.
  • Stop conditions and rollback notes were available before changes.
  • Final verification checks match the expected result.
  • Notes, logs, and handoff summary are stored where the team can find them.

Common mistakes

  • Starting commands before confirming the target device and scope.
  • Skipping read-only baseline checks.
  • Copying commands without expected output, stop conditions, or rollback notes.
  • Closing the work without a final verification summary.

CliDeck workflow fit

CliDeck Workspace is designed for this kind of operational workflow. Teams can keep terminals, notes, runbooks, logs, and shared sessions in one browser workspace instead of spreading work across terminal windows, chat messages, screenshots, and separate documents.

CliDeck runbooks can be plain command lists, one command per line. Operators can send commands with one click or use auto-run behavior that waits for the prompt before sending the next line where configured.

FAQ

Does a runbook need to be code?

No. A useful runbook can be a plain list of commands, checks, notes, expected output, stop conditions, and verification steps.

Why use a browser workspace for terminal work?

A browser workspace can keep terminals, notes, runbooks, logs, and shared sessions together, which helps during incidents, handoffs, maintenance windows, and remote support.

Can shared terminal sessions be safer than screen sharing?

Yes, when implemented with clear view/type permissions. The helper can see the relevant terminal context without taking over the operator’s entire desktop.

Can CliDeck help with this workflow?

Yes. CliDeck Workspace helps organize terminals, runbooks, notes, logs, and shared sessions. Console Server Go is useful when the workflow starts at a rack-side console port.

Related guides