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 backups | Server-wide or per instance | Professional to schedule |
| Instance restores | Server-wide or per instance | Professional to schedule |
| Certificate renewal | Server-wide | Never restricted |
| PostgreSQL vacuum | Server-wide | Never restricted |
| PostgreSQL reindex | Server-wide | Never restricted |
| Odoo image cleanup | Server-wide | Never restricted |
| Editor session cleanup | Server-wide | Never restricted |
| Staged upload cleanup | Server-wide | Never restricted |
| Disk usage measurement | Server-wide | Professional and up (Resource usage) |
| Instance health check | Server-wide | Never restricted |
| Log and journal expiry | Server-wide | Never restricted |
| License expiry warning | Server-wide | Never restricted |
| GeoLite2 database refresh | Server-wide | Never restricted |
| Analytics access sync | Server-wide | Never restricted |
| Backup storage measurement | Server-wide | Never restricted |
| Internet speed test | Server-wide | Never restricted |
Only the backups, the restores and the disk usage measurement are licensed. The disk usage measurement comes with the Resource usage feature, from the Professional edition up: a server without it neither measures nor shows it, because a measurement nobody may read would be work for nothing. Everything else the scheduler runs is the product looking after itself - pruning its own tables, renewing its license, checking for updates, refreshing the GeoLite2 databases - and an edition never decides whether a server stays healthy.
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. Restoring a whole instance, by hand or on a schedule, needs the Professional edition: Community restores a database, not an instance.
Instance backups backs up every instance whose backup mode is Automatic, every day at 20:30 UTC by default. Instance restores runs every Sunday at 01:30 UTC by default and restores over every instance whose restore mode is Automatic, from the restore sources on its Restore tab and with the database options set there.
The Test, Staging and Disaster recovery presets set an instance's restore mode to Automatic, so a copy made with one of them is restored over at the next run of Instance restores, and work done on it is lost. Set its restore mode to Manual to keep it. See What a scheduled restore does.
When the license stops carrying scheduled backups, the backup and restore schedules are disabled with their times kept, and the page says the license switched them off; the disk usage measurement stops the same way when its feature goes. Both come back by themselves when a license carries them again. See When the license changes.
Staged upload cleanup removes uploaded archives older than a day that no restore used. The New instance wizard uploads a backup archive the moment it is chosen, so a wizard left without pressing Create leaves one behind; a restore that runs removes its own upload. It runs daily and when the management API starts, and is on by default.
Odoo image cleanup removes the images nothing needs any more, every night. It first removes the stopped code editors of instances that no longer exist on the server, so their images go in the same run, and names them in the job's result; when the instance list cannot be read it leaves every editor alone and still cleans up the images. Then it removes:
- Earlier versions of an instance's image. Odoo images to keep counts the image the instance runs: at 1 the cleanup keeps that image and nothing else of the instance, at 2 it also keeps the newest earlier one, which is the one to go back to.
- The images of an instance that no longer exists, all of them.
- Untagged images a rebuild left behind, including a base image once the images built on it are gone; a chain of them goes in the same run, the images built on a base before the base. A base image that an image which stays is built on is kept, and not tried again every night.
- Other unused images, such as an old Odoo base image or a PostgreSQL version the server no longer runs. The images the product itself needs stay, so they are not downloaded again every day: the one the health check reads modules with, the PostgreSQL client image the backups run, and the current release's code editor and SSH gateway images. Those of an earlier release can go.
An image a container uses is never removed, whether the container runs or not.
Editor session cleanup removes the code editor sessions nobody has used for the number of days you set (see Workspace profiles and editor sessions). It also removes the code editors of instances that no longer exist on the server; a running one is left alone and named in the job's result. While the schedule is on, a start of the management API with no editor session cleanup succeeded in the last 24 hours runs one for those editors only, a few minutes after the start, and leaves the sessions to the schedule: an update gets it straight away, and the several restarts of one update run it once. If you saved this schedule with and once at startup switched on, the whole cleanup runs after every restart instead.
Internet speed test measures the server's download and upload throughput, and fills the Internet card on the dashboard. It runs at night, because it deliberately saturates the connection for the length of the test. When the management API starts, it runs only if no speed test has succeeded in the last 24 hours - a new server, or one back after a day away, gets its first figures without waiting for the night, while the restarts of an update do not saturate the connection again. Its job lasts as long as the test (about twenty seconds) and ends with the figures, or fails with the reason when the test could not measure the connection. If you saved this schedule with and once at startup switched on, a test still runs after every restart; switch it off here if you do not want that.
Housekeeping is never restricted
The schedules that look after the server's own state keep running at every edition, including unregistered, so a lapsed license never lets logs fill a disk. The license expiry warning is one of them, so the warning that a license is about to lapse keeps coming.
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
pelmo$ ohm server postgres vacuum --server pelmopelmo$ ohm server postgres reindex --server pelmo$ ohm system maintenanceThere is no crontab
The API's own scheduler is the only owner of these schedules, and the product writes no crontab at all.