DR docs audit fix (2026-08-08): fix stale dates, path errors, add RPO/RTO, unbacked services, restore testing, rollback procedure, S3 access instructions

docs/backup-restore/ARCHITECTURE.md

@@ -113,9 +113,11 @@ Browser shows success toast → Restore History updates
 
 ### 3. Snapshot Storage (`/opt/backup-restore/snapshots/`)
 - Structure: `/<domain>/<YYYY-MM-DD_HHMMSS>/`
-- 9 WordPress domains, 10 snapshots each (10 days retention shown)
+- 9 WordPress domains, 10 snapshots each (10 days shown in UI)
+- Retention: **30 days** — `snapshot.sh` auto-deletes snapshots older than 30 days via cron
 - Average snapshot size: 16MB files + 74KB database
 - Total: ~1.4GB for full snapshot set
+- **⚠ Local only** — not synced to S3. If app3 fails, all local snapshots are lost. Daily 3 AM S3 backup (`app3-backup.sh`) provides coarser off-site coverage.
 
 ### 4. Restore Log (`/opt/backup-restore/logs/restore.log`)
 - Pipe-delimited format: `timestamp|domain|snapshot_id|status`
@@ -155,4 +157,4 @@ All served by CloudPanel on app3, backed up by this system:
 
 3. **Tar + mysqldump over rsync:** Snapshots are point-in-time archives, not incremental backups. Each snapshot is self-contained (files.tar.gz + database.sql). Restore is a single operation with no dependency chain.
 
-4. **No auth on backup API:** The endpoints have no authentication. Access is controlled by Caddy routing — only requests through my.itpropartner.com reach the app. Internal network only.
+4. **No auth on backup API:** The endpoints have no authentication. The UI at `my.itpropartner.com/backups/` is publicly accessible through Core's Caddy. Access control relies on obscurity (the domain is not widely known) and Caddy's TLS termination. For production use, consider adding IP whitelisting or Caddy basic auth.