A paper notebook beside infrastructure looks a little sentimental until the infrastructure is the reason the digital notes aren't available.
I don't use it as a second documentation system. It doesn't contain passwords, full configuration, or a lovingly hand-copied inventory that will be obsolete before the ink dries. The notebook has a narrower job: preserve the few coordinates and observations I need when the normal path into the system is unavailable or when I’m standing there with one hand on a cable.
That physical boundary is the useful part. It keeps a small recovery aid outside the power, network, login, and application dependencies I may be trying to repair.
The index, not the encyclopedia
The first pages are an index to durable documentation. They name broad functions, physical labels, and where the maintained instructions live once ordinary access returns. A short entry might identify which device carries the network edge role or which marked cable feeds a particular shelf. It won't reproduce every setting.
Duplication creates drift, so I’m deliberately stingy. If a value can change during routine configuration, paper is usually the wrong authority. The notebook should help me reach the authoritative record, not compete with it.
The exception is bootstrap information. Some facts are needed before I can reach anything else: the order for bringing core network functions back, how to identify the management connection, and which local console path remains available without name resolution. Even then, I record roles and physical markers rather than sensitive identifiers. Credentials belong in their managed recovery process, never in a notebook sitting near equipment.
The change ledger
The middle of the notebook is a rough ledger for hands-on work. Before moving a connection or replacing a component, I write the time, the physical label, the old position, and the intended new position. Afterward I note the result. The handwriting is not elegant. Elegance would be suspicious under these conditions.
This solves a mechanical problem that terminal history can't. A shell can tell me which command ran. It can't tell me that I moved the cable with the blue marker from one port to another, noticed an unexpected light pattern, and put it back. A photo helps, but photos accumulate quickly and aren't always obvious in sequence. Two lines on paper preserve before and after without needing another device in my hand.
The ledger also interrupts improvisation. When a change doesn't help, I can reverse the exact physical action before trying the next theory. Without a written sequence, several small experiments blur together. Soon I’m debugging the original fault plus my own topology edits, a bundle nobody ordered.
The independent fault domain
Digital runbooks are better for almost everything. They’re searchable, reviewable, linkable, and easy to update. Their weakness is that they usually share at least one dependency with the system: local storage, network access, identity, power, or the device used to read them.
Paper shares very little. It needs light and readable handwriting. That’s a satisfyingly short dependency list.
The notebook is especially useful during partial failure. If name resolution is unavailable but the local network still passes traffic, I need the recovery sequence that gets me to the right console. If the management interface is unreachable, I need enough physical mapping to inspect the correct connection. The notebook bridges the gap. Once access returns, the real runbook takes over.
This only works if the paper copy stays small enough to maintain. I review bootstrap pages whenever I change the corresponding physical or recovery path. A quick correction is easy. Auditing a handwritten manual would become a chore, which means it wouldn't happen, which means the manual would become fiction with excellent battery life.
What never goes on the page
The teardown matters as much for its exclusions. No passwords. No recovery codes. No private addresses copied for convenience. No complete inventory that would expose more than the recovery task requires. No details about users or remote systems.
I also avoid speculative diagrams. A physical map records what I can label and verify. If I’m unsure where a connection leads, I mark it unknown until I trace it. Drawing a confident line because it probably reaches the switch is how paper becomes another source of false certainty.
Completed incident notes don't live there forever, either. After the system is stable, I transfer any durable lesson into maintained documentation and reduce the notebook entry to a reference. The book is a working cache, not an archive. Old pages can remain as a local change history, but they shouldn't be the only place a correction exists.
There’s a mild absurdity in using one of the oldest information technologies beside machines that can answer requests in milliseconds. I’m comfortable with it. The notebook does one job the rack can't do for itself: remain readable while the rack and I are still negotiating how to speak again.
When I reach for it, I want three things quickly: where to begin, what I just changed, and how to undo the physical part. If the notebook grows beyond that, I trim it. Its value comes from being independent, current, and almost boring enough to ignore.