Operations and recovery
Observe server health, investigate failures in a reliable order, control logs, and restore from tested backups.
Operations is the practice of turning uncertain symptoms into evidence, containing impact, and leaving the system easier to understand next time.
The first five minutes
Then narrow to the affected service:
Before you restart anything
Record the time, commands, results, and changes. Read the error first. Clearing logs or repeatedly restarting a service can remove the information you need to find the cause.
Follow each signal
| Signal | Ask next |
|---|---|
| CPU saturated | Which process? Is work expected? Is load runnable or I/O blocked? |
| Memory low | Is swap active? Is the kernel killing processes? Is usage growing? |
| Disk full | Which filesystem and directory? Are deleted files still open? |
| 502 from Nginx | Is the upstream listening? Is its health endpoint healthy? |
| Timeout | DNS, route, firewall, listener, application, or dependency latency? |
| Frequent restart | What exit code and journal message preceded it? |
Useful drill-down commands:
Keep journals bounded
Tune retention to incident and compliance needs. Logs required for investigations should be shipped off-host; a failed or compromised server cannot be its only evidence store.
Back up state, not machines
Define the recoverable components:
- database dumps or storage-native backups;
- user uploads and other persistent volumes;
- configuration represented as code;
- encrypted secrets in an approved secrets system; and
- the exact application image or release artifact.
Example PostgreSQL logical backup:
Copy backups to a separate account or region, encrypt them, apply retention, and monitor the job. A local file on the same server is not disaster recovery.
Test the restore
At a regular cadence, restore into an isolated environment:
Start from empty infrastructure
Provision a fresh server or isolated database. Do not rely on undocumented remnants.
Fetch and verify backup integrity
Validate checksums and decryption before attempting restore.
Restore data and deploy the matching application
Record tool versions and duration; watch for schema incompatibility.
Run functional checks
Validate representative records, authentication, writes, uploads, and critical user journeys.
Record achieved RPO and RTO
Recovery point objective is tolerable data loss. Recovery time objective is tolerable outage. The test reveals whether you actually meet them.
Write down what happened
End the incident with a concise record: impact, start/end time, detection, timeline, contributing conditions, mitigations, recovery evidence, owner, and follow-up work. Separate learning from blame.
A backup is not enough Test the restore on a schedule. The test should show that the team can recover working data and service within the agreed recovery time.