Systems

Backups are a workflow

A copy is only one part of recovery. The rest is knowing what it contains and how to use it.

A backup becomes useful when it answers three questions: what state does this represent, what has changed since then, and how can that state be restored without losing something newer? A timestamp helps, but a short description often helps more.

Configuration files, databases, and application versions belong to the same recovery story. Copying a database while it is being written can produce an incomplete snapshot. Restoring an old configuration into a new application can introduce a different kind of failure.

A practical recovery note can stay short. Record the source, the version, the scope, and one verification step. Keep credentials out of the note, and protect the backup with the same care as the live system.

Finally, test a restore in a place where mistakes are inexpensive. The goal is not to prove that a file exists. It is to prove that the next step is understood.

Part of Field Notes, a journal about software, systems, and observations.