docs: schedules live in root crontab, not /etc/cron.d or timers
Standardised 2026-08-31 on regular crontabs: nuc's push moved off its systemd timer (units kept disabled on disk), and the cron.d files on nuc and nas were folded into root's crontab. Notes the consequence accepted for nuc: a night with the box powered off is skipped rather than caught up after boot. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Fable 5
parent
4c6396a8fa
commit
1721d7b05d
+3
-3
@@ -31,7 +31,7 @@ incus project create backup -c features.images=false -c features.profiles=false
|
||||
/root/scripts/incus-copy.sh -p backup -s nucbackup
|
||||
```
|
||||
|
||||
Runs nightly via `/etc/cron.d/incus-copy` at **03:30** (30 min after
|
||||
Runs nightly from root's crontab at **03:30** (30 min after
|
||||
the profile-scheduled 03:00 instance snapshots, so VM refreshes stay
|
||||
incremental), logging to `/var/log/incus-copy.log` (logrotate:
|
||||
`/etc/logrotate.d/incus-copy`). Note the script's `flock` is global:
|
||||
@@ -245,8 +245,8 @@ once `usb4t` is imported.)
|
||||
| When | What | Where |
|
||||
|-------|------|-------|
|
||||
| 03:00 | instance snapshots (`snapshots.schedule` on the default profile, expiry 7d) | incus |
|
||||
| 03:30 | replicate all instances to the USB pool (`incus-copy.sh -p backup -s nucbackup`) | `/etc/cron.d/incus-copy` → `/var/log/incus-copy.log` |
|
||||
| 05:00 | apt dist-upgrade all running containers (`incus-container-upgrade.sh`; VMs and non-apt containers skipped; jellyfin pinned to the 10.11 series in-container) | `/etc/cron.d/incus-container-upgrade` → `/var/log/incus-container-upgrade.log` |
|
||||
| 03:30 | replicate all instances to the USB pool (`incus-copy.sh -p backup -s nucbackup`) | root crontab → `/var/log/incus-copy.log` |
|
||||
| 05:00 | apt dist-upgrade all running containers (`incus-container-upgrade.sh`; VMs and non-apt containers skipped; jellyfin pinned to the 10.11 series in-container) | root crontab → `/var/log/incus-container-upgrade.log` |
|
||||
|
||||
The ordering is deliberate: snapshot → backup → upgrade, so a broken
|
||||
upgrade is always one snapshot-restore away and the replicas predate it.
|
||||
|
||||
Reference in New Issue
Block a user