Data sources
The databases Backup backs up.
A data source represents one database connected to Backup. Each data source has its own credentials, an environment tag, and a region, and is attached to one or more backup policies to schedule runs.
What a data source has
- A name – a label that appears across the dashboard. Pick something
recognisable like
production-db,analytics-replica,staging-postgres. - An engine – PostgreSQL or MongoDB. Determines which tool runs
(
pg_dumpormongodump). - An environment – production / staging / dev / test. Used for filtering. Doesn't affect behaviour today.
- A region – the AWS region where backups are stored. Pick the one closest to your database to minimise transfer time and cost.
- Credentials – stored KMS-encrypted (see Encryption and security).
- An active flag – a master kill-switch. Disabling it pauses every scheduled backup for this database without losing config.
Network access
Backup connects to your database over the public internet from a single
static egress IP: 18.196.207.101. Every backup worker, regardless of
when it runs, comes from this same address – the workers are routed
through a managed NAT, so the IP is stable.
To make your database reachable:
- Allow inbound connections on your database's port from
18.196.207.101in your firewall / security group. - Use TLS –
sslmode=requirefor Postgres,tls=truefor Mongo. Backup honours TLS settings encoded in your connection string. - Use strong credentials. The role you provide should have no more
permissions than
pg_dump/mongodumpneeds (read everything you want backed up).
If 18.196.207.101 ever changes, the new value will be listed at
status.norcube.com in advance.
Private connectivity (PrivateLink, VPC peering, SSH tunnels) is not supported today. If your database is in a private VPC, expose it via a NAT-routed public endpoint with the IP allowlist above, or reach out via the dashboard about enterprise connectivity.
Behaviour and edge cases
- Disabling a data source stops new scheduled runs immediately. Any job already in flight finishes; queued jobs are cancelled.
- Deleting a data source is permanent. It cascades to every policy attachment, every backup job record, and (asynchronously) every backup file in S3 for that data source – managed and BYO destinations alike. The dashboard surfaces a destructive confirmation dialog that requires you to retype the data source name.
- Backup file cleanup after delete. S3 objects are queued for deletion when you delete a data source. The cleanup worker processes the queue within a few hours; partial uploads still in progress are aborted via S3's multipart timeout.
- Renaming a data source is cosmetic – it doesn't affect S3 paths or job history.
- Every mutating action is audited. Creating, updating, deactivating, deleting, setting credentials, verifying – each produces an audit log entry.