Backing up Percona Server for MySQL with keyring_vault plugin enabled

Backing up Percona Server for MySQL with keyring_vault plugin enabled

PREVIOUS POST
NEXT POST

Percona XtraBackup with keyring_vaultTo use Percona XtraBackup with keyring_vault plugin enabled you need to take some special measures to secure a working backup. This post addresses how to backup Percona Server for MySQL with keyring_vault plugin enabled. We also run through the steps needed to restore the backup from the master to a slave.

This is the second of a two-part series on setting up Hashicorp Vault with Percona Server for MySQL with the keyring_vault plugin. First part is Using the keyring_vault plugin with Percona Server for MySQL 5.7.

Backing up from the master

First you need to install the latest Percona XtraBackup 2.4 package, in this tutorial I used this version:

Create a transition key using any method you prefer.  This transition key will be used by Percona XtraBackup to encrypt keys of the files being backed up. Make sure to keep the transition key and not lose it or else the backup will be unrecoverable.

You can store the transition-key in Vault and retrieve it later:

We will stream the backup to the slave server using netcat, first run this on the slave:

Then on the master I used --stream=xbstream  since it fails with --stream=tar reported here (PXB-1571). Run the xtrabackup command like this:

Restoring the backup on the Slave server

Extract the backup to a temporary location:

And then prepare it with the following command. Notice that we are still using the same transition key we used when backing up the database in the master server.

Configure keyring_vault.conf on slave

Create the keyring_vault.conf file with the following contents:

Notice that it uses the same token as the master server but has a different secret_mount_point. The same CA certificate will be used across all servers connecting to this Vault server.

Use –copy-back option to finalize backup restoration

Next use the --copy-back option to copy the files from the temporary backup location to the mysql data directory on the slave. Observe that during this phase XtraBackup generates a new master key, stores it in the Vault server and re-encrypts tablespace headers using this key.

Once that’s done, change file/directory ownership to mysql.

Start the mysqld instance on the slave server configured similarly to the master configuration in the first part of this series.

From here, you should be able to create the replication user on the master, and then configure slave replication based on the coordinates in the xtrabackup_binlog_info file. You can follow this section of the manual on starting replication.

For further reference, please read the manual related to Encrypted InnoDB tablespace backups.

Is validating your security strategy a concern?

Do you need to demonstrate that the security strategy that you have implemented for your databases is sufficient and appropriate? Perhaps you could benefit from a professional database audit? It could provide the reassurance that your organization needs.

PREVIOUS POST
NEXT POST

Share this post

Comment (1)

  • Matthew Lenz Reply

    Every time I see a blog post about backup I keep hoping that eventually you guys will cover percona server for mysql quiesce for drive snapshots (GCP, AWS, etc). There is a lot of (mis)information on how to properly quiesce mysql for those types of environments.

    September 27, 2018 at 8:58 am

Leave a Reply