Guerras de copias de seguridad MySQL vs MariaDB en un VPS: mysqldump frente a copias físicas

La verdadera pelea: tiempo de restauración, consistencia e I/O

La mayoría de los equipos discuten sobre backups como si fuera una disputa teológica: los dumps lógicos son portables frente a las copias físicas son rápidas. En un VPS, la pelea es más fea y práctica:

• Objetivo de tiempo de restauración (RTO): cuánto tiempo puedes estar caído mientras reconstruyes los datos.
• Objetivo de punto de recuperación (RPO): cuánto dato puedes perder (¿minutos? ¿horas?).
• Consistencia: si la copia puede restaurarse sin corrupción o relaciones faltantes.
• Impacto: si el tiempo de copia se convierte en “parada planificada” porque el I/O se satura.
• Fricción operativa: si alguien realmente prueba las restauraciones, porque el proceso es demasiado doloroso.

mysqldump gana en simplicidad y portabilidad. Las copias físicas ganan en velocidad y, cuando se hacen correctamente, en consistencia bajo carga. Pero en el almacenamiento de VPS—a menudo respaldado por red, con ráfagas y compartido—las copias físicas también pueden ser la forma más rápida de descubrir el techo de tu asignación de IOPS.

Aquí está la regla que uso en producción: Elige el método de copia que puedas restaurar rápida y repetidamente. Todo lo demás es trivia.

Hechos e historia que importan más de lo que crees

Estos no son datos curiosos para un trivial. Cada uno explica por qué un plan de copia “simple” se rompe a las 03:00.

1. MariaDB nació como un fork de MySQL tras la compra de Sun (y por tanto de MySQL). Esa historia de fork aún aparece en diferencias de herramientas y valores por defecto.
2. InnoDB se convirtió en el motor por defecto en MySQL 5.5. Muchos enfoques de backup asumen la recuperación por crash y los redo logs de InnoDB; MyISAM no juega el mismo juego.
3. XtraBackup de Percona popularizó las copias físicas en caliente para InnoDB. Modeló la expectativa: “una copia física debería ser online”.
4. MariaDB incluye MariaBackup (mariabackup), derivado de la línea XtraBackup, pero la compatibilidad de versiones importa más que los nombres de marketing.
5. MySQL 8 avanzó hacia GTIDs y replicación más estructurada. Eso cambia cómo piensas la recuperación punto en el tiempo y la retención de binlogs.
6. File-per-table (innodb_file_per_table) se volvió común, reduciendo el problema del “ibdata1 gigante”, pero también incrementando el churn de metadatos del sistema de archivos durante las copias.
7. El formato de redo log y los cambios del diccionario de datos hicieron que algunas restauraciones físicas entre versiones fueran dolorosas. Los dumps lógicos son más lentos, pero a menudo más tolerantes entre versiones mayores.
8. “SSD local” en VPS suele estar en realidad en red. Tu estrategia de backup debe asumir vecinos ruidosos y latencia variable.

Una idea parafraseada de Werner Vogels (fiabilidad/operaciones): Todo falla, todo el tiempo; diseña sistemas que asuman fallos y recuperen rápido. Ese es el espíritu para las copias también.

Tipos de copia en un VPS: lógicas, físicas y snapshots

Copias lógicas (mysqldump, mysqlpump)

Las copias lógicas exportan esquema y datos como SQL (o a veces en formatos delimitados). Ventajas:

• Portabilidad entre sistemas operativos/sistemas de archivos y, a menudo, entre versiones.
• Selectividad: una base de datos, una tabla, incluso filas filtradas (con dolor).
• Fácil de inspeccionar con herramientas estándar.

Contras:

• Lento para restaurar a escala.
• Genera I/O temporal y carga de CPU grandes; puede aplastar a un VPS pequeño.
• La consistencia depende del motor y de las banderas. Los valores por defecto no son tus amigos.

Copias físicas (mariabackup, xtrabackup, copia en crudo)

Las copias físicas copian los archivos reales de la base de datos más suficiente metadata/logs para hacerlos consistentes. Ventajas:

• Restauración rápida (copiar archivos + fase de prepare).
• Mejor para datasets InnoDB grandes.
• Pueden ser en caliente/online con las herramientas adecuadas.

Contras:

• Las restricciones de compatibilidad entre versiones pueden ser estrictas.
• Las herramientas pueden ser delicadas en distros “mínimas” de VPS.
• Las copias son menos legibles por humanos; la verificación es diferente.

Snapshots de sistema de archivos/bloque (LVM, ZFS)

Las snapshots no son copias de seguridad por sí mismas. Son un mecanismo de captura. Aún necesitas exportar los datos de la snapshot a otro lugar y tener un plan de restauración.

En un VPS, puede que tengas o no LVM o ZFS. Si las tienes, las snapshots pueden reducir el tiempo de inactividad (o evitarlo) al tomar una copia casi instantánea mientras MySQL está brevemente bloqueado o al menos vaciado.

MySQL vs MariaDB: herramientas de backup y aristas

A nivel de “API de backup”, MySQL y MariaDB se parecen: ambos hablan SQL, ambos tienen binlogs, ambos pueden volcar esquemas. Las diferencias prácticas aparecen en la madurez de las herramientas, el empaquetado y cuán estrictas son las versiones con las restauraciones físicas.

MariaDB: mariabackup suele ser la respuesta directa

Si ejecutas MariaDB y tus datos son mayormente InnoDB, mariabackup suele ser la elección física por defecto. Está diseñado como la herramienta “oficial” de copias en caliente y, en general, sigue las características de MariaDB.

MySQL: las copias físicas dependen de tu ecosistema

Oracle MySQL tiene un producto de backup empresarial, pero en el mundo real en flotas VPS verás:

• mysqldump (en todas partes, para bien o para mal)
• Percona XtraBackup (común, especialmente para cargas InnoDB pesadas)
• Snapshots donde el almacenamiento y la madurez operativa lo permitan

Compatibilidad cruzada: deja de asumir que “es básicamente lo mismo”

Los dumps lógicos suelen ser más portables entre MySQL y MariaDB que las copias físicas. Las copias físicas están casadas al formato en disco, implementaciones de redo/undo y comportamiento específico de versión. Si planeas migrar motores o versiones mayores, los dumps más binlogs (o cortes por replicación) suelen ser más seguros que intentar “levantar y mover” archivos crudos.

mysqldump: en qué es bueno y dónde te miente

mysqldump es la herramienta de backup equivalente a la cinta americana: no es bonita, no siempre es apropiada, pero está en todos los cajones. En un VPS pequeño, a menudo es el lugar menos malo para empezar porque es predecible y no requiere paquetes exóticos.

Usa mysqldump cuando

• Tu conjunto de datos es lo suficientemente pequeño para restaurar dentro de tu RTO.
• Necesitas portabilidad entre versiones o entre MySQL y MariaDB.
• Necesitas copias selectivas (bases de datos/tablas específicas).
• Puedes aceptar mayor CPU e I/O durante las ventanas de backup.

Ten cuidado con estos modos de fallo

• Copias inconsistentes si no usas las banderas adecuadas para InnoDB.
• Bloqueos de tablas (o locks de metadata) que detienen el tráfico de la app.
• Tiempos de restauración gigantes en un solo hilo que convierten incidentes en fines de semana largos.
• Objetos faltantes si olvidas rutinas, triggers, eventos o usuarios.

Chiste #1: Una copia que nunca probaste se llama “optimismo”, lo cual no es una clase de almacenamiento.

Consistencia del dump: las banderas que importan

Para bases de datos centradas en InnoDB, lo mínimo es --single-transaction. Pero eso por sí solo no es un campo de fuerza. Las transacciones de larga duración pueden inflar undo/redo y convertir tu dump en un accidente a cámara lenta.

Lo que normalmente uso en un VPS:

• --single-transaction para la consistencia de InnoDB sin locks globales.
• --routines --triggers --events para capturar las partes que no son tablas.
• --set-gtid-purged=OFF en muchos entornos mixtos para evitar sorpresas con GTID (caso por caso).
• --hex-blob para evitar daños en la codificación.
• --master-data=2 (o al menos coordenadas de binlog) si quieres PITR.

Copias físicas: mariabackup, xtrabackup y copias en crudo

Las copias físicas consisten en copiar páginas InnoDB más los logs necesarios para hacerlas consistentes. La promesa: la restauración es rápida porque no estás reproduciendo SQL; estás restaurando archivos y dejando que InnoDB haga una reconciliación al estilo de recuperación por crash.

mariabackup (MariaDB)

mariabackup puede hacer copias en caliente de InnoDB e incluye un paso de “prepare” para aplicar los redo logs. También puede hacer streaming y compresión, lo cual importa en redes de VPS y discos pequeños.

xtrabackup (común en ecosistemas MySQL)

XtraBackup es la mula de carga para copias físicas en caliente en muchas empresas. El modelo operativo es similar: backup → prepare → restore (copy-back) → arreglar permisos → arrancar el servidor.

Copias en crudo: sólo con las guardas adecuadas

Copiar /var/lib/mysql con rsync mientras MySQL está en ejecución es la forma de fabricar copias corruptas. La única vez que las copias en crudo tienen sentido es cuando puedes garantizar la consistencia a nivel de sistema de archivos (snapshot) o detienes MySQL limpiamente.

Chiste #2: “Voy a rsync el datadir en caliente” es el equivalente en bases de datos a “voy a hacer malabares con cuchillos para ahorrar tiempo”.

Dolor específico en VPS: ráfagas I/O y vecinos ruidosos

Las copias físicas pueden consumir muchísimo I/O. Eso no es inherentemente malo—hasta que tu almacenamiento en VPS te limita. El resultado parece un problema de base de datos pero en realidad es una limitación de la plataforma: alto iowait, queries detenidos, lag de replicación y copias que tardan más cuanto más las “optimizas”.

En VPS, planifica para limitaciones: reduce la concurrencia de backup, comprime con cuidado (trade-off CPU vs I/O) y ejecuta con ionice/nice cuando corresponda.

Binlogs: la diferencia entre “copia” y “recuperación”

Una copia completa nocturna no es una estrategia de recuperación si tu RPO es menor a 24 horas. Los binlogs son la forma más sencilla de cubrir ese hueco: restauras la última copia completa y luego reproduces los binlogs hasta un timestamp/posición/GTID.

En un VPS, los binlogs también son la forma de evitar hacer dumps completos con demasiada frecuencia. Las copias completas son pesadas; la recuperación incremental mediante binlogs es barata en comparación.

Guía práctica

• Habilita binlogs si te importa PITR.
• Dimensiona la retención según cuánto tiempo te toma notar datos malos y reaccionar.
• Haz copias de binlogs fuera del host. La retención local no es una copia de seguridad; es una comodidad.
• Practica una recuperación PITR. Siempre es más extraña de lo que esperas.

Tareas prácticas: 14 comandos, salidas y decisiones

Estos son los chequeos que realmente ejecuto en sistemas VPS. Cada tarea incluye: comando, salida de ejemplo, qué significa la salida y qué decisión tomas después.

Task 1: Confirmar qué servidor estás ejecutando

cr0x@server:~$ mysql -e "SELECT VERSION() AS version, @@version_comment AS comment\G"
*************************** 1. row ***************************
version: 10.11.6-MariaDB-0+deb12u1
comment: Debian 12

Significado: Versión y empaquetado de la distro. Esto importa para la compatibilidad de copias físicas y los valores por defecto.

Decisión: Si es MariaDB, preferir mariabackup. Si es MySQL 8, revisar si usarás mysqldump, snapshots o XtraBackup.

Task 2: Comprobar tamaño de datos y distribución de archivos

cr0x@server:~$ sudo du -sh /var/lib/mysql
18G	/var/lib/mysql

Significado: Tamaño aproximado de la huella de restauración.

Decisión: Si esto es >10–20 GB en un VPS pequeño, los dumps restaurarán lentamente. Empieza a planear copias físicas o al menos flujos de restauración más rápidos (importación paralela, instancia mayor para restaurar, etc.).

Task 3: Identificar mezcla de motores (InnoDB vs MyISAM)

cr0x@server:~$ mysql -e "SELECT ENGINE, COUNT(*) tables FROM information_schema.tables WHERE table_schema NOT IN ('mysql','information_schema','performance_schema','sys') GROUP BY ENGINE;"
ENGINE		tables
InnoDB		312
MyISAM		4

Significado: --single-transaction protege la consistencia de InnoDB; MyISAM puede seguir requiriendo locks para dumps consistentes.

Decisión: Si tienes tablas MyISAM que te importan, acepta locks durante el dump o migra a InnoDB.

Task 4: Verificar ajustes de binlog y GTID

cr0x@server:~$ mysql -e "SHOW VARIABLES LIKE 'log_bin'; SHOW VARIABLES LIKE 'gtid_mode'; SHOW VARIABLES LIKE 'server_id';"
Variable_name	Value
log_bin		ON
Variable_name	Value
gtid_mode	OFF
Variable_name	Value
server_id	1

Significado: Binlogs habilitados, GTIDs desactivados (común en MariaDB o MySQL antiguo), server_id configurado.

Decisión: Si log_bin=OFF y necesitas PITR, actívalo (con planificación de disco). Si GTIDs están activos, ajusta las banderas de dump y los pasos de recuperación correspondientemente.

Task 5: Obtener la posición actual de binlog para anclar PITR

cr0x@server:~$ mysql -e "SHOW MASTER STATUS\G"
*************************** 1. row ***************************
File: binlog.000214
Position: 90123318
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set:

Significado: Esta es tu “línea de salida” para reproducir si tomas una snapshot o copia física ahora mismo.

Decisión: Registra esto con la metadata del backup. Si no puedes ligar las copias a coordenadas de binlog (o conjunto GTID), PITR se convierte en adivinanza.

Task 6: Medir presión de I/O durante ventanas de backup

cr0x@server:~$ iostat -xz 1 3
Linux 6.1.0 (server) 	12/31/2025 	_x86_64_	(2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.21    0.00    2.33   41.18    0.72   49.56

Device            r/s     w/s   rkB/s   wkB/s  aqu-sz  await  %util
vda              9.00  210.00  512.0  6144.0   12.40  58.30  99.80

Significado: 40%+ de iowait, 99% de utilización del disco y await alto. Esto es saturación de almacenamiento, no “SQL lento”.

Decisión: Limitar backups, mover el destino de backup fuera del host, programar de otra manera o mejorar disco/clase de I/O. También considerar copias físicas con paralelismo controlado frente a enormes escrituras de dumps lógicos.

Task 7: Ver si las copias están bloqueadas por locks de metadata

cr0x@server:~$ mysql -e "SHOW PROCESSLIST;"
Id	User	Host	db	Command	Time	State	Info
42	root	localhost	NULL	Query	12	Waiting for table metadata lock	FLUSH TABLES WITH READ LOCK
87	app	10.0.2.10:51234	prod	Query	12	Sending data	SELECT ...

Significado: Un paso de backup que bloquea está esperando, probablemente bloqueado por DDL o una query larga.

Decisión: Evitar FTWRL para rutas críticas. Preferir --single-transaction para dumps y copias físicas en caliente para InnoDB. Si debes bloquear, programa una ventana de congelación de DDL.

Task 8: Ejecutar un mysqldump relativamente seguro con mínimos fallos

cr0x@server:~$ mysqldump --single-transaction --routines --triggers --events --hex-blob --master-data=2 --databases prod | gzip -1 > /backups/prod.sql.gz
cr0x@server:~$ ls -lh /backups/prod.sql.gz
-rw-r--r-- 1 root root 1.9G Dec 31 02:14 /backups/prod.sql.gz

Significado: Copia creada. El tamaño te da una pista sobre el tiempo de restauración y la relación de compresión. --master-data=2 inserta coordenadas de binlog como comentario.

Decisión: Si esto tarda demasiado o degrada el rendimiento, pasa a copias físicas y/o ejecuta dumps desde una réplica.

Task 9: Validar que el dump incluye lo que crees que incluye

cr0x@server:~$ zgrep -m1 -E "MASTER_LOG_FILE|CHANGE MASTER" /backups/prod.sql.gz
-- CHANGE MASTER TO MASTER_LOG_FILE='binlog.000214', MASTER_LOG_POS=90123318;

Significado: Las coordenadas de binlog están registradas.

Decisión: Si faltan, no puedes hacer un PITR limpio desde este dump. Corrige las banderas y vuelve a ejecutar.

Task 10: Crear una copia física con mariabackup (MariaDB)

cr0x@server:~$ sudo mariabackup --backup --target-dir=/backups/mariabackup/full --user=backup --password='***'
[00] 2025-12-31 02:10:11 Backup created in directory '/backups/mariabackup/full'
[00] 2025-12-31 02:10:11 Writing backup-my.cnf
[00] 2025-12-31 02:10:11 Completed OK!

Significado: Archivos crudos más metadata capturada.

Decisión: Ejecutar inmediatamente el prepare. Una copia física sin preparar no está lista para restaurar.

Task 11: Preparar la copia física (aplicar redo logs)

cr0x@server:~$ sudo mariabackup --prepare --target-dir=/backups/mariabackup/full
[00] 2025-12-31 02:13:52 Starting to apply redo log
[00] 2025-12-31 02:14:20 Redo log applied
[00] 2025-12-31 02:14:20 Completed OK!

Significado: La copia ya es consistente y está lista para el copy-back.

Decisión: Si el prepare es lento, estás limitado por I/O; considera discos más rápidos para staging de backup o descargar el prepare a un host de restauración.

Task 12: Inspeccionar la salud de InnoDB y la presión de checkpoints

cr0x@server:~$ mysql -e "SHOW ENGINE INNODB STATUS\G" | sed -n '1,60p'
=====================================
2025-12-31 02:15:02 INNODB MONITOR OUTPUT
=====================================
...
Log sequence number          128392001928
Log flushed up to            128392001928
Last checkpoint at           128391771200
...

Significado: Si el checkpoint se atrasa mucho, las copias y las escrituras pesadas pueden crear presión de recovery/flush.

Decisión: Si ves retraso crónico en checkpoints, ajusta el tamaño del redo log (específico de motor/versión), el buffer pool y el comportamiento de flush; además evita ejecutar copias en picos de escritura.

Task 13: Comprobar lag de replicación (si haces backups desde una réplica)

cr0x@server:~$ mysql -e "SHOW SLAVE STATUS\G" | egrep "Seconds_Behind_Master|Slave_IO_Running|Slave_SQL_Running"
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 57

Significado: La réplica tiene un retraso de ~1 minuto.

Decisión: Si el lag es aceptable dentro de tu RPO, tomar backups desde la réplica reduce la carga en producción. Si el lag sube durante la copia, estás saturando I/O o CPU; limita.

Task 14: Hacer un ensayo de restauración en la misma máquina (chequeo de cordura)

cr0x@server:~$ zcat /backups/prod.sql.gz | head -n 20
-- MySQL dump 10.13  Distrib 8.0.36, for Linux (x86_64)
--
-- Host: localhost    Database: prod
-- ------------------------------------------------------
-- Server version	10.11.6-MariaDB-0+deb12u1
...

Significado: Verificas que puedes leer la copia y que contiene encabezados esperados. Esto no es una prueba completa, pero detecta errores de “archivo vacío” o “objetivo equivocado”.

Decisión: Programa una prueba real de restauración a una instancia desechable. Si nunca la haces, aprenderás durante un incidente cuando la adrenalina te haga escribir mal.

Guía de diagnóstico rápido: encuentra el cuello de botella en minutos

Cuando las copias son lentas o la app se cae durante las copias, no empieces cambiando herramientas de backup. Empieza por averiguar qué recurso estás agotando.

Primero: demuestra si es saturación de almacenamiento

• Comprueba iowait y await del disco (iostat -xz). Await alto y %util cerca de 100% significa que estás limitado por I/O.
• Revisa espacio de filesystem y presión de inodos (df -h, df -i).
• Comprueba si el VPS te está limitando IOPS (síntoma: paradas periódicas, rendimiento en sierra).

Qué hacer luego: limitar compresión/paralelismo, mover destino de backup fuera del disco principal, o mejorar la clase de almacenamiento del VPS. Si no puedes, usa una réplica para backups.

Segundo: revisar locks y transacciones largas

• SHOW PROCESSLIST para locks de metadata.
• Estado del motor para listas históricas largas / purge lag (InnoDB).
• Buscar DDL ejecutándose durante las copias.

Qué hacer luego: programar copias fuera de ventanas de migraciones, exigir ventanas de DDL y evitar enfoques basados en FTWRL a menos que toleres paradas.

Tercero: comprobar contención de CPU (compresión y dumps monocola)

• Revisar top o pidstat para mysqldump y gzip consumiendo CPU.
• En VPS muy pequeños, el nivel de compresión es un ajuste de producción.

Qué hacer luego: bajar nivel de compresión, comprimir fuera del host o cambiar a copias físicas por streaming con CPU controlada.

Cuarto: comprobar red (backups fuera del host y streaming)

• Si transmites copias a object storage u otro nodo, confirma que el throughput es estable.
• Pérdida de paquetes y retransmisiones convierten “backup por streaming” en “limitador accidental”.

Errores comunes: síntoma → causa raíz → solución

1) La copia tiene éxito, la restauración falla con rutinas/triggers faltantes

Síntoma: Errores de la app tras restaurar: procedimientos almacenados faltantes, triggers que no se ejecutan, eventos programados desaparecidos.

Causa raíz: El dump se ejecutó sin --routines --triggers --events.

Solución: Añadir las banderas, volver a ejecutar backups y probar la restauración. También incluir los objetos del sistema mysql si dependes de usuarios/privilegios.

2) mysqldump provoca paradas en producción

Síntoma: Queries se cuelgan; ves “Waiting for table metadata lock”.

Causa raíz: DDL durante el dump, o opciones de dump que fuerzan locks (o tablas MyISAM).

Solución: Imponer ventanas de migración, convertir MyISAM, usar --single-transaction y considerar tomar backups desde una réplica.

3) La copia física restaura pero InnoDB no arranca

Síntoma: MySQL/MariaDB no arranca tras el copy-back; InnoDB se queja de archivos de logs o del diccionario de datos.

Causa raíz: Incompatibilidad de versiones, paso de prepare omitido, permisos incorrectos, o mezclar archivos de diferentes servidores.

Solución: Asegurar que la versión de la herramienta de backup coincide con las expectativas de la versión del servidor, ejecutar prepare, usar la propiedad correcta (mysql:mysql) y restaurar todo el datadir de forma consistente.

4) Las copias son “rápidas” pero el lag de replicación explota

Síntoma: Seconds_Behind_Master crece durante la ventana de backup.

Causa raíz: El I/O del backup compite con la aplicación de replicación; el disco del VPS alcanza el tope de IOPS.

Solución: Limitar el backup, cambiar el horario, mover backups a otro disco/volumen o mejorar la clase de I/O. Si es posible, poner los relay logs en almacenamiento separado.

5) Puedes restaurar, pero toma una eternidad y las aplicaciones caducan

Síntoma: La restauración desde dump corre por horas; las aplicaciones timeout siguen incluso después de que la BD esté “arriba”.

Causa raíz: La restauración lógica es relativamente mono-hilo, reconstrucción de índices, buffer pool frío y estás en un VPS pequeño.

Solución: Preferir restauraciones físicas para datasets grandes; si no, restaurar en una instancia temporal más grande, calentar cachés y solo entonces cortar al entorno de producción.

6) “Tenemos backups,” pero están en el mismo VPS

Síntoma: El disco del VPS muere; las copias mueren con él.

Causa raíz: Almacenamiento de backups local únicamente.

Solución: Copias fuera del host. Dominio de fallo diferente. Siempre.

7) Las snapshots restauran datos inconsistentes

Síntoma: La BD restaurada tiene corrupción o faltan commits recientes.

Causa raíz: Snapshot tomada sin vaciar/bloquear apropiadamente; capturaste una vista de crash en progreso sin cobertura de redo.

Solución: Emparejar snapshots con coordinación de MySQL (flush, estrategia de lock apropiada al motor), o usar herramientas de copia física en caliente que incluyan pasos de redo/prepare.

Tres micro-historias corporativas desde las trincheras de backups

Micro-historia 1: El incidente causado por una suposición equivocada

Eran un SaaS de tamaño medio en un solo VPS “potente”. Las copias eran un mysqldump nocturno a un segundo disco montado en /backups. El equipo se sentía responsable. Incluso tenían retención: siete días. Esa es la parte que siempre suena reconfortante en las reuniones.

Entonces el proveedor tuvo un evento de almacenamiento. La instancia se reinició, volvió y MySQL no arrancó. Su respuesta fue calmada: “No hay problema, restaure desde anoche”. Excepto que el disco de backups era el mismo dispositivo de bloque virtual en el mismo almacenamiento subyacente. Estaba adjunto, pero el sistema de archivos estaba destruido. Los archivos de backup existían de la misma manera que un edificio demolido “existe”.

La suposición equivocada fue sutil: creyeron que un segundo volumen montado era un segundo dominio de fallo. En ese proveedor, no lo era. Era sólo otra porción del mismo pool subyacente. El postmortem no fue dramático. Fue peor: silenciosamente humillante y completamente evitable.

La solución fue aburrida: las copias se empujaron fuera del host tras la creación y las restauraciones se ensayaron mensualmente en una instancia desechable. También empezaron a registrar dónde vivían los datos en términos del proveedor—región, pool y tipo de adjunción—porque “volumen” puede significar cualquier cosa en el mundo VPS.

Micro-historia 2: La optimización que salió mal

Otra compañía quiso backups más rápidos. Pasaron de dumps a copias físicas con compresión por streaming. El ingeniero que lo hizo era competente y agresivo, el mejor tipo hasta que deja de serlo. Habilitaron hilos paralelos y subieron la compresión porque el almacenamiento era “costoso”. En papel se veía genial: copias más pequeñas, transferencia más rápida, menos dinero.

En producción, el VPS tenía dos vCPU. La compresión empezó a devorar la CPU como si le debieran dinero. MySQL empezó a competir por CPU, luego por I/O porque el backup leía agresivamente del datadir. La latencia subió. El lag de replicación creció. Sus workers de cola hicieron timeout. Incidente declarado.

La lección dolorosa: “backup más rápido” puede significar “consumir más rápido tus recursos”. La optimización era localmente racional y globalmente desastrosa. En un VPS no hay CPU “extra” escondida tras una cortina.

La solución fue medida: redujeron el paralelismo, bajaron el nivel de compresión y ejecutaron backups desde una réplica con CPU algo mayor. También introdujeron limitación de I/O y dejaron de intentar que los backups fueran gratis. Las copias cuestan recursos. Tú decides dónde pagar: durante las ventanas de backup, durante las restauraciones o durante incidentes.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Un equipo hizo algo poco moderno: ensayos trimestrales de restauración completa. No un ejercicio de mesa. Una restauración real en una VM limpia, la aplicación apuntada a ella, consultas básicas de integridad ejecutadas y una persona firmando la aprobación. Nadie se jactaba porque no es un diagrama arquitectónico llamativo.

Entonces un despliegue introdujo una migración destructiva. Eliminó una columna y el ORM felices escribió nulos al universo. Lo notaron en una hora. La pregunta no fue si tenían backups—fue cuán rápido podían rebobinar sin perder las escrituras legítimas posteriores al despliegue.

Restauraron la copia de anoche en un host de pruebas, reprodujeron binlogs hasta cinco minutos antes del timestamp del despliegue y exportaron solo las tablas afectadas de vuelta a producción. Fue algo sucio, pero controlado. El equipo conocía los pasos porque practicaban ese músculo cuando no había fuego.

Siguieron escribiendo un postmortem y mejoraron las revisiones de migraciones. Pero la razón real por la que no fue un desastre de varios días fue que su proceso de backups era ensayado, documentado y aburrido. En operaciones, lo aburrido es una característica.

Listas de verificación / plan paso a paso

Paso a paso: elegir tu enfoque de backup en un VPS

1. Mide el tamaño del dataset (datadir y tamaño lógico). Si restaurar desde SQL excede el RTO, prioriza lo físico.
2. Confirma la mezcla de motores. Si es mayormente InnoDB, herramientas físicas en caliente son viables; si hay MyISAM significativo, planifica locks o migración.
3. Decide tu RPO. Si necesitas <24h de pérdida de datos, habilita y retén binlogs fuera del host.
4. Elige tu backup primario completo:
   • BD pequeña: mysqldump + binlogs está bien.
   • BD mediana/grande: mariabackup/xtrabackup + binlogs.
5. Elige el mecanismo de captura:
   • Backup basado en herramienta (recomendado para InnoDB).
   • Snapshot + coordinación (solo si puedes hacerlo correctamente).
6. Selecciona almacenamiento fuera del host. Dominio de fallo diferente. Encriptar si hace falta.
7. Escribe un runbook de restauración con comandos, tiempos esperados y consultas de validación.
8. Programa simulacros de restauración al menos trimestralmente. Mensual si tu BD es crítica para el negocio.

Checklist operativa: todo trabajo de backup debe hacer esto

• Escribir metadata del backup (versión del servidor, archivo/pos de binlog o conjunto GTID, timestamp, versión de la herramienta).
• Verificar integridad de archivos (checksum) después de la transferencia.
• Alertar en fallos y en duraciones/tamaños inusuales.
• Mantener la retención alineada al tiempo de detección (cuánto tardas en notar corrupción o borrados malos).
• Probar la viabilidad de restauración mediante simulacros periódicos.

Checklist de validación de restauración (mínimo)

• El servidor arranca limpiamente; la recuperación de InnoDB finaliza.
• Los recuentos de filas coinciden para tablas clave (aproximado está bien como primer paso).
• Los índices críticos existen; el estado de migraciones es correcto.
• La aplicación puede autenticarse y ejecutar sus 3 workflows principales.
• La replicación (si se usa) puede restablecerse desde el estado restaurado.

Preguntas frecuentes

1) ¿Es mysqldump “suficiente” para producción?

Sí, si tu base de datos es pequeña, toleras el tiempo de restauración y lo ejecutas con las banderas correctas. No, si el tiempo de restauración se mide en horas y tu negocio mide el downtime en minutos.

2) ¿Cuál es la bandera más importante de mysqldump para InnoDB?

--single-transaction. Te da una vista consistente sin bloquear tablas (para InnoDB). No resuelve la consistencia de MyISAM y aún puede estresar undo/redo si hay transacciones largas.

3) ¿Puedo hacer backup copiando /var/lib/mysql mientras MySQL corre?

No de forma segura, a menos que uses un método de snapshot coordinado que garantice consistencia, o detengas MySQL. El rsync en vivo del datadir es una forma clásica de obtener backups que restauran en tristeza.

4) ¿Debería comprimir las copias en el VPS?

A veces. La compresión intercambia CPU por I/O y red. En VPS pequeños, usa niveles de compresión bajos y mide. Si la contención de CPU causa picos de latencia, comprime fuera del host o comprime menos.

5) ¿Las copias físicas reemplazan a los binlogs?

No. Las copias físicas te dan un punto de restauración completo rápido. Los binlogs te dan recuperación punto-en-tiempo entre copias completas. Si necesitas RPO bajo, quieres ambos.

6) ¿Las copias físicas son portables entre MySQL y MariaDB?

Generalmente no. Las copias físicas están ligadas a formatos en disco y versiones. Los dumps lógicos son la opción portable para movimientos entre motores, aunque son más lentos.

7) ¿Debo tomar backups desde una réplica?

Sí si puedes. Reduce la carga en la primaria y te da un lugar más seguro para lecturas pesadas. Pero vigila el lag de replicación: una réplica con retraso puede violar silenciosamente tu RPO.

8) ¿Con qué frecuencia debo probar restauraciones?

Al menos trimestralmente para bases “importantes”, mensual para las críticas para el negocio, y después de upgrades mayores o cambios en las herramientas de backup. Probar restauraciones es cómo conviertes archivos de backup en capacidad de recuperación.

9) ¿Cuál es el método de restauración más rápido en un VPS?

La restauración física (backup preparado + copy-back) típicamente es la más rápida para datasets InnoDB. El factor limitante real suele ser el throughput del disco en la restauración, no la elegancia de la herramienta.

10) ¿Cómo sé si mi cuello de botella es CPU, disco o locks?

Disco: alto iowait/await/%util en iostat. CPU: procesos de backup/compresión pegando cores en top. Locks: esperas de metadata lock en SHOW PROCESSLIST.

Siguientes pasos: qué hacer esta semana

• Decidir RTO/RPO por escrito. Si no puedes definirlos, no puedes elegir racionalmente entre dump y copias físicas.
• Activar binlogs (si necesitas PITR) y planificar retención fuera del host.
• Ejecutar Task 2 y Task 6 en tu VPS durante una ventana de backup. Si saturas I/O, deja de adivinar y empieza a limitar o mover backups fuera del disco principal.
• Si usas MariaDB y el dataset es mediano/grande: implementar mariabackup + prepare + copia fuera del host, capturando metadata con coordenadas de binlog.
• Si te quedas con mysqldump: estandariza banderas, captura coordenadas de binlog y realiza un ensayo de restauración completa a una VM limpia.
• Programar una prueba de restauración y hacerla responsabilidad recurrente de alguien, no un acto heroico.

Las copias no tratan sobre la copia. Tratan sobre la restauración. Construye la restauración que deseas, luego haz copias de la forma que haga que esa restauración sea aburrida.