SafeGrd / Coolify backup

Coolify database backups, encrypted, locked and restored

Coolify runs your databases as containers on a server you own, and its scheduled backups copy them to S3. Coolify's own documentation adds that a backup is not a restore test. SafeGrd runs on the same server and covers the rest: it encrypts each backup before upload, locks it with S3 Object Lock, and restores it on a schedule to check every table and row.

Run your first Fire Drill Read the install guide

What each tool does

Feature	SafeGrd	Coolify backups
Scheduled backups to S3-compatible storage	Yes	Yes
Encrypted on the server before upload	Yes	No
Every backup written under Object Lock	Yes	No
Scheduled restore tests, with row counts checked	Yes	No
Daily, weekly and monthly copies kept longer	Yes	Count, age and size limits
Alerts when a backup fails or runs late	Yes	Notifications
Restore	`safegrd restore` on any host	From the dashboard
ClickHouse	No	Yes

Running both works well. Coolify's backups give a one-click restore from its dashboard, and SafeGrd keeps a locked, tested copy that someone with access to the Coolify server cannot delete early.

Setting it up on a Coolify server

Install SafeGrd on the server. Either run the install script over SSH, or run the ghcr.io/safegrd/cli image, which carries pg_dump 18, the MariaDB client, the MongoDB tools and a PostgreSQL server for sandbox drills.
Give it a path to the database. A container on the same Docker network as the database uses the internal URL Coolify shows on the database's page. The install script on the host needs the database's port published to the server.
Add the database as a surface in the SafeGrd console, with a read-only role, and pick a bucket that supports Object Lock or SafeGrd's hosted storage.
Let the drills run. The daemon restores the newest backup into a throwaway database on the server, checks it, and signs the result.

docker run --rm -it -v safegrd:/home/safegrd/.safegrd ghcr.io/safegrd/cli enroll

How to restore

Create an empty database, on the Coolify server or anywhere else, and point the restore at it from a host that has the CLI, the engine's client tools and the key.

safegrd restore --snapshot SNAPSHOT_ID --target "postgres://user:pass@host:5432/recovered"

The same command takes a mysql://, mariadb:// or mongodb:// URL for those databases, and --target-dir for a directory such as an uploads volume. The target has to be empty: the restore refuses a database that already holds tables, so it never writes over data.

Check the tables and row counts it prints, then point the application at the new database (Restore and Fire Drills).

Questions

Which Coolify databases does it cover?

PostgreSQL, MySQL, MariaDB and MongoDB, and SQLite files on the server. It also backs up directories, such as an application's uploads volume, and IMAP mailboxes under the same key.

What happens to the backups if the server is lost?

They are in the bucket, not on the server. With a SafeGrd-managed key, SafeGrd keeps your key sealed and releases it only to your enrolled hosts, so you can restore even after losing a host. With a customer-managed key, only you can decrypt these backups, so keep a copy of the key file somewhere off the server.

Does the drill load the production database?

The drill reads from storage, not from the database, and restores into a separate throwaway database. The only load on the production database is the backup itself, which reads it once.

Coolify details come from its documentation.