Maintenance
The Maintenance page configures what runs on a schedule. The scheduler lives in the API container, ticks every thirty seconds, and reads its schedules from the database on every tick, so a change takes effect immediately.
The operations
| Operation | Scope | Licensed |
|---|---|---|
| Instance backup | Server-wide or per instance | Professional to schedule |
| Instance restore | Server-wide or per instance | Professional to schedule |
| Certificate renewal | Server-wide | Professional to schedule |
| PostgreSQL vacuum | Server-wide | Professional to schedule |
| PostgreSQL reindex | Server-wide | Professional to schedule |
| Image cleanup | Server-wide | Professional to schedule |
| Disk usage report | Server-wide | Housekeeping, never restricted |
| Log and journal expiry | Server-wide | Housekeeping, never restricted |
| Licence expiry warning | Server-wide | Housekeeping, never restricted |
Starting any of these by hand needs only the edition that operation itself needs. Backing up by hand is Community; scheduling the same backup is Professional.
Housekeeping is never restricted
The schedules that look after the server's own state keep running at every edition, including unregistered. A licensing state that let logs fill a disk would be a product that damages the machine it runs on when you stop paying, which is not a reasonable thing to build.
The licence expiry warning is in that category on purpose: the notification that your licence is about to lapse must not be the first thing the lapse disables.
Per-instance schedules
Backup and restore can additionally be scheduled per instance, several of a type. See Scheduled backups for the exclusion rule, which is the one genuinely surprising behaviour on this page.
The scheduler does not catch up
A schedule whose due time passed while the API was down does not fire late. It runs at its next due time.
This is the right default. Catching up would mean an API that was down for a weekend waking up and running three nights of backups at once, on a server that has just come back.
The consequence is that an outage silently costs you that window's run. If the API was down overnight, take the backup by hand.
By hand
prod-1# odoocli server postgres vacuum --server prod-1prod-1# odoocli server postgres reindex --server prod-1# odoocli system maintenanceHost cron versus the API scheduler
On a server where the API container is present, the API owns scheduling and the equivalent host crontab entries are removed automatically, so nothing runs twice. On a bare host without the API container, the CLI's crontab owns it instead.