Hosted backups and drills
A database with no server of yours beside it, such as Supabase, Neon or RDS, can be backed up by SafeGrd. A surface with no host to drill it, such as one backed up from a GitHub Actions workflow, can be drilled by SafeGrd. Either way, SafeGrd starts a machine for that one job, gives it the one secret the job needs, and destroys it when the job ends.
Backup
- Your database read with a read-only role
- A machine for this backup dumps, compresses, encrypts
- Hosted storage locked under Object Lock
- Given
- the connection string, for this backup only
- Never given
- the key that decrypts backups
Fire Drill
- Hosted storage the newest snapshot
- A machine for this drill restores into a throwaway database
- A signed record every table counted
- Given
- the key, for the one snapshot it restores
- Never given
- the connection string
Back up a database with nothing to install
- Under Surfaces, choose Add surface, then Back up on SafeGrd.
- Name it, and pick what it is: PostgreSQL, MySQL or MariaDB, MongoDB, or a bucket.
- Paste the connection string. Test connection opens it from SafeGrd's server and says what failed when it cannot.
- Pick how often to back up and how long to keep each backup, then Add and back up now.
The first backup starts within a few minutes, so a wrong password shows up then and not on the first scheduled night. Its drill follows on your plan's schedule.
The database has to accept connections from the internet, and a read-only role is enough. Where SafeGrd's machines connect from fixed addresses, the console lists them beside Back up on SafeGrd, for a database whose firewall lists the addresses it accepts.
Supabase
Pick a Supabase project signs you in to Supabase and lists your projects, with the
session pooler's address filled in. You type the project's database password, which
Supabase does not give out. Without the sign-in, copy the Session pooler string (port 5432)
from Connect in Supabase's dashboard and add ?sslmode=require. The
transaction pooler on port 6543 cannot take a backup. A project's Storage is a bucket: add it
the same way with its endpoint and S3 key, and it is backed up as one archive of its objects
(details).
Each backup uploads what changed
A PostgreSQL backup reads every table and uploads only the rows that changed since the last one. The machine works that out from a cache of what storage already holds. SafeGrd keeps the cache encrypted between backups, under a key it gives only to that surface's backup machines.
What it costs at your provider
Every backup reads the whole database, and the provider may bill that as egress.
Price this schedule in the form measures the database and prices the
schedule at its provider before you add it. safegrd estimate
does the same from a terminal.
Drill a surface on SafeGrd
Set Drill on SafeGrd in a surface's panel. From then on, each time a drill is due, SafeGrd starts a machine for it, restores the newest snapshot, checks it as a host would, signs the record and destroys the machine. The Fire Drills tab shows that it ran on SafeGrd. A surface SafeGrd backs up is drilled this way from the start.
- Which surfaces. One whose backups are in hosted storage and whose key SafeGrd holds (a SafeGrd-managed key), since the machine has to decrypt the snapshot. The surface's panel says why when it is not offered.
- What it restores into. PostgreSQL, MySQL, MariaDB, MongoDB and SQLite go into a throwaway database of the same engine. Files and mailboxes are read back in memory. A PostgreSQL snapshot that needs an extension the plain image lacks, such as pgvector or a Supabase extension, drills on Supabase's own image, which has them.
- Your own checks. Drill checks written as queries run on SafeGrd's machine too. A check written as a command runs only on your own host.
Which machine gets which secret
Each job gets a token minted for it alone. The token reaches the routes that job's kind needs, for the one surface, and stops working at the job's deadline.
| Job | Given | Never given |
|---|---|---|
| Backup | The connection string or bucket key, the public key it encrypts to, and the key to the surface's repository cache. | The key that decrypts backups. |
| Fire Drill | The key for the snapshot it restores. | The connection string. |
Every release is written to the Key access record before it happens, with the job it went to and the time. Open it under Projects, Storage. Security and key custody covers how SafeGrd seals what it holds.
Minutes on SafeGrd
Each plan includes an amount of machine time over a rolling 30 days, and a largest snapshot for a sandbox drill:
| Plan | Runs on SafeGrd | Largest snapshot | At once |
|---|---|---|---|
| Free | 20 minutes a month | In memory, within the plan’s storage | 1 |
| Starter | 800 minutes a month | 5 GB | 1 |
| Growth | 2,500 minutes a month | 8 GB | 2 |
| Scale | 8,000 minutes a month | 25 GB | 4 |
A job counts the time its machine ran, from when SafeGrd asked for the machine to when the job ended, or 10 minutes for each GB it moved when that is more. A drill of a 2 GB snapshot whose machine runs for 6 minutes counts 20 minutes. A backup of a 300 MB database that runs for 3 minutes counts 3. Fractions of a minute count, and there is no minimum.
- While a job runs, it counts as the most it can use: 10 minutes for each GB of its snapshot. A first backup, whose size is not known yet, counts as the largest snapshot your plan drills. The total in the console drops to what the job used when it ends.
- A stalled job ends at its deadline: 5 minutes, plus 5 for each GB of the snapshot.
- Past the plan's amount, the next run waits until enough of the 30 days has rolled off, and the console says when.
- A snapshot larger than the sandbox limit is refused before anything is
downloaded. Drill it on one of your hosts with
drill.sandbox_urlinstead. - Drills on your own hosts are never counted.