Skip to content

Backup Protection

Settings → Backup Protection sets three things that apply on top of your existing backup schedules:

  • Retention: keep backups by day, week and month instead of by a single age.
  • Immutable cloud backups: S3 Object Lock, so a cloud backup can't be deleted early, even by someone holding the S3 keys.
  • Restore checks: a weekly test that a backup really restores and boots.

With nothing set here, backups behave as they did before.

Retention

Local and datastore backups

Set how many Daily, Weekly and Monthly backups to keep. The console keeps the newest backup from each of that many days, weeks and months. For example, 7 / 4 / 6 keeps a week of dailies, a month of weeklies and half a year of monthlies.

All three at zero keeps the old rule: delete backups older than the retention days set in Platform Configuration. The newest backup of a VM is never deleted.

Cloud backups (S3)

Cloud backups are stored as chains: one full backup and the incrementals that depend on it. A chain is always kept or deleted whole, so an incremental never loses its full.

  • Newest chains: how many of the most recent chains to keep.
  • Plus monthly: also keep one chain per month for that many months.

Set up cloud backup in the Cloud Backup card first; until then this section says it's off.

Deleting old cloud backups removes them for good, including on buckets with versioning or Object Lock, so no hidden copies stay stored and billed.

Immutable cloud backups (Object Lock)

  1. Use a bucket created with Object Lock enabled. Most providers only allow this when the bucket is created.
  2. Pick the Object Lock mode:
    • Governance (recommended): each upload is locked for the chosen days. An S3 account with the bypass permission can still remove it.
    • Compliance: nobody, including the bucket owner, can delete it before the days run out.
  3. Set For days (1–3650).
  4. Check bucket confirms the bucket supports Object Lock before you save.
  5. Save.

The console checks that every upload really was locked and fails the backup, with the reason, if the provider didn't lock it. The console's own nightly backup is locked the same way. A locked backup stays listed and restorable until its lock expires.

Compliance mode can't be undone

In Compliance mode you can't shorten or remove a lock, and you can't delete the bucket until every object's lock has expired. You pay for the storage until then. Try Governance first.

Restore checks

A restore check proves a backup is usable, not just present. Each check:

  1. restores the VM's newest cloud backup on the VM's own host,
  2. boots an isolated copy with no network,
  3. waits for the QEMU guest agent to answer,
  4. deletes the copy.

To schedule it, tick Check one VM every week, choose the Day, Hour (UTC) and Wait for boot (min), then Save. Each week the VM that has gone longest without a check goes next. To check a particular VM now, pick it and click Check now.

The table under the settings shows each check's time, VM, result and detail. A failed check sends the A restore check failed notification (see Notifications & Alarms).

Requirements

  • The VM needs a cloud backup and the QEMU guest agent installed and running inside the guest. Without the agent the check can't tell the copy booted.
  • The VM's host needs enough free memory and disk for one more copy of the VM while the check runs.
  • Restore checks are off by default.

See also