Scheduled backups
Running a backup yourself needs only the edition that the backup itself needs. Letting the scheduler run it unattended is the Professional capability. The split is "by hand versus unattended", not "backup versus no backup".
Server-wide and per-instance
Backups and restores can be scheduled in two places, and they interact in one specific way worth knowing.
- A server-wide schedule sweeps every instance.
- An instance can hold its own schedules, and several of the same type.
While an instance holds at least one schedule of a type, it is excluded from the server-wide sweep for that type and runs as its own single-instance jobs instead. Remove its last schedule of that type and it returns to the sweep.
The effect is that an instance is never backed up twice by two schedules that both think they own it. The effect you have to watch for is the opposite: giving an instance a narrow schedule silently removes it from the broad one.
Where to configure
The Maintenance page for server-wide schedules, and the instance's own maintenance settings for per-instance ones.
What runs unattended, and what does not
The scheduler ticks every thirty seconds and does not catch up: a schedule whose moment passed while the API was down does not fire late. It runs at its next due time.
Housekeeping schedules that look after the server's own state are never licence-restricted. Those keep running on any edition, including unregistered.
When the licence lapses
The scheduler stops running the restricted operations and reports them as unlicensed rather than failing the tick. Nothing crashes, nothing retries in a loop, and the schedules are still there when a licence is installed again.
What this means in practice: an expired subscription silently stops your nightly backups. The licence expiry warning exists precisely because of this, and it is worth wiring the notification recipients up to somewhere a human reads.