A backup is a complete copy of your most sensitive data. SQLBackup treats it that way — authenticated AES-256 encryption applied client-side, with keys that never leave your control.
Your compressed dump is encrypted in 64 KB chunks. Each chunk gets a fresh random nonce and authenticates its own index as associated data — so chunks can't be reordered, dropped, or swapped between files without the decrypt failing.
Your password becomes a 256-bit key via scrypt (n=2¹⁴, r=8, p=1) with a random per-file salt — slow to brute-force by design.
GCM tags detect any tampering or corruption. A modified backup doesn't silently restore garbage — it refuses to decrypt.
Chunked design means a 2 GB or 200 GB backup encrypts with the same tiny, constant memory footprint.
Clear about what's covered — and honest about what's still on you.
If your S3 bucket or SFTP server is compromised, attackers get ciphertext only. Without your password-derived key, it's useless.
Backups are already encrypted at the application layer before transfer, so a tapped connection still only sees opaque bytes.
GCM authentication means an altered or truncated backup fails loudly on restore instead of quietly corrupting your data.
There's no SQLBackup server. Nothing phones home. We can't read your data because it never touches us.
Reference passwords by environment-variable name. Credentials and the encryption key stay out of config.yaml.
If you lose your encryption password, the backup is unrecoverable — by design. Store it in a password manager or secrets vault.
AES-256-GCM and scrypt from a mature, audited cryptography library — no home-rolled algorithms.
The encryption format is fully documented, so your backups are never locked into a black box — they can always be opened and restored.
No analytics, no accounts, no callbacks. The only network traffic is to your own databases and storage.
The encryption password is yours alone. We have no master key, no recovery backdoor, no copy.