Set it once. Sleep well. Restore in minutes.

SQLBackup turns a fragile pile of cron scripts into one dependable agent. Here's the whole flow — and you can play with it right on this page.

STEP 01

Add your databases

Tell SQLBackup how to reach each database. Run a one-click connection test. Keep passwords in environment variables, never in the config file.

5 enginesTest firstEnv secrets
STEP 02

Define jobs

A job ties a database to one or more destinations, a cron schedule, a backup type, and retention rules. Toggle compression and encryption per job.

CronTypeRetention
STEP 03

Run the agent

Start SQLBackup and it runs continuously — firing each job on schedule, shipping offsite, pruning old copies, logging every result, and emailing you if anything fails.

ContinuousAlertsHistory

What happens inside a single backup

Click each stage. Every backup streams through these four steps — nothing is ever fully loaded into memory.

1 · Dump
native tools
2 · Compress
streaming gzip
3 · Encrypt
AES-256-GCM
4 · Ship
local · S3 · SFTP
Stage 1 — Dump with native tools

SQLBackup never reinvents the export. It calls each engine's own, vendor-blessed dump tool and streams the output straight into the pipeline — no giant temp file loaded into memory.

# PostgreSQL — exactly what the vendor ships
pg_dump --format=custom --no-owner \
  --dbname=analytics \
  | sqlbackup stream
Stage 2 — Streaming gzip compression

The dump is compressed on the fly with streaming gzip. A 2.4 GB database often shrinks by 70–80%, so you store and transfer a fraction of the bytes — and it never has to fit in RAM.

# streamed, chunk by chunk
analytics.dump    analytics.dump.gz
2.41 GB    612 MB  (75% smaller)
Stage 3 — AES-256-GCM encryption

Before a single byte leaves your machine it's encrypted with authenticated AES-256-GCM. The key is derived from your password with scrypt and a random salt; every 64 KB chunk gets a fresh nonce and authenticates its own position.

# on-disk format
MAGIC(9) | SALT(16) |
  [ LEN(4) | NONCE(12) | CT+TAG ]×N
Stage 4 — Ship offsite & apply retention

The encrypted, compressed backup is uploaded to every destination you configured — local/NAS, Amazon S3, S3-compatible clouds, or SFTP — then retention prunes old copies per destination. The result is recorded in the history log.

# fan-out to multiple destinations
 local      keep_last: 7
 amazon_s3  keep_days: 30
 sftp       keep_last: 14

Build a backup job — live

Make a few choices and watch the backup job take shape — exactly the summary the app shows you before it runs. No install required.

PostgreSQL MySQL MariaDB SQL Server MongoDB
Local / NAS Amazon S3 Wasabi SFTP
Nightly 2 AM Hourly Every 30 min Weekly Sun
Compress (gzip) Encrypt (AES-256)
7 14 30 90
Step 4 Review — nothing has happened yet
Databaseprod_postgresPostgreSQL · localhost:5432 · app
DestinationAmazon S3your own bucket
ScheduleDaily at 02:00Today 02:00 · Tomorrow 02:00 · +2 days 02:00
OptionsCompressEncrypt (AES-256)
RetentionKeep the last 14 backupsolder copies are pruned automatically
Save & Run Now

This is the job the app would create. The wizard asks these same four questions, then the agent runs it on schedule — nothing to write by hand.

The part that actually matters

A backup you can't restore is just wasted disk. With SQLBackup, recovery is one command — here's every step it runs.

Restore: analytics
from Amazon S3
Locate backupfind the key in the destination
Downloadpull the encrypted object
Decrypt & verifyAES-256-GCM authentication
Decompressrestore the original dump
Restore databasecreated if missing, then rebuilt as analytics_restored

One command does all of it

No juggling openssl, gunzip and psql by hand at the worst possible moment. SQLBackup runs the whole chain and restores into a database you name — and if that name doesn't exist yet it is created for you, so you can verify before promoting it. Replacing a live database asks you to type its name first.

# restore one stored backup into a database sqlbackup restore --job pg_nightly_full \ --from amazon_s3 \ --key pg_nightly_full/analytics/2026-06-27/analytics_full_02-00-14-317.dump.gz.enc \ --database analytics_restored

Chain-aware: point it at any incremental or differential and it restores the base full backup plus every change file in between, in order — you never assemble a chain by hand. Tip: practice restores on a schedule. An untested backup isn't a backup yet.

Ready to set it and forget it?

Install SQLBackup, add a job, and your databases are protected by tonight.

Start free trial Read the Docs