MySQL and MariaDB

SafeGrd backs up MySQL 8.0 and 8.4 and MariaDB 10.6 and 11.4 with mysqldump. This page covers the grants the backup account needs, TLS options, restoring, and Amazon RDS and Aurora.

MySQL surfaces run mysqldump (or mariadb-dump) with --single-transaction, which reads InnoDB tables from one consistent snapshot without locking them. Backups include stored routines, triggers and events, with binary columns written as hex. The output streams into the encrypted archive as it is produced. Row counts are read from the dump stream itself, so they match the rows in the backup even while the database is being written to.

• The host needs the MySQL client (mysql-client, or brew install mysql-client on macOS). SafeGrd prefers the dump tool from the same project as the server, and MySQL's client has been tested against MariaDB 11.4 as well. SAFEGRD_MYSQLDUMP and SAFEGRD_MYSQL name them explicitly.
• A backup account needs SELECT, SHOW VIEW, TRIGGER and LOCK TABLES on the database. Add EVENT on it to back up scheduled events, and SHOW_ROUTINE ON *.* (MySQL 8.0.20 or newer) to back up stored procedures and functions other accounts created. Without them the backup runs, and says what it left out.
• The password goes to the client in a private, owner-only options file that is deleted when the run ends, never on its command line.
• TLS: ?tls=true encrypts and checks the server's certificate against the system's certificate authorities. MySQL's own certificate is self-signed and fails that check, so for a server that still uses it add ?tls=skip-verify, which encrypts without checking, or ?ssl-ca=/path/ca.pem to check it against your own CA. ?tls=preferred uses TLS when the server offers it. A database SafeGrd backs up for you has no file for ssl-ca to name, so use tls=true or tls=skip-verify there.
• ssl-mode, as mysql takes it and as Aiven's URIs carry it, works in place of tls: REQUIRED is tls=skip-verify, VERIFY_CA and VERIFY_IDENTITY are tls=true, and PREFERRED and DISABLED are tls=preferred and tls=false. A URL that sets both, differently, is refused.
• Restoring requires an empty target database and validates every table's restored row count against the snapshot manifest. Because MySQL applies DDL statements non-transactionally, a failed restore can leave partial schemas behind; drop and recreate the database before retrying.
• Database objects such as views, triggers, and stored routines preserve their original definer accounts. Recreating an arbitrary definer requires SET_USER_ID privileges, which managed platforms like RDS do not grant. During restoration, SafeGrd rewrites object definers to match the restoring account and reports the number of modified definitions.
• Rows up to the source server's max_allowed_packet are backed up whole. Set max_allowed_packet on the restore target at least as high as on the source.
• Triggers created via multi-statement APIs may contain trailing semicolons that mysqldump exports in an invalid format. SafeGrd identifies affected triggers during backup, and sandbox drills will flag them since in-memory drills do not parse SQL syntax.

Amazon RDS and Aurora (MySQL)

Managed MySQL on RDS does not grant SUPER privileges, but SafeGrd does not need them.

• SafeGrd runs mysqldump with --single-transaction and --set-gtid-purged=OFF, which works with standard user privileges.
• During a restore, SafeGrd rewrites object definers (e.g. % or admin@%) to the restoring account so RDS does not reject them.
• Backing up from an Aurora or RDS Read Replica keeps table scans off your write master.