Una parte vital para prevenir cualquier tipo de pérdida de datos en cualquier situación es tener políticas de copia de seguridad y recuperación adecuadas. También es esencial garantizar la recuperación de datos en cualquier momento del ciclo de vida del flujo de trabajo de la aplicación. Tanto MySQL como MariaDB ofrecen soluciones para estos casos. Este artículo explorará las opciones y los procedimientos existentes, así como otras posibles opciones de copia de seguridad para MySQL y MariaDB.
Estrategias de copia de seguridad
Como los datos son la parte más importante de cualquier aplicación, proteger su integridad es vital para sobrevivir en la batalla de la existencia. Es probable que cualquier interrupción de la accesibilidad o la integridad de los datos en cualquier momento perjudique gravemente a la aplicación y al negocio/servicio que proporciona.
Para garantizar el éxito del flujo de trabajo de la aplicación y la continuidad del negocio, debe implementar políticas de copia de seguridad y recuperación adecuadas con copias de seguridad diarias, semanales, mensuales y anuales. Dichas copias de seguridad se ejecutarán en períodos críticos, como:
- antes de una ventana de lote diario;
- antes de ingestas masivas de datos;
- antes de cualquier actualización de la aplicación;
- copias de seguridad semanales, mensuales y anuales para satisfacer los requisitos reglamentarios;
- u otro mantenimiento programado diario/semanal.
Herramientas de copia de seguridad
MySQL y MariaDB ofrecen varias formas de configurar y ejecutar planes de copia de seguridad y recuperación. Estos métodos incluyen copias de seguridad físicas con la herramienta mysqlbackup Enterprise de MySQL , Herramienta mariabackup de MariaDB , o herramienta XtraBackup de Percona . Además, las copias de seguridad lógicas creadas con la herramienta mysqldump de Mysql puede ser útil. Otra opción es la recuperación de un punto en el tiempo con los bin-logs de las bases de datos (los registros de transacciones) en combinación con las herramientas mencionadas anteriormente.
Puede incorporar métodos adecuados en su estrategia de copia de seguridad para maximizar la capacidad de recuperación de la base de datos en caso de falla o desastre.
Nota:En MariaDB versión 10.4.6, enlace simbólico de mysqldump se llama mariadb-dump . En las versiones posteriores, incluida la 10.5.2, los nombres cambiaron nuevamente:mysqldump se convirtió en enlace simbólico .
Para ilustrar los procedimientos, usaré la herramienta mariabackup para crear copias de seguridad físicas. La funcionalidad básica de la herramienta es la misma que en las herramientas antes mencionadas, aunque existen algunas pequeñas diferencias únicas para cada herramienta.
Copias de seguridad de bases de datos físicas
Las copias de seguridad físicas son copias de seguridad a nivel de archivo que le brindan métodos rápidos de copia de archivos. Tales copias de seguridad son preferibles en escenarios de recuperación de desastres, clonación de bases de datos y/o creación de bases de datos esclavas.
Al realizar copias de seguridad físicas, puede optar por crear copias de seguridad completas o incrementales. Las copias de seguridad completas incluyen una copia de seguridad completa del servidor de la base de datos. Las copias de seguridad incrementales solo guardan los cambios de la última copia de seguridad completa o incremental.
Importante:El tamaño de la base de datos regula el tiempo de la copia de seguridad. Por ese motivo, una buena estrategia para hacer una copia de seguridad de una base de datos muy grande puede ser combinar copias de seguridad completas e incrementales. De esta forma, ahorra tanto el espacio de almacenamiento de las copias de seguridad como el tiempo total de copia de seguridad y recuperación.
Otro momento que debe notar es que cuando recupera los datos de una copia de seguridad física, debe detener el proceso de la instancia de la base de datos MySQL/MariaDB hasta que se completen los pasos finales de recuperación.
Puede llevar a cabo la ejecución de una copia de seguridad física completa simple de la siguiente manera:
mariabackup --backup \
--target-dir=/data/backups/mariadb/D20210220 \
--user=backupuser --password=backuppasswd
El –target-dir opción le dice a la herramienta de copia de seguridad dónde colocar la copia de seguridad.
En este ejemplo, he organizado mi copia de seguridad en el directorio llamado DYYYYMMDD donde se almacena cada copia de seguridad completa (D significa Daily). Al hacerlo, tenemos un curso de acción fácil para restaurar la base de datos a partir de la copia de seguridad realizada en una fecha específica.
El siguiente ejemplo demuestra la ejecución de una copia de seguridad incremental simple:
mariabackup --backup \
--target-dir=/data/backups/mariadb/D20210220_inc1/ \
--incremental-basedir=/data/backups/mariadb/D20210220/ \
--user=backupuser --password=backuppasswd
La copia de seguridad incremental posterior tendría este aspecto:
mariabackup --backup \
--target-dir=/data/backups/mariadb/D20210220_inc2/ \
--incremental-basedir=/data/backups/mariadb/D20210220_inc1 \
--user=backupuser --password=backuppasswd
El –dir-basado-incremental La opción indica a la herramienta de copia de seguridad que utilice la copia de seguridad incremental o completa realizada anteriormente como punto de partida para crear archivos delta incrementales para la copia de seguridad actual. De esta forma, crea una cadena de una copia de seguridad completa con copias de seguridad incrementales posteriores. Juntos, forman una sola copia de seguridad para restaurar cuando sea necesario.
Ahora, averigüemos cuál es el nombre del archivo de la base de datos física en el que se almacenan todos los datos del directorio. La base de datos que se encuentra en los controladores de dominio es un Active Directory. Este directorio se utiliza para administrar usuarios, datos, etc. El núcleo de un Active Directory es el archivo de base de datos NTDS.DIT que consta de enlaces, descriptores de seguridad y tablas de datos. Todos los datos del directorio se guardan en este archivo de base de datos físico.
Es necesario distinguir entre archivos físicos y lógicos. Los datos reales del sistema se encuentran en archivos físicos, mientras que los archivos lógicos contienen la descripción de los registros almacenados en archivos físicos.
La tarea de restaurar la base de datos MySQL desde archivos físicos puede ser difícil a veces. El mysqldump El comando podría ser útil en este caso. Cubriremos más este tema.
Copias de seguridad de bases de datos lógicas
Las copias de seguridad lógicas se crean con mysqldump herramienta. Este método de copia de seguridad es más flexible que la copia de seguridad física. Consta de todas las sentencias DML y/o DDL SQL necesarias para formar una copia de seguridad coherente, combinando todos los datos comprometidos y los cambios realizados antes y durante la copia de seguridad. Si desea obtener más información sobre cómo realizar una copia de seguridad y restaurar todas las bases de datos, puede leer este artículo.
La copia de seguridad lógica puede ser un solo archivo o varios archivos (creados con un script específico). Además, puede restaurar la estructura y/o los datos sin cerrar su instancia (proceso) de MySQL/MariaDB. En consecuencia, las copias de seguridad lógicas se realizan a nivel de base de datos y/o tabla, mientras que las copias de seguridad físicas se realizan a nivel de sistema de archivos (directorios y archivos).
Tenga en cuenta también que las copias de seguridad lógicas son exclusivamente imágenes de copias de seguridad completas de las bases de datos y/o tablas previstas.
La creación de una copia de seguridad lógica de toda la instancia de MySQL/MariaDB se encuentra a continuación:
mysqldump --all-databases --single-transaction \
--quick --lock-tables=false \
-u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/full-backup-$(date +'%Y%m%d_%H%M%S').sql
Tenga en cuenta que las copias de seguridad físicas y las copias de seguridad lógicas se distinguen específicamente en el sistema de archivos con fines de gestión de copias de seguridad.
A diferencia del ejemplo anterior, una copia de seguridad lógica de una sola base de datos (esquema) se crea de la siguiente manera:
mysqldump empdb --single-transaction \
--quick --lock-tables=false \
-u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/empdb-full-backup-$(date +'%Y%m%d_%H%M%S').sql
Finalmente, para crear una copia de seguridad lógica de una sola tabla en una base de datos, agregue el nombre de la tabla después de la base de datos:
mysqldump empdb departments --single-transaction \
--quick --lock-tables=false \
-u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/empdb-departments-full-backup-$(date +'%Y%m%d_%H%M%S').sql
Cuando necesite editar y agregar las declaraciones DROP DATABASE o DROP TABLE al escenario de recuperación, trabajar con archivos de copia de seguridad grandes puede tener efectos restrictivos en los editores de texto hasta el punto de ahogarlos.
En tales casos, considere agregar otras opciones, como –add-drop-database y/o –add-drop-table para incluir estas sentencias DROP en la copia de seguridad. En otros escenarios, es posible que desee excluir estas declaraciones y sustituirlas por –skip-add-drop-table opción al comando.
Sin embargo, también puede crear copias de seguridad solo de datos o solo DDL usando –no-create-info o –sin datos opciones Las copias de seguridad separadas de datos y estructuras pueden ser una buena opción en algunos escenarios de recuperación, especialmente cuando solo necesita la estructura DDL para crear una base de datos clonada vacía y/o sus tablas.
Copia de seguridad de la base de datos mediante instantáneas de disco
A medida que crecen los datos, puede ser necesario organizarlos en varios discos y/o sistemas de archivos. Además de las razones de rendimiento, dado que la E/S se distribuye en varios discos/sistemas de archivos, debe asegurarse de que las estrategias eficientes de copia de seguridad y recuperación incluyan las capacidades de instantáneas del disco y del sistema de archivos.
Comience por diseñar y crear los diseños del sistema de archivos donde reside cada base de datos, grupo de tablas e índices. Luego, organice sus tablas y configure el sistema de base de datos. Deben residir todos en un solo directorio:
innodb_home_dir = /<path where your InnoDB tables will reside>O bien, puede utilizar el DATA_DIRECTORY y INDEX_DIRECTORY opciones en CREAR declaración de la tabla para distribuirlos por separado a diferentes ubicaciones del sistema de archivos.
Para InnoDB, asegúrese de usar file_per_table =ON (predeterminado ENCENDIDO en las versiones más recientes). Elija cuidadosamente la ruta para las tablas de InnoDB cuando las cree. Es imposible cambiar la ruta sin soltar y volver a crear la tabla.
Es útil tener sistemas de archivos adecuados con capacidades de instantáneas integradas, p. XFS y ZFS en Linux. Tenga en cuenta que la creación de copias de seguridad instantáneas es similar a la creación de copias de seguridad físicas, pero tiene sus especificidades. Requiere detener el proceso de escritura (FLUSH con READ LOCK o similar:consulte la ETAPA DE RESPALDO en la documentación en línea de MariaDB) antes de tomar la instantánea y liberar LOCKS inmediatamente después de la finalización de la instantánea. Es necesario para garantizar la coherencia de los datos.
Debe considerar y utilizar las copias de seguridad instantáneas en escenarios de recuperación ante desastres. Sin embargo, también son adecuados para clonar instancias de bases de datos.
Estrategias de recuperación
Recuperación desde copias de seguridad físicas
Anteriormente, hemos descrito los pasos de la copia de seguridad física. De esta forma, puede crear una cadena de copias de seguridad completas o una cadena de copias de seguridad completas e incrementales. La última opción significa que una copia de seguridad completa seguida de una copia de seguridad incremental posterior es el punto cero si ocurre una falla.
Por ejemplo, un DBA realiza copias de seguridad completas los domingos y copias de seguridad incrementales los demás días. Se produce un error después de realizar una copia de seguridad incremental el miércoles. Por lo tanto, necesitan restaurar la base de datos. En tales circunstancias, nuestro DBA tiene que utilizar la copia de seguridad completa realizada el domingo y las copias de seguridad incrementales realizadas los lunes, martes y miércoles. Si hubiera copias de seguridad completas diarias, sería suficiente restaurar la copia de seguridad del miércoles.
Para recuperar la copia de seguridad "más cercana" después de un error, ya sea una copia de seguridad completa o incremental, debe asegurarse de que TODOS los archivos de copia de seguridad sean coherentes en un punto en el tiempo con la hora de finalización de la copia de seguridad más cercana. De lo contrario, el motor InnoDB rechazará los datos al considerarlos corruptos.
Otro punto clave es que, cuando prepare copias de seguridad, copie las copias de seguridad completas involucradas en otra ubicación. antes de aplicar los pasos para garantizar la consistencia en un punto en el tiempo. De esta manera, conserva el estado original de la copia de seguridad, que puede ser útil más adelante. Recomiendo encarecidamente utilizar este enfoque.
Para preparar una copia de seguridad completa, elija la más cercana a la falla, cópiela en la ubicación preferida y ejecute el siguiente comando:
mariabackup --prepare \
--target-dir=data/backups/mariadb/COPY_D20210220
Para restaurar a la copia de seguridad incremental más cercana, prepare una copia de la copia de seguridad completa más cercana y agregue todas las copias de seguridad incrementales relevantes en un pedido posterior . La imagen de la base de datos restaurada debe ser la siguiente:
Logramos esto ejecutando el preparar comando para cada copia de seguridad incremental como se muestra a continuación:
mariabackup --prepare \
--target-dir=/data/backups/mariadb/COPY_D20210220 \
--incremental-dir=/data/backups/mariadb/D20210220_INC#
Después de preparar la copia de seguridad, debemos cerrar la instancia de la base de datos (proceso). Además, debemos vaciar el directorio de base de datos antes de finalizar el proceso de restauración. Puede emitir el comando con –copy-back opción
mariabackup --copy-back \
--target-dir=data/backups/mariadb/COPY_D20210220
o con –move-back opción:
mariabackup --move-back \
--target-dir=data/backups/mariadb/COPY_D20210220
El último comando mueve el directorio copiado al directorio de la base de datos. Copiar la copia de seguridad original en otra ubicación es una buena elección. De lo contrario, la copia de seguridad se perderá, ya que no podrá usarse para otras situaciones y escenarios.
El último paso antes de iniciar la instancia de la base de datos es ajustar la propiedad de los archivos para que coincida con el usuario y el grupo del propietario del proceso. Por lo general, es MySQL.
Recuperación desde copias de seguridad lógicas
Muy a menudo, pasamos por alto un punto clave cuando recuperamos bases de datos y/o tablas usando copias de seguridad lógicas. Este punto es establecer el max_allowed_packet tamaño de la sesión (puede ser más inteligente establecerlo globalmente) al valor máximo de 1073741824. Es necesario asegurarse de que los búfer grandes y las declaraciones INSERT encajen en un solo paquete entre el cliente y el servidor. Esto debería reducir el tiempo de recuperación.
Otro aspecto clave al hacer una copia de seguridad es incluir o excluir las declaraciones DROP como se mencionó anteriormente. Lo necesitamos para garantizar que el proceso de restauración de la copia de seguridad se ejecute de la mejor manera posible. Con eso en mente, use el siguiente código para ejecutar la restauración de la copia de seguridad:
mysql -u backupuser -p backuppasswd < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sqlSi no tiene ninguna base de datos incluida en la copia de seguridad, como ocurre con las copias de seguridad de bases de datos individuales, o si necesita redirigir la restauración a otra base de datos, utilice un código diferente:
mysql -u backupuser -p backuppasswd newemp < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sqlRecuperación con instantáneas de disco
Para recuperar desde la instantánea del disco siempre comience por asegurarse que el sistema de base de datos se apague antes se ejecuta el proceso de recuperación . Cualquier intento de recuperar una base de datos en vivo usando la instantánea del disco dará como resultado inconsistencias en los datos y, más probablemente, daños en los datos.
Recuperación puntual
La recuperación de un punto en el tiempo (PITR) es, como su nombre lo indica, un método para recuperar bases de datos y tablas lo más cerca posible del momento anterior a la falla. O bien, si el proceso por lotes diario ha fallado y debe volver a ejecutarse, también tiene la única opción:realizar una recuperación de copia de seguridad de PITR.
Es fundamental habilitar el registro binario de la base de datos y establecer el formato de registro binario en registro basado en declaraciones, basado en filas o mixto, según el tipo de carga de trabajo que se esté ejecutando en la base de datos. Además, es posible que deba habilitar la compresión usando log_bin_compress =ON (predeterminado OFF) para ahorrar espacio en disco.
Como bin-log es un registro de transacciones y se crea en una secuencia, es crucial hacer una copia de seguridad de todos los archivos de registro. En cuanto al proceso PITR, es imposible sin archivos de registro. Además, el mantenimiento y el ciclo de vida del bin-log deben seguir el ciclo de vida de las copias de seguridad completas e incrementales. Por lo tanto, asegúrese de purgar solo los registros que sean más antiguos que la copia de seguridad más antigua en la política de copia de seguridad.
Puede purgar registros binarios de dos maneras. Primero, es declarando el nombre de bin-log más cercano a la copia de seguridad más antigua, como se muestra en el siguiente comando de purga:
PURGE BINARY LOGS TO 'mariadb-bin.000063';En segundo lugar, es declarando la fecha de la copia de seguridad más antigua guardada en el comando de purga:
PURGE BINARY LOGS BEFORE '2021-01-20 00:00:00';Para prepararnos para la recuperación, necesitamos recuperar todas las declaraciones necesarias para reproducirlas en el momento necesario. Recopile todos los bin-logs disponibles desde el momento en que se inició la copia de seguridad hasta el momento en que se está recuperando.
Comience examinando la lista de registros desde el momento en que finalizó la copia de seguridad hasta el momento de PITR:
mysqlbinlog --start-datetime=<backup end datetime> --stop-datetime=<PITR datetime> \
<list of binlogs> \
> temporary_file.sql
Luego, examine los archivos temporales para encontrar las posiciones de registro exactas que desea aplicar y usar. Estos son –posición de inicio y –posición de parada que establece las posiciones exactas en el comando y vuelve a ejecutar mysqlbinlog comando:
mysqlbinlog --start-position=<exact log start position> --stop-position=<exact log position to stop on> \
<list of binlogs> \
> final_temporary_PITR_file.sql
En este punto, el proceso de recuperación ha comenzado. Utiliza copias de seguridad físicas o lógicas, completas o incrementales.
Finalice la recuperación aplicando el final_temporary_PITR_file.sql usando el cliente MySQL como se muestra a continuación:
mysql -u backupuser -p backuppasswd < final_temporary_PTR_file.sqlHemos completado la recuperación de PITR restaurando la copia de seguridad y las transacciones reproducidas desde el registro hasta el punto más cercano al momento en que ocurrió la falla.
Banco de trabajo
Para el diseño y desarrollo de bases de datos, pruebas y mantenimiento en MySQL y MariaDB, podemos usar una aplicación de Windows Workbench. También funciona en Linux. Con esta aplicación, los usuarios pueden diseñar bases de datos, ver y cambiar metadatos, transferir datos y metadatos, y mucho más. Vale la pena agregar que es posible usar dbForge Studio para MySQL en lugar de Workbench.
Conclusión
En total, hemos discutido e ilustrado brevemente las técnicas de copia de seguridad y recuperación de bases de datos con herramientas y métodos disponibles en MySQL y MariaDB.
Para recuperar el sistema de base de datos de cualquier falla con éxito, debemos implementar copia de seguridad tanto física como lógica métodos mencionados anteriormente en las políticas y planes, desde todo el sistema hasta tablas individuales.
Para realizar una PITR con éxito, necesitamos bin-log habilitado y necesidades de administración de registros adecuadas en su lugar.
Sin embargo, usar solo un método de copia de seguridad y perder los registros de contenedores sería un enfoque incorrecto. Puede provocar la pérdida de datos y dañar la continuidad comercial de su aplicación. Por lo tanto, combine diferentes métodos e incluya siempre los archivos de registro en las políticas de copia de seguridad y restauración.
