A backup job is not yet a recovery plan

What the public implementation shows

Guevara includes a cron-based BackupJob that derives the database name from its connection, writes timestamped custom-format pg_dump artifacts, supports credential injection, captures process output, and checks the exit code.

The job turns live control-plane database state into a filesystem artifact on a configured schedule and timezone. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleBackup success matters only when the artifact is protected, retained, observed, and restorable.

The decision behind the mechanism

Backup execution is isolated as a scheduled service with explicit path and authentication configuration rather than being mixed into application request handling.

A successful local dump can still be lost with the host, expose credentials or financial data, fill the disk, or prove unusable when no restore has been tested. The mechanism matters because it gives that failure a named boundary, durable evidence, and a controlled response instead of leaving the outcome to timing or operator guesswork.

• Write to a restricted path with monitored free capacity.
• Protect database credentials and backup artifacts.
• Alert on missed schedules and non-zero exit codes.
• Run periodic restores and integrity checks in isolation.

How the control should be operated

Pair the job with encrypted off-host replication, retention, capacity alerts, structured success metrics, restore drills, and documented recovery-point and recovery-time objectives.

The dump becomes part of a verifiable recovery system instead of a comforting log line. The reusable lesson is not to copy a class or endpoint in isolation, but to preserve the relationship between identity, state, authority, evidence, and operational ownership.