​
Overview

Everything about protecting one machine: its plan, its schedule, and what it has actually backed up.
Navigation: Compute → Virtual Machines → click a machine → Backups.

​
The plan comes first

Nothing here works until the machine is enrolled in a backup plan. Without one the schedule card blocks with “Assign a backup plan first” and the create button is unavailable.

​
Changing a plan takes two steps

You cannot swap one plan for another in a single action. With a plan assigned, the selector is disabled and the submit button relabels itself Remove Current Plan First. The card explains why:
Automatic plan replacement is disabled because removal and assignment are not atomic. Explicitly remove the current plan first; existing backup history is retained.
So the sequence is Remove Plan, then assign the new one — and the machine is unprotected in the gap. Plan a window for it rather than doing it casually on something important.
Removing asks Remove backup plan? and warns that manual and scheduled backups will be disabled, that the schedule will be permanently deleted, and that existing history is retained.

​
The schedule

Interval and timezone are locked on an existing schedule:
Interval and timezone are locked for an existing schedule. Delete it explicitly before creating a schedule with a different cadence; timing within the current cadence can be updated safely.
So moving a daily backup from 02:00 to 03:00 is fine. Switching daily to weekly means deleting the schedule and creating a new one.
There is no retention field. How many backups are kept comes from the plan, not the schedule — and changing it means changing the plan, which is the two-step dance above.

​
Backup history

Empty it reads No backups yet — “Create an on-demand backup, or wait for the configured schedule to run.”
History survives removing a plan. If a machine shows backups but no plan, someone removed the plan and the backups remained — which is the designed behaviour, not a bug.

​
When the region can’t do backups

If no backup offering is enabled for the zone, everything here goes read-only with an explanation rather than failing:
No backup offering is enabled for this zone. Existing backup history remains visible, but plan, backup, and schedule actions are disabled until an offering is configured.
That’s a platform configuration matter — contact support rather than retrying.

​
Common task: protect a production machine

1

Enrol it in a plan

Enable Backups and pick the plan matching your retention requirement. Retention comes from the plan, so this choice determines how far back you can ever go.
2

Take a manual baseline immediately

Don’t wait for the schedule’s first run to have a restore point. Use Create Backup.
3

Add a schedule

Daily at 02:00 UTC is a sensible default. Read the Schedule preview before saving — an off-by-one on day-of-week is invisible in the raw fields.
4

Confirm a backup actually completes

Check the history table. A row that says Creating is not yet a restore point.
5

Test a restore before you need one

From Backups, use Create VM from Backup rather than restoring in place. An untested backup is a hope, not a plan.
Pair this with a snapshot policy on the machine’s data volume. Snapshots are cheap, frequent and same-storage — right for “I broke it ten minutes ago”. Backups are separate and whole-machine — right for “the machine is gone”.

Backups

Plans, restoring, and backups versus snapshots.

Backup Schedules

The account-wide schedule list.

Schedules tab

Other automation for this machine.