Data sources

The databases Backup backs up — fields, network requirements, pausing, and exactly what deletion destroys.

A datasource represents one database connected to Backup. It holds the connection credentials, an environment tag, and a region, and it gets its schedule by having one or more backup policies attached.

What a datasource has

Field	What it does
Name	The label shown across the dashboard (`production-db`, `analytics-replica`). Renaming is cosmetic — it doesn't affect storage paths or job history — but note the delete confirmation asks you to type the current name.
Engine	PostgreSQL or MongoDB. Determines which dump tool runs (`pg_dump` / `mongodump`).
Environment	Development / Staging / Testing / Production. A filtering tag; no behavioural effect.
Region	Where backup workers run and managed storage lives. Currently EU Central 1 (Frankfurt).
Credentials	The connection string, stored KMS-encrypted — see Manage credentials.
Active flag	Master switch. When inactive, no scheduled backups run for this database, whatever policies are attached. Shown as the Active/Inactive badge on the detail page; toggled via the CLI or API.

The detail page also shows live operational fields: Active backup jobs (currently queued or running), Last backup and its size, Next backup (when the next scheduled run is due), and warning indicators in the list when a datasource is missing credentials or has no policy attached.

Network access

Backup connects to your database over the public internet from a single static egress IP: 18.196.207.101. Every backup worker comes from this address.

To make your database reachable:

Allow inbound connections on your database's port from 18.196.207.101 in your firewall / security group.
Use TLS — sslmode=require for Postgres, tls=true for Mongo. Backup honours the TLS settings encoded in your connection string.
Give the role only the read access pg_dump / mongodump needs — see read-only role snippets.

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.

Pause a datasource

Deactivating a datasource stops all scheduled backups for it without touching credentials, attachments, or existing backups. The dashboard shows the state (the Active badge); switching it is done from the CLI:

nrc snapdb datasource pause          # interactive picker
nrc snapdb datasource pause <id>
nrc snapdb datasource resume <id>

What pausing does — and doesn't do:

New scheduled jobs stop being enqueued from the next scheduler tick.
Jobs already queued or running still complete. Pausing is not a cancel button.
Retention keeps running. Old backups continue to age out under their policies. If you want to freeze the current backup set, that's not what pause does.
No catch-up on resume. Missed slots aren't backfilled; the next matching cron time fires normally.

To pause a single policy on a datasource instead of everything, see Pause and resume.

Delete a datasource

From the detail page: ⋯ → Delete datasource. This is the most destructive action in the product, and the dialog treats it that way — you must type the datasource's name to enable the delete button, and the request is refused while a backup is queued or running (wait for it to finish).

What gets removed — quoting the dialog: "All backup snapshots, restore history, PITR timelines, and policy attachments for this datasource. Stored backup files in our managed buckets are queued for deletion and removed within a minute. Org-wide backup policies and storage destinations are left in place — they're shared with your other datasources."

Two nuances worth spelling out:

Managed storage is cleaned up; BYO storage is not. Backup has no delete rights on your own buckets — archives written to a BYO destination stay there until you remove them yourself.
Job history goes with the datasource. If you're decommissioning a database but want the history, export it first (nrc snapdb backup list --datasource <id> --all-pages -o json).

The deletion is recorded in the audit log as datasource.deleted before the destructive work begins.

Every action is audited

Creating, updating, activating/deactivating, deleting, setting credentials, and every connection-test attempt writes an audit log entry (datasource.created, datasource.credentials_set, datasource.verify_attempted, …). Credentials never appear in audit metadata.

Connect a database — the three-step create flow.
Manage credentials — formats, rotation, read-only roles.
Test the connection — what the probe checks and every result code.