​
Overview

A backup schedule runs backups of one machine automatically. One schedule per machine, and the machine must already be enrolled in a backup plan.
Navigation: Storage → Backup Schedules. Titled Backup Schedules, subtitled “Manage automated backup scheduling for VMs”.

​
Columns

There is no status column, because a schedule has no state — it either exists for a machine or it doesn’t. Whether its backups are succeeding is visible in Backups, not here.

​
Retention is not yours to set

Max Backups is read-only. Unlike snapshot policies, where you choose retention between 1 and 10, a backup schedule has no retention field at all — the number comes from the backup plan the machine is enrolled in, and it shows — when the plan doesn’t specify one.To change how many backups are kept, change the machine’s plan. Since plan replacement isn’t atomic, that means removing the current plan and assigning another.

​
What one scheduled run does

The schedule only decides when. Everything about how much is kept comes from the plan.

​
Creating a schedule

1

Choose the machine

Virtual Machine. The dialog then shows its Backup Plan, or blocks with “No backup plan assigned” and “This VM must be enrolled in a backup plan before a schedule can be created.” plus an Enable Backups button.
2

Pick the interval

Interval defaults to Daily.
3

Set the timezone

UTC plus nine common zones — the same list snapshot policies use.
4

Set the time

The fields depend on the interval:
5

Check the preview

Schedule Preview restates the schedule in words. Read it before submitting.
Success reports “Backup schedule created successfully”.
As with snapshot policies, Day of Month accepts 31, and a schedule set to 31 will skip every month that’s shorter. Use 28 or lower for a schedule that actually runs monthly.

​
Choosing an interval

Backups are heavier than snapshots — they copy the whole machine to separate storage — so interval choice has real cost.
Pair a coarse backup schedule with a fine snapshot policy. Snapshots give you cheap, frequent, same-storage restore points; the backup gives you the durable off-volume copy. Hourly backups are usually the wrong tool for a granularity problem.

​
Editing and deleting

Edit Schedule changes the interval, time, and timezone. The machine is fixed — shown read-only — so moving a schedule means deleting and recreating it. Delete Schedule says: “Automated backups for this VM will stop immediately. Existing backups are not affected.”
Deleting a schedule leaves the machine’s existing backups in place and the plan enrolment intact. Manual backups still work. It only stops the automation.

​
Worked example: staggered schedules across a fleet

Six machines all backing up at 02:00 will contend for storage bandwidth and may overrun.
1

Group by how much loss you can tolerate

Database machines daily; stateless web machines weekly, since they rebuild from a template anyway.
2

Stagger the times

Rather than all at 02:00, spread them: 02:00, 02:20, 02:40, 03:00. Same window, no pile-up.
3

Use one timezone for the whole fleet

UTC for everything. Mixed timezones make “did last night’s backups all finish?” much harder to answer, and shift twice a year.
4

Verify against the output

After a cycle, go to Backups, filter Status to Backed Up, sort by Created, and confirm every machine appears with sensible spacing.
Creating the schedule is not evidence it works. A schedule can exist while every run fails — on quota, on a missing offering, on a machine that’s gone. The schedule list won’t tell you; Backups and Jobs will. Check after the first expected run.

​
Empty and error states

Backups

Plans, manual backups, and restoring.

Snapshot Policies

The per-volume equivalent, with retention you control.

Jobs

Whether scheduled runs are actually succeeding.