Google Cloud SQL

To back up a Google Cloud SQL for PostgreSQL database, Backup connects to its public IP like any other Postgres. Cloud SQL runs real PostgreSQL, so pg_dump works normally. Two Cloud SQL specifics matter: enabling a public IP with an authorized network for Backup's egress IP, and choosing the right SSL mode.

Which connection string

Cloud SQL for PostgreSQL listens on port 5432. Enable a public IP and connect to that IPv4 address directly. (The Cloud SQL Auth Proxy is an alternative, but it needs to run co-located with the client and a Google identity, which a third-party backup service can't do, so the public-IP path is the one to use.)

Find the connection details

1. In the Google Cloud console, open your Cloud SQL instance.
2. Go to Connections → Networking and enable the Public IP checkbox, then Save. Cloud SQL assigns a static IPv4 address.
3. The public IP shows on the instance Overview page (or run gcloud sql instances describe <instance>).
4. Create a database user under Users → Add user account → Built-in authentication (username + password), then a read-only role:

CREATE ROLE backup_ro WITH LOGIN PASSWORD '<strong-password>';
GRANT CONNECT ON DATABASE <your-db> TO backup_ro;
GRANT pg_read_all_data TO backup_ro;   -- Postgres 14+

Use built-in password auth (simpler than IAM auth, whose tokens expire hourly). See read-only role snippets.

Set SSL mode to require in Backup, and on the instance set the SSL mode to "Allow only SSL connections" (Connections → Security). Do not choose "Require trusted client certificates": that demands a client certificate, which a server-TLS-only backup connection doesn't present, and would block Backup.

Network access

Cloud SQL's public IP is protected by Authorized networks. Add Backup's egress IP so it isn't refused:

1. In the console, open the instance and go to Connections → Networking.
2. Under Authorized networks, choose Add a network.
3. Enter a name and the range 18.196.207.101/32 (CIDR notation is required; /32 is a single host). Done, then Save.

Cloud SQL doesn't support IPv6 authorized networks, so the IPv4 /32 above is the only correct form. See network access.

Restore tests and managed extensions

Every backup can be restore-tested: Backup restores it into a throwaway, vanilla stock PostgreSQL engine and confirms your data comes back. Cloud SQL preinstalls Google-authored extensions that don't exist in community Postgres, so if your database uses any, they can't be recreated on a generic engine. These are the google_-prefixed extensions, for example google_ml_integration, google_read_only_session, and google_vacuum_mgmt.

Those aren't your application data. A restore test treats their absence as expected, notes them in the log, and still records a clean Passed. What it proves is what matters: your schemas, tables, and rows all restore. Details: Provider-managed extensions.

Community extensions (postgis, pgvector, pg_stat_statements, hstore, uuid-ossp, and so on) restore normally wherever the same extension is installed.

From there, it's the standard flow

Backup runs a full pg_dump on your schedule and writes the encrypted archive to storage you control. You can download any backup and restore it with standard Postgres tools, independent of Norcube. For the general walkthrough, see connect a database.