Conceptos básicos de copia de seguridad

Razones para hacer copias de seguridad

• Recuperación completa del sistema: si un sistema falla, es crucial contar con una copia de seguridad de sus datos para
restaurarlos. La estrategia de copia de seguridad y recuperación que implementa está determinada por la forma en que
se completan y los datos que deben estar actualizados.

• Capacidades de auditoría: para ciertos sistemas y procesos asociados, puede ser importante para los usuarios finales o
administradores de los datos poder auditar o analizar los datos en un entorno separado del entorno de producción
principal. Las copias de seguridad pueden ser útiles en esta capacidad.

• Tareas típicas de DBA: las copias de seguridad de datos pueden ser necesarias cuando necesita realizar tareas típicas de
DBA como transferir datos de un sistema a otro, crear un servidor de desarrollo basado en un estado específico de un
servidor de producción, recuperar ciertas partes del sistema a un Estado antes de un error de usuario, y así sucesivamente.

• Caliente: estas copias de seguridad dinámicas se realizan mientras se leen y modifican los datos con poca o ninguna
interrupción de su capacidad para interactuar con los datos o manipularlos. Con las copias de seguridad en caliente, puede
mantener la accesibilidad del sistema tanto para la lectura como para la modificación de conjuntos de datos.

• Frío: estas copias de seguridad se realizan mientras los datos están completamente bloqueados porque los usuarios
pueden leer y / o hacer modificaciones a los datos. Estas copias de seguridad sin conexión le impiden realizar cualquier
actividad con los datos. Estos tipos de copias de seguridad no interfieren con el rendimiento del sistema cuando está en
funcionamiento. Sin embargo, no es aceptable para algunas aplicaciones tener que bloquear o bloquear completamente
el acceso de los usuarios a los datos durante un período prolongado de tiempo.

• Caliente: estas copias de seguridad se realizan mientras se están leyendo los datos, pero en la mayoría de los casos, los
datos en sí no se pueden modificar mientras se realiza la copia de seguridad. Este tipo de copia de seguridad en la mitad
del camino tiene la ventaja de no tener que bloquear completamente a los usuarios finales. Sin embargo, la desventaja de
no poder modificar los conjuntos de datos mientras se realiza la copia de seguridad puede hacer que este tipo de copia
de seguridad no sea razonable para ciertas aplicaciones. No poder modificar los datos durante las copias de seguridad
puede generar problemas de rendimiento.

----------------------------------------------------------------------------------------------------------------------------------------------------------------

• Disco: la copia de seguridad de los datos directamente en otro disco mediante el uso de procesos como la replicación o
la duplicación de los datos (por ejemplo, RAID), o mediante el uso de aplicaciones externas (como DRBD), puede
proporcionar una conexión en vivo (o tan cercana a la vida como posible) y medios rápidos de recuperación de datos.

• Registros binarios: el registro binario registra modificaciones a los datos; no graba las instrucciones SELECT o SHOW. Por
lo tanto, los registros binarios son muy útiles para restaurar aquellos eventos que han ocurrido desde la última copia de
seguridad completa. La ventaja de realizar copias de seguridad de registros binarios es que contienen una instantánea de
los datos en un momento dado. Pueden existir múltiples registros binarios en orden secuencial desde la última copia de
seguridad completa, según la cantidad de datos que se modifiquen y la frecuencia con la que se complete una copia de
seguridad completa. La desventaja de los registros binarios es que todos los registros binarios secuenciales que se crearon
a partir de la última copia de seguridad completa deben ser

Restaurado en secuencia. Además, la recuperación de una falla del sistema puede ser lenta dependiendo

en el número de registros binarios que deben ser restaurados.

• Copia de seguridad lógica / textual: puede hacer un volcado de datos completo usando mysqldump.

Estos volcados de datos se basan en un punto específico en el tiempo pero son las más lentas de todas las copias de
respaldo. La ventaja de usar mysqldump es que el archivo que se crea es simplemente una serie de sentencias de SQL que
se pueden trasladar fácilmente a otro sistema. La desventaja es que las tablas deben estar bloqueadas durante el volcado,
lo que evita que los usuarios lean o escriban en los archivos durante la copia de seguridad.

----------------------------------------------------------------------------------------------------------------------------------------------------------------

Copias de seguridad con MySQL

Las copias de seguridad de MySQL pueden ser una de las siguientes:

• Una copia de seguridad lógica produce un archivo de texto que contiene sentencias de SQL para reconstruir la base de
datos.

• Una copia de seguridad física es una copia binaria de los archivos de la base de datos MySQL.

• Una copia de seguridad basada en instantáneas

• Una copia de seguridad basada en la replicación

• Una copia de seguridad incremental (creada al vaciar los registros binarios de MySQL)

----------------------------------------------------------------------------------------------------------------------------------------------------------------

Logical (Textual) Backups

Declaraciones SQL

Las copias de seguridad lógicas o de texto vuelcan el contenido de la base de datos en archivos de texto. Estos archivos de
texto contienen sentencias de SQL y, como tales, son muy portátiles. Estas declaraciones SQL contienen toda la
información necesaria para reconstruir las tablas y bases de datos MySQL. Puede usar el archivo de texto para volver a
cargar la base de datos en otro host, ejecutando una arquitectura diferente.

El servidor debe estar funcionando

El servidor MySQL debe estar ejecutándose cuando crea copias de seguridad lógicas porque el servidor lee e interpreta
los archivos de los que se realizará la copia de seguridad. Otras aplicaciones pueden realizar operaciones de lectura
durante la copia de seguridad lógica.

Servidores locales y remotos

Con las copias de seguridad lógicas, puede hacer una copia de seguridad de los servidores MySQL locales y remotos. Puede
realizar otros tipos de copia de seguridad (en bruto) solo en el servidor MySQL local.

Generalmente más lento

Las copias de seguridad lógicas son generalmente más lentas que las copias de seguridad sin procesar. Esto se debe a que
el servidor MySQL debe leer las tablas e interpretar sus contenidos. Luego debe traducir el contenido de la tabla a un
archivo de disco, o enviar las declaraciones a un programa cliente, que las escribe.

Una copia de seguridad lógica también es más lenta que una copia de seguridad sin formato durante la recuperación. Esto
se debe a que el método de recuperación es leer las instrucciones INSERT individuales y volver a crear cada tabla y fila.

----------------------------------------------------------------------------------------------------------------------------------------------------------------

Copias de seguridad físicas (en bruto o binarias)

Copia exacta
Las copias de seguridad sin procesar son copias binarias de los archivos de la base de datos MySQL. Estas copias conservan
las bases de datos exactamente en el mismo formato en el que MySQL las almacena en el disco. Debido a que son copias
exactas de los originales, las copias de seguridad sin procesar son del mismo tamaño que las originales.

Es más rápido hacer una copia de seguridad binaria porque involucra solo aquellas operaciones de copia de archivos que
no necesitan saber nada sobre la estructura interna de los archivos. Sin embargo, si la copia de seguridad se va a utilizar
para transferir bases de datos a otra máquina que usa una arquitectura diferente, los archivos deben ser binarios
portátiles. Debido a que una copia de seguridad sin formato es una representación exacta de los bits en los archivos de
base de datos, deben restaurarse en un servidor MySQL usando el mismo motor de base de datos. Una copia de seguridad
de MySQL sin procesar no se puede recuperar de una base de datos InnoDB a una base de datos MyISAM.

MySQL Server Shutdown

Con los métodos de copia de seguridad binarios, debe asegurarse de que el servidor no modifique los archivos mientras
la copia de seguridad está en curso. Esto se puede lograr de varias maneras. Una es cerrar el servidor MySQL y luego tomar
la copia de seguridad. Esto tiene obvias desventajas. por

Algunos motores de almacenamiento, un mejor enfoque es bloquear temporalmente la base de datos, tomar la copia de
seguridad,

y luego desbloquear la base de datos. El impacto también se puede minimizar a MariaDB y aplicaciones mediante el uso
de instantáneas, replicación o métodos propietarios.

----------------------------------------------------------------------------------------------------------------------------------------------------------------

Copia de seguridad basada en instantáneas

Capacidad de instantánea externa

Las copias de seguridad basadas en instantáneas utilizan alguna capacidad de instantáneas externas. Por ejemplo, si sus
bases de datos MariaDB y sus registros binarios existen en un volumen lógico LVM2 con un sistema de archivos adecuado
(XFS o VxFS), puede crear copias de seguridad de instantáneas. Las copias de seguridad basadas en instantáneas funcionan
mejor para motores transaccionales como InnoDB. Para InnoDB, se puede realizar una copia de seguridad en caliente;
Para otros motores, se puede realizar una copia de seguridad en caliente.

Escalable

Las copias de seguridad de instantáneas son escalables, ya que el tiempo necesario para realizar la instantánea no aumenta
a medida que aumenta el tamaño de la base de datos. De hecho, la ventana de copia de seguridad (desde la perspectiva
de la aplicación) es casi cero. Sin embargo, una copia de seguridad basada en instantáneas casi siempre incluye una copia
de seguridad sin formato después de que se toma la instantánea.

----------------------------------------------------------------------------------------------------------------------------------------------------------------

Copia de seguridad basada en la replicación

Replicación asíncrona unidireccional

Las funciones de MySQL son compatibles con la replicación asíncrona unidireccional, en la que un servidor actúa como
maestro, mientras que uno o más servidores actúan como esclavos. Las copias de seguridad se pueden realizar a través
de la replicación utilizando la réplica o el esclavo en lugar del maestro. Esto tiene la ventaja de no producir ningún impacto
en el servidor maestro.

Desventajas

Esta es una solución más costosa, ya que debe comprar hardware adicional y ancho de banda de red. Además, la copia del
esclavo de la base de datos no es idéntica al maestro porque es una replicación asíncrona.
----------------------------------------------------------------------------------------------------------------------------------------------------------------

Cambios realizados después de la copia de seguridad

Es necesario hacer copias de seguridad, pero una copia de seguridad es solo uno de los componentes que necesita para
la recuperación de datos después de una pérdida o daño. El otro es el registro binario, que contiene un registro de cambios
de datos. Para recuperar las bases de datos, utiliza las copias de seguridad para restaurarlas a su estado en el momento
de la copia de seguridad. Una vez que se ha restaurado la copia de seguridad, se ejecutan las instrucciones contenidas en
el registro binario que realizó cambios en los datos después de que se creó la copia de seguridad. Asegúrese de que el
registro binario esté habilitado para todos los servidores MySQL.

SUPER privilegio

Debe tener el privilegio SUPER para establecer esta variable. Cualquier intento de establecer esta variable sin el privilegio
SUPER da como resultado el siguiente error:

ERROR 1227 (42000): Acceso denegado; Necesitas el privilegio SUPER para esta operación.

----------------------------------------------------------------------------------------------------------------------------------------------------------------

Las copias de seguridad se pueden hacer sin el uso de herramientas o utilidades adicionales.

Ejemplos:

• Sentencias SQL que se utilizan para realizar copias de seguridad lógicas

• Realizar copias de seguridad sin procesar una combinación de sentencias de SQL (para el bloqueo) junto con los
comandos del sistema operativo (para hacer la copia binaria)

mysqlhotcopy

La utilidad mysqlhotcopy también viene con la distribución de MariaDB. Realiza una copia de seguridad sin procesar y se
usa solo para aquellas bases de datos que usan el motor de base de datos MyISAM. El nombre implica que la base de
datos tiene una copia de seguridad "activa", lo que significa que no hay interrupciones en la disponibilidad de la base de
datos. Sin embargo, este no es el caso, ya que la base de datos está bloqueada y no se puede cambiar durante la copia de
seguridad. Por lo tanto, se describe mejor como una copia de seguridad "caliente". No hay informes o seguimiento
proporcionado con este script.

mysqldump

La utilidad mysqldump viene con la distribución de MySQL. Realiza copias de seguridad lógicas y funciona con cualquier
motor de base de datos. Se puede automatizar con el uso de crontab en Linux y UNIX, y con el administrador de tareas de
Windows. No hay herramientas de seguimiento o informes para mysqldump.

Herramientas de terceros
Las herramientas comerciales y comunitarias de Oracle son el enfoque principal de esta lección. Sin embargo, debe tener
en cuenta que existen numerosas herramientas comerciales y comunitarias de terceros que pueden incorporarse en sus
estrategias de respaldo.

----------------------------------------------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------

mysqlbackup es un comando que puede usar para realizar una copia de seguridad en línea de sus tablas InnoDB, y una
instantánea de sus tablas MyISAM que corresponden a la misma posición de binlog de la copia de seguridad de las tablas
InnoDB. Además de crear copias de seguridad, mysqlbackup puede preparar una copia de seguridad para iniciar un
servidor MySQL en la copia de seguridad, y puede copiar datos, índices y archivos de registro desde el directorio de copia
de seguridad a sus ubicaciones originales.

Pasos seguidos

1. Se hace ping al servidor MariaDB para ver si mysqlbackup puede conectarse al servidor MariaDb.

2. Se llama a mysqlbackup y realiza una copia de seguridad en línea de las tablas InnoDB.

- Esta fase no perturba el procesamiento normal de la base de datos.

3. Cuando la ejecución de mysqlbackup casi se ha completado, se ejecuta el comando SQL f lush t ab le s con readlock, y
luego las tablas MyISAM y los archivos .frm se copian en el directorio de respaldo.

- Si en este momento no ejecuta selecciones largas u otras consultas en la base de datos, y sus tablas MyISAM son
pequeñas, la fase de bloqueo dura solo unos segundos.

De lo contrario, toda la base de datos, incluidas las tablas de tipo InnoDB, se puede bloquear durante bastante tiempo.

4. mysqlbackup se ejecuta hasta el final y desbloquea las tablas.

----------------------------------------------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------

copia de respaldo

Ejecutar esta opción requiere que el servidor de la base de datos ya esté apagado. La opción luego copia los archivos de
datos, los registros y otros archivos respaldados desde el directorio de respaldo a sus ubicaciones originales, y realiza
cualquier procesamiento posterior requerido en ellos.

----------------------------------------------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------

Para que mysqlbackup cree una copia de seguridad de un solo archivo, todos los archivos de datos originales deben estar
en un solo directorio en lugar de estar distribuidos en diferentes rutas. Esto requiere que especifique la misma ruta para
las opciones de configuración datadir, innodb log group home dir e innodb data home dir.

----------------------------------------------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------

• - src-entry: identifica un archivo o directorio para extraer una copia de seguridad de un solo archivo

• - dst-entry: se utiliza con copias de seguridad de un solo archivo para extraer un solo archivo o directorio en una ruta
especificada por el usuario

----------------------------------------------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------
Copia de seguridad completa de InnoDB

Una operación de copia de seguridad sin procesar hace una copia de seguridad completa de InnoDB (una copia de
seguridad de todas las tablas en el espacio de tablas de InnoDB) se basa en hacer copias exactas de todos los archivos que
InnoDB utiliza para administrar el espacio de tablas.

Recuperación

Para recuperar un espacio de tabla InnoDB utilizando una copia de seguridad sin procesar, detenga el servidor, reemplace
todos los componentes de los cuales se hicieron copias durante el procedimiento de copia de seguridad y reinicie el
servidor.

Nota: Es necesario copiar los archivos del espacio de tablas como un grupo. Esto significa que debe reemplazar cualquier
archivo de espacio de tabla existente en el servidor. No puede agregar un espacio de tabla a otro utilizando una copia de
seguridad sin formato.

LOCK TABLES

Para realizar una copia de seguridad sin formato de una tabla MylSAM, copie el archivo. frm, .m y d, y .myi archivos que
MariaDB usa para representar la tabla. Durante esta operación de copia, otros programas (incluido el servidor) no deben
usar la tabla. Para evitar problemas de interacción con el servidor, detenga el servidor durante la operación de copia.

Nota: Bloquear tablas en lugar de apagar el servidor funciona en sistemas Linux. En Windows, el comportamiento de
bloqueo de archivos es tal que podría no ser capaz de copiar archivos de tablas para tablas que están bloqueadas por el
servidor. En ese caso, detenga el servidor antes de copiar los archivos de tabla.

Nuevo archivo de registro binario

Para iniciar un nuevo archivo de registro binario, use flush logs (antes de unlocktables). Como alternativa, show master
status devuelve el nombre y la posición del archivo de registro binario actual. El nuevo archivo de registro binario contiene
todas las declaraciones que cambian los datos después de la copia de seguridad (y cualquier archivo de registro binario
posterior).

Recuperación

Para recuperar una tabla MyISAM de una copia de seguridad sin formato, detenga el servidor, copie los archivos de la
tabla de copia de seguridad en el directorio de la base de datos correspondiente y reinicie el servidor

----------------------------------------------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------

Locks tables

mysqlhotcopy se conecta al servidor MariaDB local y copia los archivos de la tabla. Cuando ha finalizado la operación de
copia, desbloquea las tablas.

MariaDB debe estar en ejecución

Ejecute mysqlhotcopy en el servidor host para que pueda copiar los archivos de la tabla mientras los bloqueos de la tabla
están en su lugar. El servidor debe estar ejecutándose para que mysqlhotcopy pueda conectarse al servidor.
La operación de mysqlhotcopy es rápida porque copia los archivos de la tabla directamente en lugar de realizar copias de
seguridad a través de la red.

Opciones

- flush-log: vacía registros después de bloquear todas las tablas

- record_log_pos = db_name. tbl_name: registra el estado del maestro y el esclavo en la base de datos especificada
db_name y la tabla tbl_name

----------------------------------------------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------

Portabilidad

La portabilidad binaria es útil cuando se toma una copia de seguridad binaria hecha en una máquina para usar en una
segunda máquina que tiene una arquitectura diferente. Por ejemplo, usar una copia de seguridad binaria es una forma de
copiar bases de datos de un servidor MariaDB a otro.

InnoDB

Para InnoDB, con la portabilidad binaria puede copiar archivos de espacio de tabla directamente desde un servidor
MariaDB en una máquina a otro servidor en otra máquina, y el segundo servidor accede al espacio de tabla. De forma
predeterminada, todas las tablas InnoDB administradas por un servidor se almacenan juntas en el espacio de tablas.

MyISAM

Para MyISAM, la portabilidad binaria significa que los archivos se pueden copiar directamente para una tabla MyISAM de
un servidor MariaDB a otro en una máquina diferente, y el segundo servidor accede a la tabla

----------------------------------------------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------

Ubicación de almacenamiento

Para los archivos de volcado de formato SQL que contienen las tablas de creación e inserción para recrear las tablas, el
servidor envía el contenido de la tabla a mysqldump, que escribe los archivos en el host del cliente.