Review Cloud SQL automatic backups

Configure a supported backup method and retention policy, and verify that restoration works.

Description

Without the automatic backups a Cloud SQL instance needs, data damaged by mistakes or failures may be difficult to recover. Replicas and high availability do not replace backups, and enabling a backup feature alone does not establish that recovery objectives are met.

Use settings appropriate to the engine and selected backup method. Read replicas cannot have their own backups, so verify protection of the source instance. Point-in-time recovery also has engine-specific log requirements.

Potential impact

  • Without recoverable backups, data loss may become permanent and service interruption may last longer.
  • An unsuitable retention period or untested restore procedure can prevent recovery to the required point.

Remediation

Enable supported automatic backups on the instance being protected and align the schedule and retention with recovery objectives. For the standard backup example, set settings.backup_configuration.enabled to true. Configure engine-specific point-in-time recovery when needed, and test backup success and actual restoration.

Examples

These are MySQL instance creation excerpts. Supply mysql_database_version and cloud_sql_tier values supported by the installed module and service, plus the actual project and service account JSON file. For an existing instance, use a supported Cloud SQL administration path; the google.cloud 1.14.0 module cannot update it.

Before

yaml
- name: create a second instance
  google.cloud.gcp_sql_instance:
    name: "{{ resource_name }}-2"
    database_version: "{{ mysql_database_version }}"
    settings:
      tier: "{{ cloud_sql_tier }}"
    region: us-central1
    project: test_project
    auth_kind: serviceaccount
    service_account_file: "/tmp/auth.pem"
    state: present

- name: create a forth instance
  google.cloud.gcp_sql_instance:
    name: "{{ resource_name }}-2"
    database_version: "{{ mysql_database_version }}"
    settings:
      backup_configuration:
        binary_log_enabled: no
        enabled: no
      tier: "{{ cloud_sql_tier }}"
    region: us-central1
    project: test_project
    auth_kind: serviceaccount
    service_account_file: "/tmp/auth.pem"
    state: present

The first task omits backup settings; the second disables automatic backups and binary logs. Omission alone does not establish the actual backup state. The tasks are separate configuration examples.

After

yaml
- name: create a instance
  google.cloud.gcp_sql_instance:
    name: "{{ resource_name }}-2"
    database_version: "{{ mysql_database_version }}"
    settings:
      backup_configuration:
        binary_log_enabled: yes
        enabled: yes
      tier: "{{ cloud_sql_tier }}"
    region: us-central1
    project: test_project
    auth_kind: serviceaccount
    service_account_file: /tmp/auth.pem
    state: present

This enables automatic backups and MySQL binary logging. Verify scheduling, retention and recovery, and do not apply the binary logging setting unchanged to other engines.

References