MariaDB vs Percona Server: velocidad de respaldo/recuperación en una VPS pequeña

La respuesta práctica (quién gana)

En una VPS pequeña, la velocidad de respaldo/recuperación está dominada por tu cuello de botella: normalmente la I/O del disco, a veces la CPU (compresión/criptografía), ocasionalmente la red (almacenamiento remoto) y con frecuencia “tu proceso” (herramienta equivocada o suposiciones incorrectas).

Si comparas MariaDB + mariabackup frente a Percona Server + xtrabackup sobre el mismo conjunto de datos InnoDB y una configuración similar, el “ganador” rara vez es la distribución del servidor. La diferencia suele ser más bien:

• Qué herramienta de respaldo físico estás usando realmente y su compatibilidad con la versión del servidor.
• Cuánto redo debe aplicarse durante el prepare y cuán duro tu VPS limita escrituras aleatorias.
• Elección del algoritmo de compresión (ligado a CPU) frente a “sin compresión” (ligado a I/O).
• Método de restauración: copia de archivos vs streaming vs importación lógica.

Mi opinión operativa: para restauraciones en VPS pequeñas, Percona XtraBackup tiende a ser la opción más predecible “lo suficientemente rápida” cuando estás en el ecosistema MySQL/Percona y quieres respaldos físicos con buenas herramientas para streaming e incrementales. Para entornos MariaDB, mariabackup es la herramienta adecuada y puede ser igual de rápida, pero debes mantener la alineación entre versiones de MariaDB y entender qué hace el “prepare” en tu disco limitado.

Si estás haciendo respaldos lógicos (mysqldump), el “ganador” no es ninguno: ya perdiste, solo que aún no lo has notado. Las restauraciones lógicas en VPS pequeñas son donde el tiempo desaparece.

Hechos interesantes y contexto histórico (porque el pasado explica el presente)

1. MariaDB existe por la adquisición de MySQL por Oracle (era 2009–2010); Monty Widenius y otros bifurcaron MySQL para mantener el desarrollo abierto y dirigido por la comunidad.
2. Percona construyó un negocio sobre el dolor operativo: su servidor y herramientas se centraron desde temprano en diagnósticos de rendimiento, instrumentación y valores por defecto sensatos para producción.
3. XtraBackup se convirtió en la herramienta de respaldo físico “en caliente” de facto para MySQL/Percona durante años porque evitaba bloqueos globales largos y no requería complementos empresariales costosos.
4. mariabackup de MariaDB es una línea fork de XtraBackup, creada para soportar las internals divergentes de MariaDB y evitar trampas de compatibilidad.
5. El modelo de recuperación de InnoDB (redo logs + páginas sucias) es la razón por la que los respaldos físicos requieren una fase de “prepare”: básicamente estás reproduciendo el redo para hacer la copia consistente.
6. Los tablespaces de undo y el comportamiento de ibdata cambiaron con los años; diseños más nuevos pueden hacer las restauraciones más predecibles pero también más fáciles de malconfigurar al mover entre hosts.
7. La compresión en herramientas de respaldo pasó de “agradable” a “obligatoria” cuando la gente empezó a enviar copias a almacenamiento de objetos; eso convirtió muchas restauraciones de I/O-limitadas a CPU-limitadas en máquinas pequeñas.
8. “Flush tables with read lock” fue una vez parte normal de los scripts de backup; ahora es una señal de que haces respaldos lógicos o que no has actualizado tu playbook en una década.
9. Los proveedores de VPS pequeños a menudo limitan la I/O sostenida de formas que no aparecen en benchmarks de ráfaga; tu primer minuto es rápido, los siguientes diez son trágicos.

Qué controla realmente la velocidad de respaldo/recuperación en una VPS

1) El patrón de I/O vence al rendimiento bruto

Restaurar un respaldo físico no es solo “copiar archivos”. Es: copiar archivos, luego aplicar redo (escrituras aleatorias), luego arrancar InnoDB que puede hacer más recuperación, luego reconstruir cachés y estadísticas cuando tu carga vuelve.

En el almacenamiento de VPS pequeño, el rendimiento secuencial puede parecer aceptable, pero el IOPS de escritura aleatoria es donde yacen los cadáveres. La fase de aplicar redo y el calentamiento posterior son intensivos en IOPS. Ahí es donde “la restauración tardó 7 minutos la última vez” se convierte en “la restauración tardó 45 minutos hoy” después de que tu proveedor movió silenciosamente tu disco virtual a otro backend.

2) CPU: la compresión y la encriptación no son gratis

La compresión del respaldo es seductora: archivos más pequeños, subidas más rápidas. En una VPS de dos núcleos también es un impuesto de rendimiento que pagas dos veces: una en el respaldo y otra en la restauración. Si tu pipeline de restauración incluye descomprimir + prepare + copy-back, has montado un triatlón de CPU en una máquina que jadeará al descomprimir logs.

3) Memoria: el buffer pool no acelera directamente la restauración, pero cambia el comportamiento de recuperación

Más RAM ayuda al servidor a comportarse mejor después de la restauración (menos lecturas, calentamiento más rápido), pero la velocidad bruta de restauración trata mayormente de escrituras en disco y aplicar redo. Aun así: un buffer pool demasiado pequeño puede hacer que el periodo “el sistema está arriba pero inutilizable” sea más largo, lo que es funcionalmente lo mismo que una restauración lenta.

4) Alineación de versiones es el asesino silencioso

Percona Server y MariaDB son compatibles con muchas convenciones de MySQL, pero los respaldos físicos son sensibles a formatos internos y a las versiones de las herramientas. Un desajuste entre herramienta y servidor puede forzarte a una restauración lógica, que es el pivote más lento posible durante un incidente.

Idea parafraseada de Werner Vogels (CTO de Amazon): todo falla todo el tiempo, así que diseñas sistemas asumiendo que la falla es normal. Las restauraciones son la parte de “asumir que la falla es normal” que o practicas, o no.

Métodos de respaldo que importan (físico vs lógico)

Respaldos lógicos: portables, lentos y llenos de sorpresas

mysqldump es una exportación de texto. Es útil cuando necesitas portabilidad entre versiones, o cuando exportas un subconjunto. También es el equivalente de respaldo de imprimir la base de datos, enviártela por fax y luego volver a teclearla más tarde.

El rendimiento de la restauración depende del parseo SQL, la creación de índices y la sobrecarga de transacciones. En una VPS pequeña, eso suele ser horas para conjuntos de datos no triviales. Si necesitas tiempos de restauración rápidos, usa dumps lógicos solo para bases de datos pequeñas o para recuperación de “último recurso”.

Respaldos físicos: la restauración más rápida cuando se hacen bien

Las herramientas de respaldo físico (mariabackup, xtrabackup) copian archivos de datos InnoDB y logs mientras el servidor está en ejecución, luego “preparan” el respaldo a un punto consistente. La restauración es básicamente copiar archivos de vuelta más la recuperación del servidor. En una VPS pequeña, este es el único enfoque que escala sin convertirte en un arqueólogo a tiempo parcial de viejos dumps SQL.

Qué significa realmente “prepare”

Durante --prepare, la herramienta aplica los redo logs capturados durante el respaldo para llevar los archivos a un estado consistente. Si tu carga fue intensa, el backlog de redo puede ser grande. Un backlog grande significa más escrituras aleatorias. Las escrituras aleatorias en discos de VPS significan dilatación temporal.

Chiste #1: Los respaldos son como paracaídas: si necesitas uno y no funciona, probablemente no volverás a necesitarlo.

Guía rápida de diagnóstico

Cuando la restauración es lenta en una VPS pequeña, no tienes tiempo para debatir religiones. Necesitas una lista corta y un orden de operaciones implacable.

Primero: confirma qué fase es lenta

• Descarga/transferencia (red, limitación del almacenamiento remoto, sobrecarga de cifrado)
• Descompresión/descifrado (ligado a CPU)
• Prepare/aplicar-log (ligado a IOPS de escritura aleatoria)
• Copy-back (principalmente ligado a escrituras secuenciales)
• Primer arranque (recuperación InnoDB, permisos, desajuste de configuración)

Segundo: identifica tu límite duro (disco vs CPU vs red)

• Disco con alta utilización y bajo rendimiento: estás limitado por IOPS.
• CPU al máximo durante descompresión/prepare: elige otra compresión o más núcleos.
• Red saturada pero CPU/disco inactivos: haz streaming en pipeline o elige un almacenamiento más cercano.

Tercero: aplica el cambio más pequeño que mueva la aguja

• Desactiva la compresión (o elige un algoritmo más ligero) si estás limitado por CPU.
• Reduce el volumen de redo mejorando el horario de backups o la estrategia de flush si el prepare es lento.
• Usa I/O directo y un paralelismo sensato si el copy-back es lento.
• Deja de hacer restauraciones lógicas para conjuntos grandes.

Tareas prácticas: comandos, salidas y decisiones (la parte que salva tu fin de semana)

Estos son chequeos realistas que puedes ejecutar en una VPS Linux. El objetivo no es coleccionar trivia; es tomar una decisión después de cada comando.

Tarea 1: Identifica qué estás ejecutando realmente (MariaDB vs Percona vs Oracle MySQL)

cr0x@server:~$ mysql --version
mysql  Ver 15.1 Distrib 10.11.6-MariaDB, for debian-linux-gnu (x86_64) using  EditLine wrapper

Qué significa: Esto es MariaDB 10.11.x. Deberías preferir mariabackup para respaldos físicos.

Decisión: Si planeabas usar XtraBackup, detente y confirma compatibilidad. El desajuste de herramienta es un auto-boicot común.

Tarea 2: Confirma Percona Server (si crees que lo instalaste)

cr0x@server:~$ mysqld --version
mysqld  Ver 8.0.35-27 for Linux on x86_64 (Percona Server (GPL), Release 27, Revision 1f4b4a6)

Qué significa: Percona Server para MySQL 8.0. XtraBackup es la pareja natural.

Decisión: Usa xtrabackup que coincida con la versión mayor. No improvises con paquetes antiguos.

Tarea 3: Comprueba el tipo de disco y las opciones de montaje (la velocidad de restauración vive aquí)

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,ROTA,MOUNTPOINT,FSTYPE
NAME   TYPE SIZE ROTA MOUNTPOINT FSTYPE
vda    disk  80G    0
├─vda1 part  79G    0 /          ext4
└─vda15 part  1G    0 /boot/efi  vfat

Qué significa: ROTA=0 sugiere almacenamiento respaldado por SSD (o al menos presentado así).

Decisión: Si ROTA=1 o estás en almacenamiento en bloque en red, espera dolor por escrituras aleatorias; planifica minimizar el tiempo de prepare/aplicar-log y evita compresión pesada.

Tarea 4: Comprueba si el proveedor está limitando tu disco (rápido y sucio)

cr0x@server:~$ iostat -xm 1 5
Linux 6.1.0-18-amd64 (server) 	12/30/2025 	_x86_64_	(2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.20    0.00    4.60   52.40    0.30   36.50

Device            r/s     rkB/s   rrqm/s  %rrqm  r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm  w_await wareq-sz  aqu-sz  %util
vda              4.00    120.0     0.00   0.00    8.50    30.00   220.0   22000.0    15.00   6.38  130.00   100.00   30.20  99.80

Qué significa: El disco está ~100% de utilización y write await es enorme. Estás limitado por I/O; el almacenamiento de la VPS es el factor limitante.

Decisión: Deja de añadir paralelismo y compresión. Necesitas menos escrituras aleatorias (optimización de prepare) o mejor almacenamiento (plan más grande, VPS con NVMe local o adjuntar un volumen más rápido).

Tarea 5: Comprueba el steal de CPU (tu “vCPU” puede ser solo una sugerencia)

cr0x@server:~$ mpstat 1 5
Linux 6.1.0-18-amd64 (server) 	12/30/2025 	_x86_64_	(2 CPU)

12:10:01 AM  CPU    %usr   %nice    %sys %iowait   %irq   %soft  %steal  %guest  %gnice   %idle
12:10:02 AM  all   18.00    0.00    6.00   10.00   0.00    0.00   22.00    0.00    0.00   44.00

Qué significa: Un alto %steal indica que el hipervisor te está quitando tiempo de CPU. La compresión irá lenta y pueden ocurrir timeouts.

Decisión: Si el steal es consistentemente alto durante las restauraciones, paga por CPU dedicada o mueve la tarea de restauración a una máquina con menos contención.

Tarea 6: Confirma el directorio de datos y espacio libre (las restauraciones fallan cuando los discos se llenan)

cr0x@server:~$ mysql -Nse "SELECT @@datadir, @@tmpdir;"
/var/lib/mysql	/tmp

cr0x@server:~$ df -h /var/lib/mysql /tmp
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        79G   62G   13G  83% /
/dev/vda1        79G   62G   13G  83% /

Qué significa: Solo 13G libres. Una restauración física más archivos temporales puede desencadenar un error por falta de espacio.

Decisión: Si no puedes garantizar espacio para el backup + copia preparada + logs, restaura en un volumen nuevo o en una instancia nueva.

Tarea 7: Revisa ajustes de InnoDB que afectan el comportamiento de restauración/recuperación

cr0x@server:~$ mysql -Nse "SHOW VARIABLES WHERE Variable_name IN ('innodb_flush_log_at_trx_commit','sync_binlog','innodb_doublewrite','innodb_log_file_size','innodb_buffer_pool_size');"
innodb_buffer_pool_size	1073741824
innodb_doublewrite	ON
innodb_flush_log_at_trx_commit	1
innodb_log_file_size	268435456
sync_binlog	1

Qué significa: Ajustes conservadores de durabilidad. Geniales para la seguridad de datos, más lentos para ráfagas de escritura intensas y algunos flujos de restauración.

Decisión: Durante una ventana de restauración (no en operación normal), considera relajar temporalmente sync_binlog y innodb_flush_log_at_trx_commit si haces importaciones lógicas. Para copy-back de restauración física esto importa menos; para el catch-up posterior puede importar.

Tarea 8: Mide el tamaño del backup y la relación de compresión (predice dolor de CPU vs I/O)

cr0x@server:~$ du -sh /backups/full-2025-12-29
18G	/backups/full-2025-12-29

cr0x@server:~$ du -sh /backups/full-2025-12-29.tar.zst
6.2G	/backups/full-2025-12-29.tar.zst

Qué significa: Compresión 3x. Bien. También: el coste de descompresión es real.

Decisión: Si estás limitado por CPU, elige un nivel de compresión más ligero o ninguno; si estás limitado por red, mantén compresión y acepta el coste de CPU.

Tarea 9: Verifica disponibilidad y versión de mariabackup/xtrabackup

cr0x@server:~$ mariabackup --version
mariabackup based on MariaDB server 10.11.6-MariaDB Linux (x86_64)

Qué significa: La herramienta está alineada con la familia MariaDB 10.11.

Decisión: Continúa con respaldo/recuperación física. Si la herramienta reporta una familia mayor diferente a tu servidor, corrige eso primero.

Tarea 10: Toma el tiempo de la fase de prepare y vigila la I/O en vivo (encuentra el cuello de botella)

cr0x@server:~$ /usr/bin/time -v mariabackup --prepare --target-dir=/backups/full-2025-12-29 2>&1 | tail -n 8
	User time (seconds): 132.10
	System time (seconds): 88.55
	Percent of CPU this job got: 92%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 4:12.33
	Maximum resident set size (kbytes): 612340
	File system outputs: 9483216
	Exit status: 0

Qué significa: Tiempo de pared 4 minutos con mucha salida al sistema de archivos: escrituras intensas. La CPU es alta pero no totalmente saturada; probablemente mezcla de CPU + disco.

Decisión: Si el tiempo de pared es enorme y iostat muestra alta espera, estás limitado por IOPS. Mitiga reduciendo el volumen de redo (menos churn de escritura durante el backup) o restaura en un almacenamiento mejor.

Tarea 11: Valida la integridad del backup antes de apostar tu ventana de incidencia

cr0x@server:~$ mariabackup --check-privileges --target-dir=/backups/full-2025-12-29
mariabackup: Starting to check privileges
mariabackup: All required privileges are granted

Qué significa: Tu usuario de backup tiene permisos correctos; menos sorpresas durante restauraciones de emergencia.

Decisión: Si la comprobación de privilegios falla, arréglalo ahora. No aceptes “usualmente funciona”. Así te llaman a medianoche.

Tarea 12: Restaura con copy-back y verifica la propiedad (la parte aburrida que importa)

cr0x@server:~$ systemctl stop mariadb

cr0x@server:~$ mariabackup --copy-back --target-dir=/backups/full-2025-12-29
mariabackup: Starting to copy back
mariabackup: Copying ./ibdata1 to /var/lib/mysql/ibdata1
mariabackup: completed OK!

cr0x@server:~$ chown -R mysql:mysql /var/lib/mysql

Qué significa: Los archivos de datos están en su lugar. La propiedad es crítica; systemd no lo solucionará por ti.

Decisión: Si omites chown, puedes obtener errores de permisos, fallo de arranque y una larga noche de “por qué está caído” mientras miras logs.

Tarea 13: Observa el tiempo de la primera recuperación al arrancar (la mentira de “la restauración ha terminado”)

cr0x@server:~$ systemctl start mariadb

cr0x@server:~$ journalctl -u mariadb -n 30 --no-pager
Dec 30 00:22:12 server mariadbd[12988]: InnoDB: Starting crash recovery from checkpoint LSN=234887123
Dec 30 00:22:20 server mariadbd[12988]: InnoDB: 2 out of 2 rollback segments are active.
Dec 30 00:22:34 server mariadbd[12988]: InnoDB: Crash recovery finished.
Dec 30 00:22:35 server mariadbd[12988]: mariadbd: ready for connections.

Qué significa: Hubo trabajo de recuperación, pero terminó rápido.

Decisión: Si la recuperación de crash se arrastra, tu prepare no manejó todo el apply, o tu sistema está escaso de IOPS. Revisa el disco y los ajustes de logs de InnoDB.

Tarea 14: Mide la velocidad de copia durante la restauración (separa “copia” de “prepare”)

cr0x@server:~$ rsync -aHAX --info=progress2 /backups/full-2025-12-29/ /var/lib/mysql/
      9,732,145,152  62%  42.31MB/s    0:03:12

Qué significa: ~42 MB/s copia secuencial-ish. Eso es decente para una VPS pequeña.

Decisión: Si la velocidad de copia está bien pero la restauración completa es lenta, el problema es el prepare o la recuperación, no la transferencia de archivos.

Tarea 15: Si debes usar restauración lógica, hazla menos terrible

cr0x@server:~$ mysql -e "SET GLOBAL innodb_flush_log_at_trx_commit=2; SET GLOBAL sync_binlog=0;"

cr0x@server:~$ pv /backups/db.sql | mysql --max-allowed-packet=1G
1.58GiB 0:03:41 [7.30MiB/s] [=====================>     ] 62% ETA 0:02:15

Qué significa: Estás mejorando el rendimiento relajando durabilidad durante la importación; pv muestra progreso y tasa.

Decisión: Haz esto solo en una ventana de restauración controlada. Después de la importación, restaura ajustes seguros.

Tarea 16: Confirma posiciones de replicación/binlog tras la restauración (evita la deriva silenciosa)

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

Qué significa: Tienes un archivo/posición de binlog. Si este servidor es un réplica o sembrará réplicas, necesitas consistencia.

Decisión: Registra estas coordenadas y alinea réplicas. Una restauración rápida que crea inconsistencia de datos es solo un incidente lento más adelante.

Tres micro-historias corporativas (anonimizadas, dolorosamente plausibles)

Incidente causado por una suposición errónea: “SSD es SSD”

Un pequeño equipo SaaS ejecutaba MariaDB en una VPS barata porque en etapas tempranas la quema de efectivo se estaba “gestionando”. Sus restauraciones eran históricamente ~10 minutos usando respaldos físicos. Las practicaban trimestralmente. No era ideal, pero era soportable.

Un lunes, un problema de sistema de archivos obligó una restauración. La fase de copia de backup corrió a velocidad normal. Luego --prepare y el primer arranque empezaron a ralentizarse. El on-call asumió que “era solo un backup grande” y esperó. Cuarenta minutos después todavía veían mensajes de recuperación de InnoDB avanzar despacio como en una película de terror.

La suposición equivocada: “El disco es SSD, así que las escrituras aleatorias deben ser buenas”. En realidad, su VPS había sido migrada a un backend con limitación agresiva de IOPS. Las escrituras secuenciales estaban bien; la latencia de escritura aleatoria era brutal. El prepare y las fases de crash recovery golpearon escrituras aleatorias y fueron estranguladas hasta el infinito.

Solución: reconstruyeron en una clase de VPS distinta con IOPS predecible y añadieron una comprobación previa simple: ejecutar iostat durante una prueba programada de prepare y alertar si la espera de escritura superaba un umbral durante minutos. Las restauraciones no volvieron a ser instantáneas. Se volvieron predecibles. Predecible es lo que le vendes a tu yo futuro.

Optimización que salió mal: “Comprimamos todo más fuerte”

Una compañía mediana usaba Percona Server y enviaba respaldos nocturnos en streaming a otra región. Los costes de almacenamiento subían, así que alguien propuso aumentar la compresión y cifrar al mismo tiempo. Los artefactos de backup quedaron más pequeños. La hoja de cálculo de costes mejoró. Todos celebraron y siguieron lanzando features.

Dos meses después, se necesitó una restauración tras un error operativo. El pipeline de restauración bajó el stream comprimido/cifrado, luego pasó mucho tiempo descifrando y descomprimiendo en una pequeña VPS standby. La CPU se quedó al máximo, el %steal no fue trivial y todo el trabajo tardó tanto que la dirección empezó a preguntar si debían reconstruir la base de datos desde eventos de la aplicación.

El fallo: optimizaron por tamaño de backup y coste de transferencia, pero movieron el dolor al lado de la restauración—exactamente donde tienes menos paciencia y más presión. En máquinas pequeñas, “mejor compresión” suele significar “recuperación más lenta”.

Solución: cambiaron a un nivel de compresión más ligero y trasladaron el descifrado/descompresión pesada a un host robusto. Los backups siguieron siendo más pequeños que en bruto, pero las restauraciones volvieron a una ventana predecible. Además documentaron una regla simple: “El tiempo de restauración es un requisito del producto.” Una vez que lo dices así, la gente deja de tratarlo como un hobby.

Práctica aburrida pero correcta que salvó el día: restauraciones ensayadas con presupuestos de tiempo

Otro equipo—también con footprint de VPS pequeño—tenía una regla: cada mes, hacer una restauración completa en una instancia nueva y medir el tiempo de cada fase: descarga, descifrado, descompresión, prepare, copy-back, arranque y una prueba de humo básica de la aplicación.

No era glamoroso. No produjo features visibles para clientes. También significó que cuando sucedió una corrupción de disco, ya sabían que la restauración sería limitada por CPU en la descompresión y por IOPS en el prepare. Tenían una solución documentada: tirar el backup a una VPS de staging optimizada para compute, prepararlo allí y luego rsync del directorio preparado al objetivo.

Ejecutaron el plan. Sin improvisaciones. Sin “¿quizás deberíamos intentar…?” en medio del incidente. El servicio volvió dentro de la ventana esperada y el postmortem fue corto porque el resultado fue aburrido.

Chiste #2: Lo único más caro que probar restauraciones es no probarlas—tu futura caída te cobrará en horas.

MariaDB vs Percona: palancas de velocidad y trampas que realmente importan

Herramientas: mariabackup y xtrabackup son primos, no gemelos

La gente habla de “XtraBackup” como si fuera un término genérico para respaldos físicos. Eso es como llamar a todos los aspiradores “Dyson”. Conveniente, incorrecto y a veces caro.

mariabackup de MariaDB existe porque MariaDB divergió de las internals de MySQL/Percona. xtrabackup de Percona está afinado para la compatibilidad con Percona Server/MySQL. En teoría, ambos hacen respaldos físicos en caliente de InnoDB. En producción, desajustes de versión y diferencias sutiles de formato pueden convertir “restauración rápida” en “por qué no arranca”.

La velocidad de restauración la moldea el churn de redo, no la marca

Si tu carga genera mucho redo (alta tasa de escritura, transacciones grandes, muchas actualizaciones de índices secundarios), la etapa de prepare hará más trabajo. Ese trabajo consiste básicamente en escribir páginas—de forma aleatoria. En una VPS pequeña con IOPS mediocres, tu tiempo de restauración es función de la amplificación de escritura.

A veces puedes reducir el churn de redo programando respaldos en periodos de menor escritura, o asegurando que la base de datos no esté haciendo patrones patológicos (como actualizaciones masivas sin batching). Pero no existe un interruptor mágico “Percona es más rápido” para eso.

Las elecciones de compresión crean perfiles de “restauración por CPU” vs “restauración por disco”

La restauración más rápida en una VPS pequeña suele ser: respaldo sin comprimir almacenado localmente, preparado una vez y copiado de vuelta rápidamente. Pero eso consume mucho almacenamiento. Si guardas respaldos fuera del host, vas a comprimir. Ahora tu restauración incluye descompresión y la CPU se vuelve el limitador.

Si estás limitado por CPU, tanto MariaDB como Percona “pierden” de la misma forma, porque la variante del servidor no hace la descompresión: lo hace la herramienta y el pipeline. La ventaja viene de elegir niveles de compresión y dónde ejecutar el cómputo.

Binlogs y replicación: las restauraciones que “funcionan” aún pueden fallarte

Los entornos Percona suelen tener topologías de replicación más elaboradas y hábitos de recuperación punto-en-tiempo, en parte porque el ecosistema de Percona te empuja allí. Los entornos MariaDB varían mucho. De cualquier modo, la restauración no es solo copiar datos: necesitas que el servidor vuelva a la realidad—coordenadas de replicación, GTIDs, binlogs, expectativas de la aplicación.

En una VPS pequeña, la restauración más rápida a veces es “reemplazar la instancia” en vez de “restaurar en el lugar”. Nueva VM, adjuntar datos preparados, arrancar, swap de IP/DNS. Eso no es una característica de la base de datos; es un patrón operativo.

Qué elegiría en una VPS pequeña

• Si ya estás en Percona Server (MySQL 8.0): usa XtraBackup, mantén las versiones alineadas y diseña tu pipeline para minimizar el dolor de CPU durante la restauración.
• Si ya estás en MariaDB 10.6+: usa mariabackup, practica restauraciones mensuales y trata el tiempo de prepare como tu KPI central.
• Si eliges desde cero en una VPS diminuta y la velocidad de restauración es primordial: escoge la pila que puedas operar con limpieza y luego paga por almacenamiento con IOPS predecibles. La factura es más barata que el tiempo de inactividad.

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

1) Síntoma: la fase de prepare tarda una eternidad, disco al 100% de uso

Causa raíz: Límite de IOPS de escritura aleatoria en el almacenamiento de la VPS; workload de aplicar redo intenso.

Solución: Restaura/prepara en una instancia más grande/rápida y luego copia los archivos preparados; o muévete a un plan con IOPS predecible. Reduce el churn de redo programando backups en ventanas de baja escritura.

2) Síntoma: la restauración es “rápida” pero el primer arranque tarda con crash recovery

Causa raíz: El backup no fue preparado correctamente, o el servidor está haciendo recuperación adicional por desajuste de configuración (tamaños de log, archivos faltantes), o el almacenamiento está estrangulado.

Solución: Asegura que --prepare se complete con éxito; verifica compatibilidad de tamaños de logs de InnoDB; comprueba propiedad e integridad de archivos; vigila logs de recuperación y correlaciónalos con iostat.

3) Síntoma: restauración lógica más lenta de lo esperado, CPU no está saturada, disco tampoco

Causa raíz: Cuello de botella por importación mono-hilo, sobrecarga de reconstrucción de índices secundarios, o fsync forcings por commit.

Solución: Usa respaldos físicos para conjuntos grandes. Si estás atrapado con respaldo lógico: desactiva autocommit en la importación, usa --single-transaction en el dump, relaja sync_binlog/innodb_flush_log_at_trx_commit durante la ventana de restauración y carga esquema + datos en orden sensato.

4) Síntoma: el backup completa, la restauración falla con “permission denied” o datadir inaccesible

Causa raíz: Propiedad incorrecta/SELinux/AppArmor después del copy-back.

Solución: chown -R mysql:mysql del datadir, verifica políticas de seguridad y confirma que la unidad de servicio tiene acceso.

5) Síntoma: el servidor restaurado arranca, pero la aplicación ve tablas faltantes o errores raros

Causa raíz: Restauraste el conjunto de backups equivocado, mezclaste artefactos lógicos + físicos o restauraste un backup parcial.

Solución: Valida el manifiesto del backup, mantén backups inmutables y ejecuta consultas de verificación post-restauración (conteos de tablas, muestreo por checksum, prueba de humo de la aplicación).

6) Síntoma: la restauración es rápida localmente pero dolorosamente lenta al tirar desde almacenamiento remoto

Causa raíz: Throughput/latencia de red, límites de tasa o descifrado/desccompresión en una CPU pequeña.

Solución: Descarga en un host de staging cercano al almacenamiento, prepara allí y luego mueve los datos preparados; o mantén una copia reciente local si tu RTO lo exige.

7) Síntoma: xtrabackup/mariabackup da errores sobre versión de servidor no soportada

Causa raíz: Desajuste herramienta/servidor; intentar usar la herramienta del otro ecosistema.

Solución: Instala la versión correcta de la herramienta desde el mismo ecosistema y familia de versión mayor que el servidor; vuelve a ejecutar pruebas de backup.

8) Síntoma: después de restaurar, la replicación se rompe o los datos divergen

Causa raíz: Coordenadas de binlog/GTID no capturadas o aplicadas de forma consistente; restaurar desde un backup sin el estado de replicación correspondiente.

Solución: Captura y guarda coordenadas de replicación con cada backup; tras restaurar, reconfigura la replicación explícitamente y verifica con checks de estado.

Listas de verificación / plan paso a paso

Plan A: Restauración física rápida en la misma VPS (menos piezas móviles)

1. Confirma alineación servidor + herramienta (MariaDB→mariabackup, Percona→xtrabackup).
2. Comprueba espacio libre: necesitas sitio para el backup preparado y operaciones de copy-back.
3. Detén el servicio de base de datos limpiamente.
4. Prepara el backup (aplica redo) y cronometra la operación.
5. Haz copy-back al datadir y corrige la propiedad.
6. Arranca el servicio y vigila logs hasta completar la recuperación.
7. Ejecuta verificación: consultas básicas, conteo de filas, prueba de humo de la app.

Plan B: Restauración física rápida usando un host de staging (cuando el disco de la VPS es el cuello de botella)

1. Provisiona una instancia temporal optimizada para cómputo con mejor CPU/IOPS que la VPS objetivo.
2. Descarga + descifra + descomprime allí (evita consumir CPU en el objetivo limitado).
3. Ejecuta el prepare allí; este paso es el que más escrituras aleatorias realiza.
4. Rsync del datadir preparado a la VPS objetivo (más secuencial, más predecible).
5. Arranca MySQL/MariaDB en el objetivo y valida.
6. Desmantela el staging tras el éxito (y documenta el proceso para la próxima vez).

Plan C: Estás atrapado con dumps lógicos (cómo sobrevivir)

1. Restaura el esquema primero (tablas, índices, constraints), pero considera diferir índices pesados si es posible.
2. Relaja temporalmente la durabilidad durante la importación si es aceptable dentro de tu ventana de recuperación.
3. Importa en transacciones grandes (evita commits por fila).
4. Monitorea el progreso con pv y métricas del servidor; no trabajes a ciegas.
5. Vuelve a activar los ajustes de durabilidad inmediatamente después de la importación.
6. Reconstruye o analiza tablas según sea necesario para rendimiento.

Reglas de decisión (apréndetelas mentalmente)

• Si prepare domina el tiempo: estás limitado por IOPS o por redo → usa staging con mejor IOPS.
• Si descompresión domina el tiempo: estás limitado por CPU → compresión más ligera u offload de cómputo.
• Si transferencia domina el tiempo: haz streaming en pipeline o mantén una copia local reciente.
• Si restauras via mysqldump para conjuntos grandes: no tienes un RTO, tienes un deseo.

Preguntas frecuentes

1) Entonces, ¿quién es más rápido: MariaDB o Percona Server?

Si usas respaldos físicos con la herramienta correcta (mariabackup para MariaDB, xtrabackup para Percona/MySQL), normalmente están en la misma franja de rendimiento. Tu disco VPS y las elecciones de compresión deciden el resultado real.

2) ¿Cuál es el método de restauración más rápido en una VPS pequeña?

Un backup físico preparado copiado de vuelta en su lugar (o rsynceado desde un host de staging) suele ser lo más rápido. Las restauraciones lógicas casi siempre son más lentas para algo no trivial.

3) ¿Por qué a veces el “prepare” tarda tanto?

El prepare reproduce redo y hace consistente la copia de archivos. Eso puede implicar muchas escrituras aleatorias. En almacenamiento VPS limitado en IOPS, las escrituras aleatorias son el cobrador de impuestos.

4) ¿Debo comprimir backups en una VPS de 2 vCPU?

Comprime si estás limitado por red/almacenamiento, pero espera que la descompresión perjudique el tiempo de restauración. Si el tiempo de restauración es tu prioridad, mantén al menos un backup reciente sin comprimir o preparado en un host más potente.

5) ¿Puedo restaurar un backup de MariaDB usando xtrabackup (o viceversa)?

A veces funciona en rangos de versiones muy concretos, pero es una trampa de fiabilidad. En un incidente quieres “soportado y probado”, no “funcionó una vez en staging”.

6) ¿Restaurar a una VPS nueva es más rápido que restaurar en el lugar?

A menudo sí—especialmente si puedes preparar el backup en otro host y luego adjuntar/rsync los datos. Reemplazar la instancia evita pelear con problemas de disco residual, deriva de paquetes y presión del filesystem root.

7) ¿Qué métricas debo vigilar durante una restauración?

Utilización y espera del disco (iostat -xm), steal de CPU (mpstat), espacio libre (df -h) y logs de base de datos para progreso de recuperación (journalctl). Si no puedes determinar si estás limitado por CPU o I/O, no podrás arreglarlo rápidamente.

8) ¿Aumentar innodb_buffer_pool_size acelera las restauraciones?

Rara vez acelera la copia de archivos o el prepare directamente. Puede reducir el dolor post-restauración mejorando los hits de caché y acelerando el retorno a la normalidad. Es una jugada de estabilidad, no un acelerador mágico.

9) ¿Y las instantáneas (LVM/ZFS)?

Las instantáneas pueden ser muy rápidas para rollback local, pero en una VPS pequeña a menudo no controlas la capa de almacenamiento. Además, el rendimiento de snapshot puede degradarse bajo carga de escritura. Trata las instantáneas como complemento, no como tu único plan de recuperación.

10) ¿Cómo hago predecible el tiempo de restauración?

Practica restauraciones, registra tiempos por fase y alerta ante cambios. La predictibilidad viene del ensayo y de infraestructura que no estrangula aleatoriamente tu I/O.

Conclusión: siguientes pasos que realmente reducen el tiempo de restauración

MariaDB frente a Percona Server no es tu palanca principal de velocidad de restauración en una VPS pequeña. Es una elección de herramientas y ecosistema, y ambos pueden ser rápidos cuando usas correctamente sus herramientas de respaldo físico. La lucha real es contra los límites de escritura aleatoria del disco, la inanición de CPU por compresión y hábitos operativos que tratan las restauraciones como algo teórico.

Haz esto a continuación:

1. Elige respaldos físicos como predeterminado (mariabackup o xtrabackup) y deja de fingir que los dumps lógicos son una estrategia RTO para datos grandes.
2. Haz un ensayo de restauración mensual y registra tiempos para transferencia, descompresión, prepare, copy-back y primer arranque.
3. Decide dónde se ejecuta el prepare. Si el almacenamiento de tu VPS es débil, haz el prepare en un host de staging con mejor IOPS y envía los archivos preparados.
4. Ajusta la compresión según a qué estés realmente limitado: CPU, red o disco.
5. Presupuesta almacenamiento predecible. Si el tiempo de restauración importa, las IOPS “burst” no son un plan serio.

Cuando aparezca el próximo incidente—porque aparecerá—o bien estarás restaurando desde un pipeline probado, o estarás aprendiendo bajo presión. Una de esas opciones es más barata.