fs-freeze) durante el backup: sube de crash-consistent a fs-consistent.pg_dump, mysqldump, XtraBackup) o hooks que fuercen a la base de datos a un estado limpio antes del snapshot.Hay una falsa sensación de seguridad muy extendida: «hago backup de la VM entera cada noche con Proxmox Backup Server, así que estoy cubierto». El backup existe, corre, ocupa espacio y da la sensación de deber cumplido. El problema aparece el día que hay que restaurar una base de datos y descubres que el backup de la VM no era lo que creías: la base de datos arranca reparándose, o peor, con datos inconsistentes que parecen bien pero no lo están.
La causa es un malentendido técnico que casi nadie explica: hacer una copia del disco de una máquina no es lo mismo que hacer un backup consistente de la base de datos que corre dentro. Son dos cosas distintas, con garantías distintas, y confundirlas es cómo se pierden datos con backups «que funcionaban».
Este artículo explica los tres niveles de consistencia de un backup, por qué un snapshot a secas se queda en el más débil, y cómo conseguir el bueno en Proxmox. Es la pieza que faltaba en nuestra serie de copias de seguridad, junto a la regla 3-2-1 y los objetivos de RTO/RPO: de nada sirve tener tres copias si las tres son inconsistentes.
No todos los backups son iguales. La diferencia está en qué garantiza cada uno sobre el estado de los datos en el momento de la copia.
Es lo que obtienes con un snapshot de disco sin más. La copia refleja el disco exactamente como estaría si a la máquina le cortaran la corriente en ese instante. Ni mejor ni peor. ¿Es recuperable? Normalmente sí: los sistemas de ficheros modernos y las bases de datos serias tienen mecanismos de recuperación ante caídas —replay del journal, del WAL— que arrancan y reparan al iniciar.
Pero «normalmente recuperable» no es «garantizado íntegro». Hay escrituras en vuelo, cachés en memoria que no llegaron al disco, transacciones a medias. La base de datos hará lo que pueda al arrancar, pero partes de un estado de accidente. Para muchas cargas es aceptable; para datos que importan, es apostar.
Un escalón por encima. Antes de hacer el snapshot, se le pide al sistema operativo invitado que vacíe sus cachés a disco y congele momentáneamente la escritura (un fs-freeze). El snapshot captura entonces un sistema de ficheros limpio, sin escrituras a medias a nivel de disco. En Proxmox esto lo habilita el QEMU Guest Agent, del que hablamos abajo.
Es mejor, pero tiene un límite importante: congela el sistema de ficheros, no la base de datos. Si el motor de base de datos tiene transacciones en su propia memoria sin volcar, el fs-freeze no las conoce. El disco queda limpio; el estado lógico de la base de datos, no necesariamente.
El bueno. Aquí la propia base de datos participa: antes del backup se la lleva a un estado coherente conocido —cierra transacciones, vuelca sus buffers, se pone en modo backup—. La copia refleja un estado que la base de datos reconoce como válido y del que puede partir sin recuperación ni dudas. Es el único nivel que garantiza que una base de datos restaurada está íntegra.
La regla que resume todo: para ficheros normales, fs-consistent basta; para bases de datos, necesitas application-consistent. Y un snapshot de VM a secas no te da ninguno de los dos: te da crash-consistent.
La pieza que casi nadie activa y debería. El QEMU Guest Agent es un pequeño servicio que se instala dentro de la VM y permite que Proxmox le hable al sistema operativo invitado. Para backups, su función clave es el fs-freeze/fs-thaw: cuando Proxmox va a hacer el backup, le pide al agente que congele el sistema de ficheros; al terminar, que lo descongele.
# Dentro de una VM Linux
apt install qemu-guest-agent
systemctl enable --now qemu-guest-agentY en Proxmox, en las opciones de la VM, activar «QEMU Guest Agent». A partir de ahí, los backups suben automáticamente de crash-consistent a fs-consistent: el sistema de ficheros se captura limpio. Es gratis, es un minuto de trabajo, y mucha gente lo tiene desactivado sin saber lo que se pierde. Si no haces nada más de este artículo, activa el guest agent.
Pero recuerda el límite: fs-freeze limpia el disco, no la base de datos. Para bases de datos hay que dar un paso más.
Para llevar la base de datos a un estado coherente antes del backup, hay tres enfoques. Se pueden combinar.
La base de datos sabe exportarse a sí misma en un estado consistente. Es lo que hacen las herramientas de volcado:
# PostgreSQL — volcado lógico consistente
pg_dump -Fc basedatos > /backups/basedatos.dump
# MySQL/MariaDB — volcado consistente de tablas transaccionales
mysqldump --single-transaction --routines --triggers basedatos > /backups/basedatos.sqlFíjate en --single-transaction en MySQL: hace el volcado dentro de una transacción, capturando una foto coherente sin bloquear la base de datos. pg_dump es consistente por diseño. El resultado es un fichero que restaura una base de datos íntegra, sin depender del estado del disco.
La práctica más común y sólida: un volcado nativo programado dentro de la VM, cuyo fichero luego entra en el backup de Proxmox. Así el backup de la VM incluye un dump que sí es application-consistent, aunque el resto de la imagen sea fs-consistent. Dos capas, cada una con su garantía.
Proxmox permite ejecutar scripts hook en fases del backup (antes de empezar, antes del snapshot, después). Un hook puede disparar un volcado o poner la base de datos en modo backup justo antes del snapshot y sacarla después. Es la forma de automatizar la vía 1 atada al ciclo de backup de Proxmox, sin depender de un cron separado dentro de la VM.
Para bases de datos grandes donde un volcado lógico es demasiado lento, los motores traen backup físico en caliente: pg_basebackup en PostgreSQL, Percona XtraBackup en MySQL/MariaDB. Copian los ficheros de datos mientras la base de datos sigue en marcha, de forma consistente, y habilitan la recuperación a un punto en el tiempo.
Un matiz que separa un backup decente de uno serio. Un backup —del nivel que sea— es una foto de un momento. Si la toma es de las 3:00 y el desastre ocurre a las 14:30, restaurar el backup te devuelve al estado de las 3:00: pierdes 11 horas y media. Eso es tu RPO, y para muchas bases de datos 11 horas es inaceptable.
La solución es el PITR (Point-In-Time Recovery): además del backup base, se archivan de forma continua los registros de transacciones —el WAL en PostgreSQL, los binlogs en MySQL—. Con el backup base más esos registros, puedes reconstruir el estado de la base de datos en cualquier instante entre el backup y el desastre. Restauras la foto de las 3:00 y luego «reproduces» las transacciones hasta las 14:29. El RPO baja de horas a segundos.
Esto vive en la capa de base de datos, no en el snapshot de la VM. Es la razón por la que un backup de VM, por bueno que sea su nivel de consistencia, no sustituye a una estrategia de backup propia de la base de datos: la VM te da la foto; solo los registros de transacciones te dan el «hasta el último segundo».
Combinando todo, una estrategia que aguanta de verdad:
| Capa | Qué hace | Garantía |
|---|---|---|
| QEMU Guest Agent | fs-freeze en cada backup de VM | Sistema de ficheros limpio |
| Volcado nativo o hook | Dump consistente de la base de datos | Base de datos íntegra (application-consistent) |
| Archivado de WAL/binlog | Registros de transacciones continuos | PITR: recuperación al segundo |
| Proxmox Backup Server | Backup de la VM completa, deduplicado, offsite | La imagen entera, con la regla 3-2-1 |
Y una prueba que casi nadie hace y lo cambia todo: restaura de verdad, en un entorno aparte, y comprueba que la base de datos arranca íntegra. Un backup que nunca se ha restaurado no es un backup, es una esperanza. La primera restauración no debería ser durante un incidente real.
¿Un snapshot de Proxmox Backup Server sirve para mi base de datos? Sirve como copia de la VM, pero por defecto es consistente por caída: captura el disco como si se hubiera cortado la corriente. La base de datos probablemente se recupere al arrancar, pero no está garantizado que quede íntegra. Para bases de datos, añade el QEMU Guest Agent (fs-freeze) y, sobre todo, un volcado nativo o hook que dé consistencia de aplicación.
¿Qué hace exactamente el QEMU Guest Agent en un backup? Antes del snapshot, congela el sistema de ficheros de la VM (vacía cachés a disco y pausa la escritura un instante), y lo descongela al terminar. Eso sube el backup de crash-consistent a filesystem-consistent. No conoce el estado interno de la base de datos, así que no sustituye a un volcado de base de datos.
¿Es mejor un volcado (dump) o un backup de la VM entera? No compiten, se complementan. El backup de la VM te devuelve la máquina entera rápido ante un desastre total. El volcado te garantiza una base de datos íntegra y portable. Lo robusto es tener ambos: la VM en Proxmox Backup Server y un dump consistente dentro (o disparado por hook).
¿Qué es PITR y lo necesito? La recuperación a un punto en el tiempo permite restaurar la base de datos a cualquier instante, no solo al momento del último backup, archivando de forma continua los registros de transacciones (WAL/binlog). Lo necesitas si perder las horas entre backup y desastre es inaceptable para tus datos. Baja el RPO de horas a segundos.
¿Cada cuánto debo hacer backup de una base de datos? Depende de tu RPO: cuántos datos puedes permitirte perder. El backup base puede ser diario, pero si toleras perder poco, combínalo con archivado continuo de registros de transacciones (PITR). Y prueba la restauración periódicamente: la frecuencia del backup importa menos que la certeza de que restaura bien.
mysqldump y backup consistente.¿Haces backups de tus VMs pero no sabes si tus bases de datos restaurarían íntegras? Diseñamos contigo una estrategia por capas sobre Proxmox —agente invitado, volcados consistentes y PITR— y probamos la restauración de verdad. Empieza por nuestra comparativa de cloud o hablemos de tu proyecto.
Proxmox VE 9.2 estrena versión oficial para ARM64 (AArch64), la primera fuera de x86-64 en la historia del producto. Misma base de código, mismos repositorios y mismo soporte, con NVIDIA Grace y NVIDIA Vera como plataformas certificadas de salida. Repasamos qué hardware cumple los requisitos, qué funciones se quedan en x86 y qué cambia (poco, de momento) para quien ya tiene un clúster en producción.
Una red IP enrutada abajo, los servicios de cada cliente encapsulados arriba y BGP distribuyendo dónde está cada MAC. Qué resuelve EVPN-VXLAN, cómo encajan underlay y overlay, qué detalles rompen un fabric (la MTU, siempre la MTU) y cuándo no compensa montarlo.
Entrenar o servir modelos de IA en tu propio cloud privado pasa por una pieza técnica concreta: entregar una GPU física a una máquina virtual con rendimiento casi nativo. Explicamos qué es el passthrough con VFIO e IOMMU, cómo se hace en Proxmox VE 9.2, dónde están las trampas (grupos IOMMU, la GPU de arranque, licencias) y cuándo compensa frente a alquilar GPU en un hiperescalar.