thesabear/public
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

cron-scheduler: drop PVE backup-disabled disclosure from public doc

Browse Source 
Same status the disaster-recovery.md conversation already ruled out of
the public repo - operationally true, not employer-facing. KB and
NocoDB job notes keep the real detail; only the public prose changes.
This commit is contained in:
thesabear committed 2026-08-28 11:36:33 +03:00
1 parent 3562322d50
commit 566f5d9f92
1 file changed
+1 -1
Download Patch File Download Diff File Expand all files Collapse all files
docs/cron-scheduler.md
+1 -1
View File
@@ -30,7 +30,7 @@ The harder, more "correct" version of this tool would auto-discover every schedu
Populating 50 rows by hand across a dozen-plus different systems wasn't just data entry — it surfaced real scheduling conflicts and real bad assumptions: Populating 50 rows by hand across a dozen-plus different systems wasn't just data entry — it surfaced real scheduling conflicts and real bad assumptions:
- **A three-way monthly collision, resolved by moving one job.** PBS's own datastore garbage-collection job used to run first-Saturday-of-month 02:00 — the same slot as the weekly `os-update-vms` Kestra flow *and* the `dashy-fleet-audit` flow, both of which also land on Saturday. Moved to first-Tuesday-of-month 10:00 instead, clearing all three out of each other's way in one change rather than shuffling the other two around it. - **A three-way monthly collision, resolved by moving one job.** PBS's own datastore garbage-collection job used to run first-Saturday-of-month 02:00 — the same slot as the weekly `os-update-vms` Kestra flow *and* the `dashy-fleet-audit` flow, both of which also land on Saturday. Moved to first-Tuesday-of-month 10:00 instead, clearing all three out of each other's way in one change rather than shuffling the other two around it.
- **A cascading reschedule, not an isolated fix.** Kopia's backup snapshot used to run 07:00 — directly on top of Proxmox hyper2's own fixed VM-backup slot (disk-intensive, kept fixed on purpose even while currently disabled). Moving Kopia to 08:00 then put it on top of ClamAV's scan, so ClamAV moved again to 09:00 — one collision fix triggering a second, tracked and resolved rather than left half-done. - **A cascading reschedule, not an isolated fix.** Kopia's backup snapshot used to run 07:00 — directly on top of Proxmox hyper2's own fixed VM-backup slot (disk-intensive, kept fixed on purpose). Moving Kopia to 08:00 then put it on top of ClamAV's scan, so ClamAV moved again to 09:00 — one collision fix triggering a second, tracked and resolved rather than left half-done.
- **Don't trust a duration number until it comes from a real completed run.** `app-update`'s first-logged duration was ~2-3 seconds — which turned out to be sampled from killed, failed, and paused runs, not a real completion. The actual number, from a genuine successful run, is ~16 minutes: an 8x difference between "what the data said" and "what actually happened," caught only by checking. - **Don't trust a duration number until it comes from a real completed run.** `app-update`'s first-logged duration was ~2-3 seconds — which turned out to be sampled from killed, failed, and paused runs, not a real completion. The actual number, from a genuine successful run, is ~16 minutes: an 8x difference between "what the data said" and "what actually happened," caught only by checking.
- **The heaviest job in the entire fleet isn't a backup.** Radarr's own `Refresh Movie` task runs ~1h15min daily — heavier than any single PVE backup job, and the heaviest scheduled task found anywhere in the *arr media suite. Radarr's own backup job, by contrast, finishes in about 41 seconds. - **The heaviest job in the entire fleet isn't a backup.** Radarr's own `Refresh Movie` task runs ~1h15min daily — heavier than any single PVE backup job, and the heaviest scheduled task found anywhere in the *arr media suite. Radarr's own backup job, by contrast, finishes in about 41 seconds.
- **A 404 that looked like an auth problem wasn't one.** Pulling Authentik's 18 internal task schedules initially 404'd against the endpoint documented for older versions (`/admin/system_tasks/`) — the real one had moved to `/api/v3/tasks/schedules/` in the installed version. A wrong assumption about *why* something failed costs more time than the actual fix would have. - **A 404 that looked like an auth problem wasn't one.** Pulling Authentik's 18 internal task schedules initially 404'd against the endpoint documented for older versions (`/admin/system_tasks/`) — the real one had moved to `/api/v3/tasks/schedules/` in the installed version. A wrong assumption about *why* something failed costs more time than the actual fix would have.