Back up Amazon RDS & Aurora, and prove it restores
Restore-tested logical backups of your Amazon RDS or Aurora PostgreSQL, written to storage you control. Connect by the endpoint with a read-only role, 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 RDS
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 RDS, 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 RDS, step by step
The RDS-specific settings, from the connection string to network access. Everything after that is the standard Protect form: schedule, retention and restore testing.
Copy the endpoint
In the RDS console, open Databases, select your instance or cluster, and copy the Endpoint from the Connectivity & security tab. Always connect by this DNS name, never a raw IP, because the IP changes on failover. For Aurora, use the reader endpoint so dumps run off a replica.
Create a read-only role
Create a dedicated role, for example
norcube_backup, withCONNECT, schemaUSAGEandSELECTon your tables. Use password authentication, not IAM database authentication, whose tokens expire after 15 minutes.Make the instance reachable
Set Public access to Yes, make sure the DB subnet group uses public subnets with a route to an internet gateway, and enable DNS hostnames and DNS resolution on the VPC.
Allow Norcube in the security group
Add an inbound rule to the instance's VPC security group: type PostgreSQL (TCP 5432), source
18.196.207.101/32. Don't use0.0.0.0/0.Paste it into Norcube with SSL required
Choose Protect a database, pick PostgreSQL and enter the endpoint, port
5432, database and the read-only role. RDS for PostgreSQL 15+ forces SSL, so set SSL mode torequire.
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.
RDS backups, answered
The questions that come up when backing up Amazon RDS & Aurora. The full guide is in the docs.
Should I use IAM database authentication?
Do I need the RDS CA bundle?
require, which encrypts the connection without it. Only verify-ca and verify-full need the CA file.Why does a restore test mention aws_s3 or other AWS extensions?
aws_s3, aws_commons, rds_tools and pg_transport, plus Aurora-only ones like aws_lambda and apg_plan_mgmt. They don't exist in community Postgres and AWS recreates them on any instance, so a restore test notes their absence as expected and still records a clean Passed. Ordinary extensions like postgis or pgvector restore normally.Which Aurora endpoint should Norcube use?
Your RDS data, backed up and tested
Start on the Free plan. No credit card required. Connect RDS, pick a schedule and let the first restore test prove it.
- Free plan
- No credit card
- Standard formats
- Restore-tested