Encryption at rest in MariaDB secures data files by transparently encrypting tablespaces, logs, and backups using server-side keys.
Encryption at rest protects the physical files that store your databases—tablespaces, binary logs, temporary files, and backups—so stolen disks or snapshots reveal nothing readable.
Set encryption user variables in my.cnf
, restart the server, then issue ALTER INSTANCE
statements to encrypt existing tablespaces. This secures every new InnoDB table by default.
[mysqld]
plugin_load_add=file_key_management
file_key_management_filename=/etc/mysql/keys.enc
file_key_management_encryption_algorithm=AES_CBC
innodb_encrypt_tables=ON
innodb_encrypt_log=ON
innodb_temp_tablespace_encrypt=ON
Use CREATE TABLE ... ENCRYPTION='Y'
or ALTER TABLE ...
. This lets you encrypt sensitive objects—e.g., Customers
—without the overhead on read-only reference data.
Yes. MariaDB supports online key rotation. ALTER INSTANCE ROTATE INNODB MASTER KEY;
re-encrypts all tablespaces in the background while keeping the database available.
Store key files on a different mount, restrict file permissions (chmod 600
), back up keys separately, test restores regularly, and monitor the information_schema.INNODB_TABLESPACES_ENCRYPTION
view for lagging pages.
Query INFORMATION_SCHEMA.INNODB_TABLESPACES_ENCRYPTION
for the table’s space_id or check PAGE_TYPE
in innodb_space
if installed. The ENCRYPTION_SCHEME
column should show 1
.
Encrypt Orders
and OrderItems
while leaving catalog tables unencrypted to minimize CPU load.
ALTER TABLE Orders ENCRYPTION='Y', ENCRYPTION_KEY_ID=5;
ALTER TABLE OrderItems ENCRYPTION='Y', ENCRYPTION_KEY_ID=5;
Logical backups (mysqldump, mysqlpump) remain in plaintext unless used with --routines --events --triggers
. Physical backups with MariaDB Backup preserve encryption; keep the keyring file with the backup to allow restores.
PCI-DSS compliance, GDPR protection of personal data in Customers
, regulatory separation of production vs. staging, and safe use of cloud block storage.
CPU cost is usually < 5 % with AES-NI capable processors. IO patterns are unchanged, but backup and restore times rise because of additional crypto operations.
1. Forgetting to load the key management plugin. Without plugin_load_add=file_key_management
, encryption statements fail silently. Always confirm with SHOW PLUGINS
.
2. Storing keys on the same disk as data files. If the disk is lost, attackers get both data and keys. Keep keyring on a separate, access-restricted volume or use HashiCorp Vault/KMS.
MariaDB docs: Encryption Overview, Key Management.HashiCorp Vault plugin.MariaDB Backup user guide for encrypted instances.
With modern CPUs supporting AES-NI, the overhead is typically under 5 %. Disk IO patterns remain identical, so most workloads see negligible impact.
MariaDB encrypts at the page level; you cannot encrypt individual columns. Instead, place sensitive data in a dedicated table and encrypt that table.
No. Schedule ALTER INSTANCE ROTATE INNODB MASTER KEY;
periodically via cron or an orchestrator, then monitor INNODB_TABLESPACES_ENCRYPTION
until KEY_ROTATION
is complete.