The two backup mechanisms, why a restore always creates a new resource, and what a self-built dump can be restored into.
Backups and restore
Backups covers the database resources this platform can back up, in two different ways.
Two mechanisms
Cloud snapshot wraps the provider's own managed snapshot — RDS and ElastiCache snapshots, Atlas Cloud Backup. Nothing leaves the provider, and restoring goes through the provider's own restore.
System dump runs pg_dump, mongodump or mysqldump against the database itself and uploads
the artifact to an S3 bucket in an AWS connection you choose. It is the only option for a
self-hosted server, and it is available as an alternative for RDS instances and Atlas clusters.
For a managed resource the platform holds the provider's API credential, never a database login — so a system dump asks you for the database host, port, username and password at the moment you trigger it. Those are used for that dump and are not stored.
A recurring schedule cannot prompt, so a schedule on a managed resource instead references an already-registered self-hosted connection and resolves the login from it when it fires. The schedule itself never holds a password.
Where a resource supports both mechanisms they are two tabs, each with its own "Back up now" — one button does one thing. The Cloud snapshot tab additionally reports what the provider is already doing automatically (retention window, backup window, continuous backup / PITR flags), so you can see the existing posture before deciding whether a manual snapshot adds anything.
Restore always creates a new resource
A restore never overwrites the source in place — on either mechanism, for every provider. It provisions a new resource and tracks it, leaving the original exactly as it was.
That is a deliberate divergence from how most backup tooling behaves, and it is the reason a restore is safe to attempt while you are still working out what went wrong.
Restoring into a Production environment requires an admin. It does not use the two-person pipeline approval — that stays scoped to pipeline runs.
What a dump can be restored into
Cloud snapshots and system dumps are not interchangeable, because the provider's restore only understands the provider's own snapshot id:
A cloud snapshot restores through its own provider.
A system dump — whether it came from a self-hosted server or from an ad-hoc dump of an RDS instance or Atlas cluster — restores only into a registered self-hosted database server.
The restore form enforces this rather than letting it fail halfway through.
Self-hosted servers
A PostgreSQL, MongoDB or MySQL server with no provider snapshot API is registered from Backups itself. Registration is one atomic action: it creates the connection, verifies the server is reachable, and tracks the resource. One registered server can host many named databases, discovered live rather than recorded once — so a database added later appears without re-registering anything. The service can connect directly, through an SSH tunnel, or by running the dump and restore tools on the remote machine over SSH.