Cloud SQL instances with automated backups turned off

What a Cloud SQL instance without automated backups cannot recover from

Automated backups run on a scheduled cadence while the instance is running, starting inside a backup window you choose. The Cloud SQL backup overview also notes that automated backups are needed to support point-in-time recovery, which is what lets you restore to the minute before a bad DELETE rather than to last week.

With them disabled, the only restore points are on-demand backups someone remembered to take. Replication does not help: a dropped table replicates to the standby and to read replicas just as faithfully as a good write. And if the instance itself is deleted, Google keeps the backups of a deleted instance for four days unless you set it to retain them, which assumes there were backups to keep.

Listing instances and their backup setting

gcloud sql instances list \
  --format="table(name, databaseVersion, settings.backupConfiguration.enabled, settings.backupConfiguration.startTime)"

True in the enabled column means scheduled backups are on. False or an empty value means there is no automated backup.

How ZopNight decides backups are off

The rule first confirms the resource is a real Cloud SQL instance by checking that ZopNight has recorded its machine tier. It then reads the backup configuration Cloud SQL reports. Unless that configuration says automated backups are enabled, the rule fires. ZopNight treats a missing backup block the same as an explicit false, because in both cases no scheduled backup is taken.

Records that do not produce a finding

Resources without a recorded tier are not treated as Cloud SQL instances and are skipped. Any instance reporting automated backups as enabled is silent, whatever its retention count. How long backups are kept is a separate question: dev and test instances that keep more backups than they need are covered by GCP Cloud SQL Excessive Backup Retention for Dev/Test.

Risk, not a saving

The finding carries a $0 saving. Turning backups on adds backup storage to the bill. The risk it closes is permanent data loss from an operator mistake, a faulty deploy or corruption, with no point-in-time recovery to fall back on.

Turning automated backups on

1. Pick a backup start time in a low-traffic period. The value is in UTC and opens a 4-hour window in which the backup can start.

2. Enable it, per Google’s backup configuration steps:

   gcloud sql instances patch INSTANCE_NAME --backup-start-time=02:00

3. Confirm with gcloud sql instances describe INSTANCE_NAME that backupConfiguration shows enabled: true and your start time.

4. For MySQL, point-in-time recovery also needs binary logging, so add --enable-bin-log to the same patch if it is not already on.

5. Take an on-demand backup now so you have a restore point before the first scheduled run.