comparison for homelab
Prompt
You are reviewing a proposed change to a small self-hosted media server. Do not assume access to the machine, the internet, or any files other than the information below. System: * Ubuntu Desktop mini PC * Docker Compose * 32 GB RAM, 1 TB NVMe * Services include Sonarr, Radarr, Prowlarr, Audiobookshelf, and several lightweight metadata/API services * Configuration is stored under `/srv/stacks` * Some applications use SQLite databases * Backups are made with restic to an rclone-backed remote * The operator wants minimal manual maintenance and prefers safe failure over automatic recovery that might destroy data * Docker images are pinned to explicit versions or digests; `latest` should not be introduced * Live SQLite database files should not simply be copied while applications are running * Updates should not proceed if the most recent verified backup is stale * Destructive Docker cleanup commands should be avoided unless their effects have been explicitly bounded and verified A proposed automation script does this every Sunday: 1. Run `docker compose pull` in every stack directory. 2. Run `docker compose up -d` for every stack. 3. Copy `/srv/stacks` recursively into `/tmp/backup`. 4. Run restic to back up `/tmp/backup`. 5. Run `docker system prune -af --volumes`. 6. If any container is unhealthy after 60 seconds, restart it once. 7. If it is still unhealthy, automatically roll back by replacing its image tag with `latest` and running `docker compose up -d`. 8. Send a success notification as long as the script itself exits with code 0. The operator says: "I mainly care that this runs unattended. If something goes wrong, I want the safest possible behavior. A failed update is acceptable; silent data loss or an unverified rollback is not." Review the proposal. Your response must contain exactly these five sections: 1. `Critical flaws` Identify the most important problems. Rank them from highest to lowest risk. Do not inflate the list with minor style issues. 2. `Correct execution order` Give a safer high-level sequence for backup, verification, update, health checking, rollback, cleanup, and notification. Do not write a full shell script. 3. `Rollback rule` State precisely what conditions must be true before an automated rollback is attempted, and when the system should instead stop and alert the operator. 4. `Failure scenario` Walk through one realistic failure involving a database-backed service during an update and explain how your proposed design prevents data loss or makes recovery auditable. 5. `Unknowns` List information that would need to be inspected on the real server before implementing the automation. Do not invent paths, APIs, commands, health checks, or application-specific backup mechanisms that were not supplied above. Constraints: * Treat "minimal manual maintenance" as secondary to protecting data. * Distinguish a backup having completed from a backup having been verified. * Do not recommend `latest` as a rollback mechanism. * Do not assume a container restart proves that its application is healthy. * If two requirements conflict, explicitly identify the conflict and resolve it. * Prefer bounded, reversible operations. * Be concise enough that an experienced operator could audit your reasoning quickly.
