Cloud SQL's automated backups and point-in-time recovery restore into Cloud SQL instances, inside your Google Cloud project. Cloud SQL can also export a SQL dump to a Cloud Storage bucket, but that's still in Google Cloud. A pg_dump from your own Windows machine gives you an independent, portable copy, which is what you want if the project itself is at risk or you just need production data locally.
Step 1: Choose how to connect
| Option | How it works | Best for |
|---|---|---|
| Cloud SQL Auth Proxy | A small program on your PC opens an encrypted, IAM-authorized tunnel; pg_dump connects to 127.0.0.1 | Most setups. No IP allow-listing, works from anywhere |
| Authorized networks | Give the instance a public IP and allow your PC's public IP | Quick tests; fixed office IPs |
Google recommends the proxy, and it suits scheduled backups well because your changing home IP stops mattering.
Step 2a: Using the Cloud SQL Auth Proxy
- Download
cloud-sql-proxy.x64.exefrom Google's Cloud SQL Auth Proxy page. - Give the account it runs as the Cloud SQL Client role. For unattended use, create a service account and download its key file.
- Find your instance connection name on the instance's Overview page:
project:region:instance. - Start the proxy on a local port:
.\cloud-sql-proxy.x64.exe --port 5433 --credentials-file C:\ProgramData\pg-backup\sa-key.json my-project:europe-west1:prod-dbpg_dump then connects to 127.0.0.1:5433, and the proxy handles encryption, so leave PGSSLMODE at its default.
Step 2b: Using authorized networks
In the console, open the instance → Connections → Networking, make sure Public IP is on, and add your public IP under Authorized networks. Then connect to the instance's public IP on port 5432 with PGSSLMODE=require (or stricter, if you've enforced SSL with client certificates).
Step 3: Back it up
Through the proxy:
& 'C:\Program Files\PostgreSQL\18\bin\pg_dump.exe' -h 127.0.0.1 -p 5433 -U postgres `
-F c -f "D:\Backups\prod-$(Get-Date -Format yyyyMMdd-HHmm).dump" appdbUse client tools at least as new as the instance's PostgreSQL version. The postgres user on Cloud SQL is a member of cloudsqlsuperuser but not a real superuser. It can dump anything it can read, which normally includes all your application's tables.
Step 4: Schedule it
Combine it with the script from the main Windows guide. For the proxy approach, start it at the top of the script and stop it at the end:
$proxy = Start-Process 'C:\ProgramData\pg-backup\cloud-sql-proxy.x64.exe' -PassThru -WindowStyle Hidden -ArgumentList @(
'--port', '5433', '--credentials-file', 'C:\ProgramData\pg-backup\sa-key.json', 'my-project:europe-west1:prod-db')
Start-Sleep -Seconds 5 # give it a moment to listen
# ... the backup part of the script, with $PgHost = '127.0.0.1' and $Port = 5433 ...
Stop-Process -Id $proxy.IdKeep the service account key in the same locked-down folder as pgpass.conf. Anyone who has that key can reach the database.
Restoring
& "$bin\createdb.exe" -h localhost -U postgres prod_copy
& "$bin\pg_restore.exe" -h localhost -U postgres -d prod_copy --no-owner --no-privileges D:\Backups\prod-20261014-0200.dumpRestoring into Cloud SQL works the same way through the proxy. Use --no-owner so objects belong to the user you restore as. More in restoring a .dump file on Windows.
How PostgresBackup handles Cloud SQL
PostgresBackup connects to whatever address and port you give it, so it works with either option. With authorized networks, add the public IP with SslMode=Require. With the Auth Proxy, run the proxy at startup (a scheduled task or a service) and add 127.0.0.1 and the proxy port as the server. The app's background service then takes the nightly backups from boot and handles retention and restores.