xbackupman
Guides / Google Cloud SQL

Back up Google Cloud SQL.

Google Cloud SQL runs PostgreSQL, MySQL with standard connectivity — which means encrypted, verified, off-platform backups take a connection string and three minutes.

Find your connection details

Cloud SQL → your instance → Overview → Connect. Either allowlist the worker IP for the public address, or run the Auth Proxy.

# host looks like:
34.89.12.34 (public IP) or via Cloud SQL Auth Proxy

The manual way

PostgreSQL (port 5432):

pg_dump -h 34.89.12.34 -U USER mydb | gzip > backup.sql.gz

MySQL (port 3306):

mysqldump -h 34.89.12.34 -u USER --single-transaction mydb | gzip > backup.sql.gz

One-shot and unencrypted. Scheduling, encryption, retention, verification and alerting are still on you — that's the part xbackupman automates.

The automated way

  1. 1. Add your Google Cloud SQL connection — the same host, user and password, encrypted at rest.
  2. 2. Point backups at storage you own (S3, R2, B2, MinIO, Drive…).
  3. 3. Pick a schedule — down to every 5 minutes; unchanged runs dedup to pointers.
Automate it free →PostgreSQL backups

FAQ

Does xbackupman support Google Cloud SQL?

Yes — Google Cloud SQL exposes standard PostgreSQL, MySQL connectivity, and xbackupman connects with the same credentials you use anywhere else. No special integration or agent is needed on the provider's side.

Are Google Cloud SQL backups encrypted?

Every dump is encrypted with AES-256-GCM using your organization's key before it leaves the worker, then stored in S3-compatible storage you own. Google Cloud SQL (and your storage provider) only ever see ciphertext.

Doesn't Google Cloud SQL already take backups?

Provider snapshots live inside the same account and platform as the database — one compromised credential or billing lapse can take both. Independent, encrypted, restore-verified copies in storage you control are what off-platform backups are for.

← All backup guides