sql >> Base de Datos >  >> RDS >> Mysql

Cómo hacer una copia de seguridad de una base de datos cifrada con Percona Server para MySQL 8.0

Casi se garantiza que las interrupciones de producción ocurrirán en algún momento. Lo sabemos, así que planificamos copias de seguridad, creamos bases de datos en espera de recuperación, convertimos instancias individuales en clústeres.

Admitiendo la necesidad de un escenario de recuperación adecuado, debemos analizar el posible cronograma de desastres y los escenarios de falla e implementar pasos para recuperar su base de datos. La ejecución de una interrupción planificada puede ayudar a preparar, diagnosticar y recuperarse de la siguiente. Para mitigar el impacto del tiempo de inactividad, las organizaciones necesitan un plan de recuperación adecuado, que incluya todos los factores necesarios para que el servicio cobre vida.

La gestión de copias de seguridad no es tan sencilla como programar una tarea de copia de seguridad. Hay muchos factores a considerar, como la retención, el almacenamiento, la verificación y si las copias de seguridad que está realizando son físicas o lógicas y qué es fácil pasar por alto la seguridad.

Muchas organizaciones varían su enfoque de las copias de seguridad, tratando de tener una combinación de copias de seguridad de imágenes del servidor (instantáneas), copias de seguridad lógicas y físicas almacenadas en múltiples ubicaciones. Es para evitar cualquier desastre local o regional que borre nuestras bases de datos y copias de seguridad almacenadas en el mismo centro de datos.

Queremos que sea seguro. Los datos y las copias de seguridad deben estar encriptados. Pero hay muchas implicaciones cuando ambas opciones están en su lugar. En este artículo, echaremos un vistazo a los procedimientos de copia de seguridad cuando tratemos con bases de datos cifradas.

Cifrado en reposo para Percona Server para MySQL 8.0

A partir de MySQL 5.7.11, la versión comunitaria de MySQL comenzó a admitir el cifrado de espacio de tabla InnoDB. Se llama Cifrado de espacio de tabla transparente o se conoce como Cifrado en reposo.

La principal diferencia en comparación con la versión empresarial es la forma en que se almacenan las claves:las claves no se encuentran en una bóveda segura, lo cual es necesario para el cumplimiento normativo. Lo mismo se aplica a Percona Server, a partir de la versión 5.7.11, es posible cifrar el espacio de tablas de InnoDB. En Percona Server 8.0, la compatibilidad con el cifrado de registros binarios se ha ampliado considerablemente. Versión 8.0 añadida 

(Según el documento de versión de Percona 8.0):

  • Cifrado de archivos temporales
  • InnoDB Deshacer Cifrado de Tablespace
  • Cifrado de espacios de tablas del sistema InnoDB (Cifrado de espacios de tablas del sistema InnoDB)
  • default_table_encryption  =DESACTIVADO/ACTIVADO (Cifrado de espacio de tabla general)
  • table_encryption_privilege_check =DESACTIVADO/ACTIVADO (verificación de la configuración de cifrado)
  • Cifrado de registro de rehacer de InnoDB (solo para cifrado de clave maestra) (Cifrado de registro de rehacer)
  • Cifrado de archivos combinados de InnoDB (verificación de la configuración de cifrado)
  • Cifrado de búfer de doble escritura paralelo Percona (Cifrado de espacio de tabla InnoDB)

Para aquellos interesados ​​en migrar de la versión MySQL Enterprise a Percona:también es posible integrarse con el servidor Hashicorp Vault a través de un complemento keyring_vault, que coincide con las funciones disponibles en la edición MySQL Enterprise de Oracle.

El cifrado de datos en reposo requiere un complemento de llavero. Hay dos opciones aquí:

  • keyring_file:un archivo plano con una clave de cifrado
  • Complemento Keyring Vault :un servicio

Cómo habilitar el cifrado de espacios de tabla

Para habilitar el cifrado, inicie su base de datos con la opción --early-plugin-load:

ya sea a mano:

$ mysqld --early-plugin-load="keyring_file=keyring_file.so"

o modificando el archivo de configuración:

[mysqld]

early-plugin-load=keyring_file.so

Al iniciar Percona Server 8.0, se pueden cifrar dos tipos de tablespaces. Espacio de tabla general y espacio de tabla del sistema. Sys tablespace se controla a través del parámetro innodb_sys_tablespace_encrypt. De forma predeterminada, el espacio de tablas del sistema no está encriptado y, si ya tiene uno, no es posible convertirlo al estado encriptado, se debe crear una nueva instancia (inicie una instancia con la opción --bootstrap).

El espacio de tablas general admite el cifrado de todas las tablas en el espacio de tablas o de ninguna. No es posible ejecutar el cifrado en modo mixto. Para crear un espacio de tabla con cifrado, utilice el indicador ENCRYPTION='Y/N'.

Ejemplo:

mysql> CREATE TABLESPACE severalnines ADD DATAFILE 'severalnines.ibd' ENCRYPTION='Y';

Copia de seguridad de una base de datos cifrada

Cuando agrega espacios de tablas encriptados, es necesario incluir el archivo de conjunto de claves en el comando xtrabackup. Para hacerlo, debe especificar la ruta a un archivo de llavero como el valor de la opción --keyring-file-data.

$ xtrabackup --backup --target-dir=/u01/mysql/data/backup/ --user=root --keyring-file-data=/u01/secure_location/keyring_file

Asegúrese de almacenar el archivo del conjunto de claves en una ubicación segura. Además, asegúrese de tener siempre una copia de seguridad del archivo. Xtrabackup no copiará el archivo del conjunto de claves en el directorio de copia de seguridad. Para preparar la copia de seguridad, debe hacer una copia del archivo del conjunto de claves usted mismo.

Preparación de la copia de seguridad

Una vez que tengamos nuestro archivo de copia de seguridad, debemos prepararlo para la recuperación. Aquí también debe especificar los datos del archivo de claves.

$ xtrabackup --prepare --target-dir=/u01/mysql/data/backup/ --keyring-file-data=/u01/secure_location/keyring_file

La copia de seguridad ahora está preparada y se puede restaurar con la opción --copy-back. En el caso de que el conjunto de claves se haya rotado, deberá restaurar el conjunto de claves (que se utilizó para tomar y preparar la copia de seguridad).

Para preparar la copia de seguridad xtrabackup, necesitaremos acceso al conjunto de claves. Xtrabackup no se comunica directamente con el servidor MySQL y no lee el archivo de configuración my.cnf predeterminado durante la preparación; especifique la configuración del conjunto de claves a través de la línea de comando:

$ xtrabackup --prepare --target-dir=/data/backup --keyring-vault-config=/etc/vault.cnf

La copia de seguridad ahora está preparada y se puede restaurar con la opción --copy-back:

$ xtrabackup --copy-back --target-dir=/u01/backup/ --datadir=/u01/mysql/data/

Realización de copias de seguridad incrementales

El proceso de realizar copias de seguridad incrementales con el cifrado de espacio de tabla InnoDB es similar a realizar las mismas copias de seguridad incrementales con un espacio de tabla sin cifrar.

Para hacer una copia de seguridad incremental, comience con una copia de seguridad completa. El binario xtrabackup escribe un archivo llamado xtrabackup_checkpoints en el directorio de destino de la copia de seguridad. Este archivo contiene una línea que muestra to_lsn, que es el LSN de la base de datos al final de la copia de seguridad.

Primero, debe crear una copia de seguridad completa con el siguiente comando:

$ xtrabackup --backup --target-dir=/data/backups/base --keyring-file-data=/var/lib/mysql-keyring/keyring

Ahora que tiene una copia de seguridad completa, puede hacer una copia de seguridad incremental basada en ella. Use un comando como el siguiente:

$ xtrabackup --backup --target-dir=/data/backups/inc1 \

--incremental-basedir=/data/backups/base \

--keyring-file-data=/var/lib/mysql-keyring/keyring

El directorio /data/backups/inc1/ ahora debería contener archivos delta, como ibdata1.delta y test/table1.ibd.delta.

El significado debe ser evidente. Ahora es posible utilizar este directorio como base para otra copia de seguridad incremental:

$ xtrabackup --backup --target-dir=/data/backups/inc2 \

--incremental-basedir=/data/backups/inc1 \

--keyring-file-data=/var/lib/mysql-keyring/keyring

Preparación de copias de seguridad incrementales

Hasta ahora, el proceso de copia de seguridad de la base de datos es similar a una copia de seguridad regular, excepto por el indicador donde especificamos la ubicación del archivo de claves.

Desafortunadamente, el paso --prepare para las copias de seguridad incrementales no es el mismo que para las copias de seguridad normales.

En las copias de seguridad normales, se realizan dos tipos de operaciones para que la base de datos sea coherente:las transacciones confirmadas se reproducen desde el archivo de registro contra los archivos de datos y las transacciones no confirmadas se revierten. Debe omitir la reversión de las transacciones no confirmadas al preparar una copia de seguridad, ya que las transacciones que no estaban confirmadas en el momento de la copia de seguridad pueden estar en curso y es probable que se confirmen en la próxima copia de seguridad incremental. Debe usar la opción --apply-log-only para evitar la fase de reversión.

Si no utiliza la opción --apply-log-only para evitar la fase de reversión, sus copias de seguridad incrementales serán inútiles. Después de revertir las transacciones, no se pueden aplicar más copias de seguridad incrementales.

Comenzando con la copia de seguridad completa que creó, puede prepararla y luego aplicarle las diferencias incrementales. Recuerda que tienes las siguientes copias de seguridad:

/data/backups/base

/data/backups/inc1

/data/backups/inc2

Para preparar la copia de seguridad base, debe ejecutar --prepare como de costumbre, pero evite la fase de reversión:

$ xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base --keyring-file-data=/var/lib/mysql-keyring/keyring

Para aplicar la primera copia de seguridad incremental a la copia de seguridad completa, debe usar el siguiente comando:

$ xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base \

--incremental-dir=/data/backups/inc1 \

--keyring-file-data=/var/lib/mysql-keyring/keyring

si el conjunto de claves se ha rotado entre la base y la copia de seguridad incremental, necesitará usar el conjunto de claves que estaba en uso cuando se realizó la primera copia de seguridad incremental.

Preparar la segunda copia de seguridad incremental es un proceso similar

$ xtrabackup --prepare --target-dir=/data/backups/base \

--incremental-dir=/data/backups/inc2 \

--keyring-file-data=/var/lib/mysql-keyring/keyring

Nota; --apply-log-only debe usarse al fusionar todos los incrementales excepto el último. Es por eso que la línea anterior no contiene la opción --apply-log-only. Incluso si se usó --apply-log-only en el último paso, la copia de seguridad seguiría siendo coherente, pero en ese caso el servidor realizaría la fase de reversión.
El último paso es restaurarlo con --copy-back opción. En caso de que se haya rotado el conjunto de claves, deberá restaurar el conjunto de claves que se utilizó para tomar y preparar la copia de seguridad.

Si bien el método de restauración descrito funciona, requiere acceso al mismo conjunto de claves que utiliza el servidor. Es posible que no sea posible si la copia de seguridad se prepara en un servidor diferente o mucho más tarde, cuando se eliminan las claves del conjunto de claves o, en caso de mal funcionamiento, cuando el servidor de almacenamiento del conjunto de claves no está disponible en absoluto.

La opción --transition-key= debe usarse para que xtrabackup pueda procesar la copia de seguridad sin acceso al servidor de almacenamiento de claves. En este caso, xtrabackup obtiene la clave de cifrado AES de la frase de contraseña especificada y la utilizará para cifrar las claves de los espacios de tablas de los que se está realizando una copia de seguridad.

Creación de una copia de seguridad con una frase de contraseña

El siguiente ejemplo ilustra cómo se puede crear la copia de seguridad en este caso:

$ xtrabackup --backup --user=root -p --target-dir=/data/backup \

--transition-key=MySecetKey

Restauración de la copia de seguridad con una clave generada

Al restaurar una copia de seguridad, deberá generar una nueva clave maestra. Aquí está el ejemplo para keyring_file:

$ xtrabackup --copy-back --target-dir=/data/backup --datadir=/data/mysql \

--transition-key=MySecetKey --generate-new-master-key \

--keyring-file-data=/var/lib/mysql-keyring/keyring

En el caso de keyring_vault, se verá así:

$ xtrabackup --copy-back --target-dir=/data/backup --datadir=/data/mysql \

--transition-key=MySecetKey --generate-new-master-key \

--keyring-vault-config=/etc/vault.cnf