For online backups, mysqlbackup contacts the MySQL server to determine the keyring plugin the server is using, which, currently, is either one of keyring_file or keyring_okv (for offline backups, the --keyring option must be used to convey the same information to mysqlbackup). mysqlbackup also finds out from the server where to access the keyring (for offline backup, the --keyring_file_data or --keyring_okv_conf_dir option must be used to supply the same information). Once mysqlbackup has access to the keyring, it obtains the master key and uses it to decrypt the encrypted tablespace keys, which were used to encrypt the InnoDB tables on the server.

Using the user password supplied with the option --encrypt-password (users who do not want to supply the password on the command line or in a default file may use the option without specifying any value; mysqlbackup then asks the user to type in the password before the operation starts), mysqlbackup reencrypts the tablespace keys. For each encrypted table, the reencrypted tablespace key, together with other information, is stored into a transfer file (with the .bkt extension), which is saved into the backup.

Using the user password supplied with the option --encrypt-password, which should be the same password used for backing up the database (users who do not want to supply the password on the command line or in a default file may use the option without specifying any value; mysqlbackup then asks the user to type in the password before the operation starts), mysqlbackup decrypts the tablespace keys, which were encrypted using the password when the backup was performed earlier.

If the --generate-new-master-key option is used, mysqlbackup generates a new master key and uses it to reencrypt the tablespace keys. To use the --generate-new-master-key option, the --keyring option, as well as the --keyring_file_data option (when --keyring=keyring_file) or --keyring_okv_conf_dir option (when --keyring=keyring_okv) must be specified, so mysqlbackup can access the keyring and add the new master key to it.

$ mysqlbackup  --defaults-file=/usr/local/mysql/my.cnf  --backup-image=/home/admin/backups/my.mbi \
  --backup-dir=/home/admin/restore-tmp --encrypt-password="encryptpass" \ 
  --generate-new-master-key --keyring=keyring_file --keyring-file-data=path-to-keyring-file \
    copy-back-and-apply-log

The keyring parameters should then be supplied to the restored server.

If the --generate-new-master-key is not used, mysqlbackup assumes that the same keyring used on the server when it was backed up continues to be valid and is available to the restored server.

For MySQL 5.7.11 and earlier, backup for InnoDB tablespaces encrypted with “MySQL Enterprise Transparent Data Encryption (TDE)” is not supported by mysqlbackup. To perform a backup for those tables, upgrade the server to the latest MySQL 5.7 release, paying attention to any upgrade requirements explained in Changes in MySQL 5.7, especially the one regarding the --early-plugin-load option, and rotate the master key on the upgraded server using the ALTER INSTANCE ROTATE INNODB MASTER KEY statement. Proceed then with the backup process.

During a validate operation, if mysqlbackup encounters any encrypted InnoDB tables, it issues a warning and then skips over them.

For partial backups using transportable table spaces (that is, when the --use-tts option is used), encrypted InnoDB tables are never included in a backup. A warning is issued in the log file whenever an encrypted InnoDB table that matches the table selection criteria has been skipped over.

The --skip-unused-pages option has no effect on encrypted InnoDB tables during a backup (that is, empty pages for those tables are not skipped).