Problem
Every non-alert run mirrors its full stdout/stderr into $LOG_FILE via exec > >(tee -a "$LOG_FILE") 2>&1 (append-only). Nothing ever rotates or truncates it:
- The local retention prune (
find "$BACKUP_DIR" -type f -mtime +7 -name "mongo_backup_*.gz") targets only the .gz dumps, not the log.
- There is no
logrotate snippet in the repo and no in-script size/age cap.
So logs/mongo_backup_manager.log grows without bound. At the intended hourly cadence on a long-lived host (e.g. the shared-DB box) it climbs steadily and indefinitely — each run appends the run banner + stage markers + mongodump/S3 upload progress lines + prune output. (Already ~25 KB after a handful of manual runs during activation.)
Why it matters a bit more now
PR #12 changed the failure alert to read this file (slices from the last Run started at … to EOF via awk). An ever-growing file means the alert does a full-file scan on every invocation — still linear, but avoidable.
Options
- In-script self-cap (preferred — matches the single-script, zero-dependency design): after each run, trim
$LOG_FILE to the last N runs or a byte/line cap (e.g. keep the last ~1 MB, or the last K Run started blocks). Since the alert only needs the last run block, an aggressive cap loses nothing.
- Ship a
logrotate drop-in (/etc/logrotate.d/mongo-backup) — but that's an extra install step and an external dependency, less self-contained than (1).
- Rotate on threshold — move to
.log.1 when > N, keep 1–2 generations.
Suggested
Option 1: a small rotate_log step (size- or run-count-bounded) invoked once per run, no external dependency. Keep .gitignore coverage (logs already ignored).
Context: surfaced during the #11/#12 alert work (alert now reads this log).
Problem
Every non-alert run mirrors its full stdout/stderr into
$LOG_FILEviaexec > >(tee -a "$LOG_FILE") 2>&1(append-only). Nothing ever rotates or truncates it:find "$BACKUP_DIR" -type f -mtime +7 -name "mongo_backup_*.gz") targets only the.gzdumps, not the log.logrotatesnippet in the repo and no in-script size/age cap.So
logs/mongo_backup_manager.loggrows without bound. At the intended hourly cadence on a long-lived host (e.g. the shared-DB box) it climbs steadily and indefinitely — each run appends the run banner + stage markers +mongodump/S3 upload progress lines + prune output. (Already ~25 KB after a handful of manual runs during activation.)Why it matters a bit more now
PR #12 changed the failure alert to read this file (slices from the last
Run started at …to EOF viaawk). An ever-growing file means the alert does a full-file scan on every invocation — still linear, but avoidable.Options
$LOG_FILEto the last N runs or a byte/line cap (e.g. keep the last ~1 MB, or the last KRun startedblocks). Since the alert only needs the last run block, an aggressive cap loses nothing.logrotatedrop-in (/etc/logrotate.d/mongo-backup) — but that's an extra install step and an external dependency, less self-contained than (1)..log.1when> N, keep 1–2 generations.Suggested
Option 1: a small
rotate_logstep (size- or run-count-bounded) invoked once per run, no external dependency. Keep.gitignorecoverage (logsalready ignored).Context: surfaced during the #11/#12 alert work (alert now reads this log).