Google Cloud SQL runs automated backups and point-in-time recovery, and they work well. They also live in the same Google Cloud project as the database. For anything important, a copy in storage you control, in a separate account, on your own retention, is worth having. And a backup that has never been restored is a hope, not a guarantee.
Norcube Backup gives you an independent copy in storage you own, restore-tested on every run.
What it does
Point Norcube at your Cloud SQL instance. On your schedule it runs a full pg_dump, encrypts it, and writes it to a bucket you control. You can download any backup and restore it with standard Postgres tools, independent of Google and of us.
Connecting Cloud SQL
Cloud SQL is real Postgres, so the connection is ordinary once the networking is set. Enable a public IP on the instance, then add Backup’s egress IP 18.196.207.101/32 under Authorized networks. Set the instance SSL mode to “Allow only SSL connections” (not “Require trusted client certificates”, which would block a service that doesn’t present a client cert), and connect with sslmode=require on a read-only user. Full steps are in the Google Cloud SQL backup guide.
Prove it restores
Every backup can be restore-tested: Norcube restores it into a throwaway database and confirms your data comes back. Cloud SQL’s Google-authored extensions (the google_-prefixed ones) exist only on Google’s platform, so a restore test recognizes their absence as expected and still records a clean pass. Your schemas, tables, and rows are what it proves came back.
Backups are only real once you’ve restored one
An independent, restore-tested copy of your Cloud SQL database in your own storage is cheap insurance. Try it on your database, or read the Google Cloud SQL backup guide first.