Cloud SQL instances running without automated backups
What does ZopNight detect here?
Cloud SQL instances whose backupConfiguration is disabled or absent cannot be restored to a point in time before corruption or an accidental delete. ZopNight reads the backup_enabled flag the discoverer stamps in both polarities and flags anything not exactly true, recommending backups plus at least 7 days of retention.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-145 |
| Category | compliance |
| Severity | high |
| Metric | none — pure configuration read |
| Source | cloudsql_backup.go |
Where it applies
No backups, no rewind
Every failure mode that matters for a database (a bad migration, a fat-fingered DELETE, application-level corruption) happens inside a healthy instance, where replication and HA faithfully copy the damage. Automated backups are the only mechanism that lets Cloud SQL restore to a moment before the mistake, and for MySQL and PostgreSQL they are also the prerequisite for point-in-time recovery via write-ahead logs. An instance without them can lose everything since its last manual export, which for most such instances means everything.
Absent config counts as disabled
The discoverer stamps backup_enabled in both polarities: true when
backupConfiguration.enabled is true, and false both when it is explicitly false and
when the backupConfiguration block is missing from the instance entirely. That second
half matters. An instance created by minimal Terraform that never mentioned backups has
no block at all, and treating “unconfigured” as anything but disabled would hide exactly
the instances most likely to be unprotected. The rule flags any value other than an
exact true.
PITR needs more than a nightly dump
The remediation baseline is automated backups in an off-peak window with at least 7 days of retention. For production, also enable point-in-time recovery so restores land on a transaction, not on last night’s snapshot. Then test one restore, because an unverified backup is a hypothesis. Backup storage bills separately, which is the trade this high-severity finding says to accept.
Check the backup configuration
gcloud sql instances describe my-instance \ --format="value(settings.backupConfiguration.enabled,settings.backupConfiguration.startTime)"An empty or False first field reproduces the finding. Enabling is gcloud sql instances patch my-instance --backup-start-time=03:00.
Only real Cloud SQL instances are judged
A guard worth knowing: the rule evaluates only resources the discoverer stamped a Cloud
SQL tier on, so a resource it never actually inspected cannot be mis-flagged as
“backups disabled” by mere absence of data. The finding itself is $0: compliance
categories carry no savings figure and skip the cost-rule materiality floors.