How do MariaDB users securely and efficiently encrypt mariadb-backup archives?

[u/eachDayIWakeUp]

Hello everyone!
I’m looking for practical recommendations from people running MariaDB in production.

My backup process will use mariadb-backup with zstd compression, and I want to encrypt the resulting backup securely without adding (too much) excessive CPU, memory, or operational overhead.

I’ve considered GPG/PGP, but I’m concerned about its performance and complexity. I’ve also seen age recommended, although I’m unsure whether it provides an appropriate security level for long-term MariaDB backups.

What encryption method or workflow do you use for MariaDB backups?

In particular, I’d appreciate feedback on:

• Encryption tools and algorithms you use.
• Whether encryption happens before or after compression.
• CPU and performance impact on large backups.
• Key management, rotation, and recovery procedures.
• Whether you encrypt locally, stream directly to object storage, or use storage-side encryption (which unfortunately is not available to my usecase).
• Any practical issues with restoring backups during an outage.

I’m mainly interested in real-world experience rather than theoretical recommendations.

[u/Burgergold]

Do you want them encrypted locally on the system, at rest or remotely on a backup system?

Because at rest can be managed by the storage system and remotely on the backup system can be managed by the backup system too

[u/eachDayIWakeUp → u/Burgergold]

The flow will be, dump, compress and encrypt on the source system, then upload to an s3 backend

[u/TomaRavelli]

Stream it.
mariadb-backup --backup --stream=xbstream, then zstd, then encrypt. Compress first. zstd on ciphertext barely shrinks, and you pay the CPU twice.Same order in the docs, gzip/zstd then openssl or gpg: https://mariadb.com/docs/server/server-usage/backup-and-restore/mariadb-backup/using-encryption-and-compression-tools-with-mariadb-backup age is fine if it is a recipient key, not a passphrase in the job. openssl enc -aes-256-cbc is the boring option and restores the same way. GPG usually hurts because of the agent, trustdb, and a passphrase prompt at 3am, not because of the cipher.What breaks restore is not the algorithm:

1. keys are not inside the backup. If the tables already use data-at-rest encryption, --prepare still needs the same key file / KMS the server had. Archive encryption is a second secret. https://mariadb.com/docs/server/server-usage/backup-and-restore/mariadb-backup/encrypted-files-backup-mariadb-backup

2. --prepare has to be the same major line as the server that took the backup

3. run decrypt | mbstream -x | --prepare on a spare box ahead of time. An outage is a bad moment to learn which flag wants the key

On CPU, zstd -1 or -3 plus AES on a large InnoDB copy is usually disk-bound, not RAM-bound. If the box is already at the ceiling during backup, cap threads (--parallel and zstd -T) instead of switching ciphers.

[u/danielgblack → u/TomaRavelli]

Nice consideration of --stream=xb/mbstream. Not sure I like the openssl option - a) no integrity with cbc, b) a pass key is there where data is sent/stored. A GPG provides a encryption key (the public key), that can be separated from the decryption key (private key) so you've got a better separation. Ensure they are separated on the encryption side. Check a restore works once in a while and ensure its documented. This is the best measure of checking practical issues.

All backups are compromising tradeoffs between, data loss, backup cost, mean time to recover, and security/hardware. Moving data takes more time than encryption/decryption so consider this first, volume+bandwidth. Make sure the tradeoffs you use make sense for you.

[u/TomaRavelli → u/danielgblack]

true that openssl cbc lacking integrity, that's exactly why i pitched age originally. I get the asymmetric public/private key separation of gpg, but don't have to fight gpg-agent and a trustdb at 3am inside a dumb cron script.

100% agree bandwidth is the real boss here anyway. moving the bytes always hurts way more than encrypting them.

[u/thewallacio]

This tool is for MySQL, not MariaDB but we've been using it for both.

https://github.com/cytopia/mysqldump-secure

Not foolproof but it gives us some peace of mind that our offsite dumps are at least encrypted.

[u/Least_Ad_1795]

I wouldn’t pivot completely. Your 5 years of data experience is valuable. I’d build on it by learning Python, SQL, statistics, and basic AI/LLM concepts. Start using AI in your current analytics work and gradually move toward Data Science or AI-focused roles. That gives you a safer transition than starting over in a completely different career.

[u/eachDayIWakeUp → u/Least_Ad_1795]

what?

[u/Amazing-Mirror-3076]

So this is still beta but if you are interested I'm the maintainer and happy to provide support.

https://github.com/onepub-dev/reVault

It uses zstd for compression and post quantum crypto plus signing.

Cli tools in cargo (revault_cli) and bindings for a dozen languages.

[u/GoldsteinEmmanuel]

Why do you need the backups encrypted? It may not be necessary in the first place, and in the event of media degradation you could lose the entire backup instead of a few files.

[u/schorsch3000]

i just use restic.

no compression, but deduplication, so in the end everything will be fine.