Back up Google Cloud SQL, and prove it restores
Restore-tested backups of your Google Cloud SQL for PostgreSQL, written to storage you control. Enable a public IP, authorize one address, and every backup can prove it restores.
- Spin up a throwaway database
- Restore the backup
- Check the data came back 48 of 48 tables
- Delete the throwaway database
A second copy, outside Cloud SQL
An off-site backup is the one you can still reach when something goes wrong with the platform or the account. Norcube keeps it outside Cloud SQL, in storage you control, and proves it restores.
Off-site, in storage you control
Norcube runs a full pg_dump on your schedule and writes the encrypted archive to Norcube-managed storage in Frankfurt or to your own S3-compatible bucket.
Proven to restore
Every backup can be restore-tested: Norcube restores it into a throwaway database and confirms your schemas, tables and rows come back.
Yours, in a standard format
Download any backup and restore it with standard Postgres tools, independent of Norcube. No proprietary format, no lock-in.
Connect Cloud SQL, step by step
The Cloud SQL-specific settings, from the connection string to network access. Everything after that is the standard Protect form: schedule, retention and restore testing.
Enable a public IP
In the Google Cloud console, open your Cloud SQL instance, go to Connections → Networking, check Public IP and save. The address shows on the instance Overview page.
Authorize Norcube's address
Under Authorized networks, choose Add a network and enter
18.196.207.101/32. Cloud SQL requires CIDR notation and doesn't support IPv6 authorized networks.Create a read-only user
Add a user with Built-in authentication, then a read-only role, for example
GRANT pg_read_all_data TO backup_roon Postgres 14+. Password auth is simpler than IAM auth, whose tokens expire hourly.Set the SSL mode
Under Connections → Security, choose Allow only SSL connections. Don't choose Require trusted client certificates: a backup connection doesn't present a client certificate, so it would be blocked.
Paste it into Norcube with SSL required
Choose Protect a database, pick PostgreSQL and enter the public IP, port
5432, database and the read-only user, with SSL moderequire.
What Norcube adds
Restore testing
Prove each backup restores, not just that the dump ran. A Passed badge per backup and a restore-health score per database show recoverability at a glance.
Failure and missed-backup alerts
Get notified when a backup fails, a restore test can't confirm your data, or a schedule silently stops. By email, Slack or a signed webhook, on every plan.
Your own bucket
Keep backups in Norcube-managed storage in Frankfurt, or in your own Amazon S3, Cloudflare R2, Backblaze B2, Wasabi or MinIO bucket.
Standard archives
Every backup is a standard pg_dump archive, gzip-compressed by default. Download it any time.
Cloud SQL backups, answered
The questions that come up when backing up Google Cloud SQL. The full guide is in the docs.
Why not the Cloud SQL Auth Proxy?
Which SSL setting should the instance use?
Why does a restore test mention google_ extensions?
google_ prefix, such as google_ml_integration. They don't exist in community Postgres, so a restore test notes their absence as expected and still records a clean Passed. Community extensions like postgis or pgvector restore normally.Can I authorize an IPv6 address?
18.196.207.101/32 is the only correct entry.Your Cloud SQL data, backed up and tested
Start on the Free plan. No credit card required. Connect Cloud SQL, pick a schedule and let the first restore test prove it.
- Free plan
- No credit card
- Standard formats
- Restore-tested