The daemon reads a database, a directory or a mailbox, encrypts it on the host, writes it to a bucket under Object Lock, and restores it on a schedule to check what came back. Pick the row that matches your setup; each page has the connection details, the role to create and the restore command for that platform.
PostgreSQL 13 and later. Schema from pg_dump, rows over binary COPY, from one snapshot. Each backup uploads only what changed. Restores into an empty database, or one schema into a running one.
One mysqldump archive per backup under a single transaction, checked on every drill, and loaded into a throwaway server on a sandbox drill with every table's row count checked.
A mongodump archive of every database the role can read, Atlas included, drilled by restoring into mongod and counting documents per collection.
A consistent copy through the backup API, so a file an application is writing to still backs up whole. Incremental, like a directory.
Any directory tree. The first run of a month uploads every file once; each run after it uploads what changed. Every version of every file is kept and restores on its own.
A platform with a server you can log in to runs the daemon there. A managed database with no server beside it is backed up from a GitHub Actions workflow, or by a machine SafeGrd starts for each backup from the connection string.
Through the session pooler on port 5432, with auth and storage included. Restored into Supabase's own PostgreSQL image to test it, since a project cannot take a restore.
The direct endpoint, not the pooler. A copy outside the project that does not count against Neon's restore window or its branch limit.
The daemon as a service on the private network, so the dump costs no egress, or a backup through the TCP proxy from outside, for the copy that survives the project.
Over the external URL with TLS, from a workflow or from SafeGrd's machines, for a backup that outlasts the workspace plan's recovery window.
The daemon as a Fly Machine on the same private network as the database, for Fly Postgres and Managed Postgres alike.
Managed Databases from a droplet in the VPC or over the public host, and Spaces as a sink with the lock turned off, since Spaces has no Object Lock.
A PostgreSQL on a Hetzner server, written to Hetzner Object Storage under Object Lock in the same region, so the backup never leaves Germany or Finland.
The container beside the databases Coolify runs, with the internal URL from the database's page. Runs alongside Coolify's own backups.
From a host inside the VPC, pointed at a read replica, with Amazon's certificate bundle for verify-full.
Backups are written under S3 Object Lock in compliance mode, so the bucket refuses to delete them before their date, for anyone. A bucket with no Object Lock works with the lock turned off, stated in the config, and the console says so on every backup written there.
Object Lock in compliance mode, a bucket policy that lets the host write and never delete, and a CloudFormation template the console writes for your bucket's name.
S3-compatible with no egress fees. Check Object Lock support for your bucket before relying on it; without it, the lock-off mode applies.
Both support Object Lock in compliance mode. Wasabi charges no egress.
Object Lock in compliance or governance mode, enabled when the bucket is made, in Falkenstein, Nuremberg or Helsinki.
Self-hosted, with real Object Lock in distributed mode. For a bucket on your own network.
A bucket SafeGrd runs, locked in compliance mode, for a team that does not want to make one. safegrd export copies every snapshot to a bucket of your own, still encrypted, whenever you want.
curl -fsSL https://safegrd.dev/install.sh | sh installs the binary and a systemd unit or launchd job, or brew install safegrd/tap/safegrd.
The ghcr.io/safegrd/cli image carries pg_dump 18, the MariaDB client and the MongoDB tools. The Helm chart runs it beside the database.
safegrd/backup-action backs up a database the runner can reach, on a schedule, with the config in a repository secret: the host for a database with no server.
Email, Slack, Discord and a webhook, when a backup fails, runs late, or a drill does not pass. A badge for the README that turns amber when the last passed drill is more than 3 days old, and red after 7 or when a drill fails.
An MCP server so Claude, Cursor or any agent can ask which backups passed their last drill, and a REST API with an OpenAPI description.
Tell us what you run. A database engine, a platform or a bucket we do not list is a request, and the ones asked for most are built next.