Copia de seguridad, restauración y PITR con Percona XtraBackup

Copia de seguridad física con Percona XtraBackup: instalación de la versión compatible de XtraBackup, usuario de backup con auth_socket, script de backup full + incremental comprimido/cifrado, programación con un systemd timer o cron, copia de binlogs y prueba de restauración. Las tarjetas de escenario cubren restauración completa, restauración desde una cadena incremental, recuperación a un punto concreto en el tiempo (PITR), restauración de una sola tabla, creación de una replica desde un backup y restauración en otro servidor. Use esta guía para el backup diario de bases de datos grandes y para la recuperación ante desastres; para migraciones, volcados de un solo esquema/tabla o el paso entre versiones use la guía de backup lógico (mysqldump / MySQL Shell).

Topología: 1 servidor (independiente, source, replica o secondary de InnoDB Cluster); almacenamiento de backup en disco local o NFS

Escenarios

• Configurar los backups, programarlos y probar una restauración (flujo completo) — Instalación de XtraBackup, usuario de backup, script de backup full + incremental, programación y una prueba de restauración (PITR incluido). Elija esta opción si lo configura por primera vez. El backup se toma con el servidor en marcha; sin downtime, solo aumenta la carga de disco/CPU.
• Restauración completa: volver al último backup full — El directorio de datos se ha perdido/dañado o el servidor no arranca; basta con volver al backup full de la cadena. MySQL permanece detenido durante toda la restauración.
• Restauración desde una cadena full + incremental (hasta el último incremental) — Quiere volver al momento del último backup incremental (o de un incremental que elija); los incrementales se aplican en orden sobre el full con --apply-log-only. MySQL permanece detenido durante toda la restauración.
• Recuperar a un punto en el tiempo (PITR): antes de un DELETE / DROP erróneo — Datos borrados o dañados por error: se restaura el último backup y se aplican los binlogs hasta justo antes de la transacción errónea (por hora, posición o GTID). MySQL permanece detenido durante toda la restauración y también se pierden las escrituras posteriores al error; si solo se ha visto afectada una tabla, considere primero el escenario de una sola tabla.
• Restaurar una sola tabla (--export + IMPORT TABLESPACE) — Solo necesita la versión de una tabla que hay en el backup; sin restaurar todo el servidor, la tabla se importa desde el backup con el nombre t_restore y los datos se corrigen desde ahí. El servidor sigue en marcha.
• Crear una nueva replica desde un backup — Quiere preparar una replica nueva (o reconstruida) a partir de un backup de XtraBackup existente en lugar de clonarla por la red, y conectarla al source (datos grandes, carga en el source). El source no se ve afectado; se reemplazan los datos del servidor de destino.
• Restaurar el backup en otro servidor (migración, pruebas, clonación) — Quiere abrir un backup de producción en un servidor de pruebas/desarrollo, trasladar un servidor o comprobar en un servidor aparte que el backup realmente se restaura. El servidor de origen no se ve afectado.

Antes de empezar

• MySQL … está en marcha (si se instaló con la guía Instalación de MySQL en un solo servidor de DBAtlas, las rutas son las mismas); el usuario root del sistema operativo puede conectarse sin contraseña con el comando mysql (auth_socket o ~/.mylogin.cnf).
• El directorio de backup … está en un disco/NFS aparte con al menos (tamaño de datos × número de cadenas) de espacio… (zstd suele reducirlo entre 3 y 6 veces)…. Una restauración necesita bajo … al menos el doble del tamaño de los datos libre (descompresión + prepare).
• El binary log está activado y GTID habilitado (para PITR y la coherencia de los incrementales).
• El servidor puede acceder a repo.percona.com por HTTPS, o hay un mirror interno configurado.
• Hay preparado un lugar seguro fuera del servidor (caja fuerte, gestor de contraseñas) para guardar una copia de la clave de cifrado. Si se pierde la clave, los backups no se pueden abrir.
• Preferiblemente hay un servidor de pruebas aparte para la prueba de restauración (instalado con la misma versión de MySQL y el mismo my.cnf). Los pasos de restauración reemplazan el directorio de datos del servidor en el que se ejecutan.
• Este servidor es una replica sana: los threads IO y SQL están en Yes y el retraso es bajo. Si se copian binlogs (PITR), log_replica_updates debe estar activado (activado por defecto en 8.x); de lo contrario, el binlog de la replica no contiene las transacciones que llegan del source.
• Este servidor es miembro de un InnoDB Cluster y ahora está en SECONDARY / ONLINE. El backup se programa en este miembro; si más adelante el miembro pasa a primary, el script registra un aviso y toma el backup igualmente.
• La cadena de backup a restaurar está bajo …… (en el servidor …)… y completa: el full y los incrementales a usar, junto con los directorios de metadatos -lsn…; clave de cifrado en …….
• En este servidor están instalados MySQL … y XtraBackup …; la versión menor de MySQL es igual o más reciente que la del servidor en el que se tomó el backup (el valor server_version del backup aparece en el paso de diagnóstico).
• …En el servidor de destino no hay datos que conservar: el directorio de datos se reemplaza por el backup (el anterior se aparta como .old-<timestamp>).…La ventana de mantenimiento y la parada de la aplicación están aprobadas: MySQL permanece detenido mientras dura la restauración; la aplicación no debe conectarse a este servidor.…
• La tabla es InnoDB y está en su propio archivo .ibd con innodb_file_per_table = ON (valor por defecto en 8.x); la estructura de la tabla (columnas, índices) no ha cambiado desde que se tomó el backup. El servidor sigue en marcha.

Fases de la guía

• Instalación de XtraBackup — Añadir el repositorio de Percona · Instalar XtraBackup
• Usuario de backup y clave — Comprobar el plugin auth_socket · Crear el usuario de backup · Probar la conexión · Crear la clave de cifrado
• Script de backup y programación — Crear el directorio de backup · Escribir el script de backup · Hacer ejecutable el script · Tomar el primer backup full · Probar un backup incremental · Escribir el servicio systemd …
• Restauración — Copiar la cadena al directorio de trabajo · Descifrar / descomprimir · Preparar el backup full (prepare, apply-log-only) · Aplicar los incrementales en orden · Prepare final · Detener MySQL y apartar los datos existentes …
• Recuperación a un punto en el tiempo (PITR) — Determinar el momento objetivo · Aplicar los binlogs hasta el momento objetivo · Verificar el resultado y tomar un nuevo backup
• Limpieza — Borrar los datos apartados y el directorio de trabajo
• 1. Diagnóstico: ¿qué backup, qué método? — Comprobar el estado del servidor y las versiones · Listar las cadenas de backup y su contenido
• 2. Red de seguridad — Registrar el estado actual y la configuración
• 3. Aplicación: preparar el backup — Copiar la cadena al directorio de trabajo · Copiar la cadena al directorio de trabajo · Descifrar / descomprimir · Preparar el backup full (prepare, apply-log-only) · Aplicar los incrementales en orden · Prepare final
• 3. Aplicación: restaurar los datos — Detener MySQL y apartar los datos existentes · Copiar el backup al directorio de datos (copy-back) · Arrancar MySQL y verificar · Comprobar la configuración de replicación que viene del backup
• 3. Aplicación: aplicar los binlogs hasta el objetivo (PITR) — Verificar la transacción errónea y el punto objetivo · Aplicar los binlogs hasta el objetivo
• 4. Verificación — Verificar que la transacción errónea se ha deshecho · Verificar los datos
• 5. Después — Tomar un nuevo backup full · Borrar los datos apartados y el directorio de trabajo · Causa raíz y topología
• 1. Diagnóstico: ¿son adecuados la tabla y el backup? — Mostrar el estado actual y la estructura de la tabla · Listar las cadenas de backup y su contenido
• 2. Red de seguridad — Hacer backup del estado actual de la tabla
• 3. Aplicación: preparar el backup con --export — Copiar la cadena al directorio de trabajo · Descifrar / descomprimir · Preparar el backup full (prepare, apply-log-only) · Aplicar los incrementales en orden · Prepare final (--export)
• 3. Aplicación: importar la tabla en una tabla intermedia — Crear la tabla intermedia y descartar su tablespace · Copiar los archivos del backup e importarlos (IMPORT TABLESPACE)
• 4. Verificación — Comprobar la tabla intermedia y compararla con la tabla original
• 5. Después: copiar los datos y limpiar — Copiar las filas necesarias a la tabla original · Eliminar la tabla intermedia y borrar el directorio de trabajo
• 1. Diagnóstico: ¿son adecuados el servidor de destino y el backup? — Comprobar la versión, la identidad y el disco del servidor de destino · Listar las cadenas de backup y su contenido (…)
• 2. Red de seguridad — Registrar el estado actual y la configuración
• 3. Aplicación: traer y preparar el backup — Traer la cadena desde el servidor de backup · Copiar la cadena al directorio de trabajo · Descifrar / descomprimir · Preparar el backup full (prepare, apply-log-only) · Aplicar los incrementales en orden · Prepare final
• 3. Aplicación: restaurar los datos — Detener MySQL y apartar los datos existentes · Copiar el backup al directorio de datos (copy-back) · Arrancar MySQL y verificar · Comprobar la configuración de replicación que viene del backup
• 3. Aplicación: iniciar la replicación desde la posición del backup — Determinar el punto de partida · Configurar e iniciar la replicación
• 4. Verificación — Verificar los datos
• 5. Después — Borrar los datos apartados y el directorio de trabajo · Poner el servidor en servicio con su nuevo rol