Estrategias de copia de seguridad en Proxmox: snapshots, vzdump y Proxmox Backup Server

Primero la respuesta: la estrategia en tres niveles

Para un host Proxmox que te importa, la estrategia que funciona es esta:

1. Snapshots para la próxima hora: haz uno antes de cambios arriesgados (actualizaciones, intervenciones en la configuración), vuelve atrás si algo sale mal, bórralo después. Los snapshots viven en el almacenamiento de la VM: protegen contra tus propios errores, no contra el host en sí.
2. Copias de seguridad vzdump programadas para el próximo mes: copias de seguridad en modo snapshot según un calendario, con reglas de retención, hacia un almacenamiento que no sean los mismos discos en los que corren las VM.
3. Proxmox Backup Server cuando los números crecen: copias de seguridad deduplicadas, incrementales, cifradas, verificadas hacia una segunda máquina, sincronizadas externamente. Aquí es donde las copias de seguridad diarias con historial completo de cada invitado se vuelven lo bastante baratas como para hacerlas de verdad.

Y la regla que convierte todo esto en protección real en lugar de pura apariencia: una copia de seguridad que no has restaurado es una hipótesis. Programa pruebas de restauración igual que programas las copias de seguridad.

Los snapshots no son copias de seguridad

Merece la pena aclararlo, porque la interfaz coloca «Snapshot» tentadoramente cerca de «Backup». Un snapshot de VM congela un momento en el tiempo en el mismo almacenamiento donde vive la VM: si el almacenamiento muere, el snapshot muere con él. Los snapshots de larga duración además degradan el rendimiento y complican el almacenamiento a medida que se acumulan los deltas.

Aquello para lo que los snapshots son excelentes es precisamente aquello para lo que las copias de seguridad son demasiado lentas: un botón de deshacer instantáneo alrededor de un cambio arriesgado. Haz uno, haz lo peligroso, confirma, borra el snapshot. Vida útil de minutos a horas: el consejo de nuestra guía de actualización de Debian, «decide primero tu plan de rollback», hecho realidad en un clic. (El RAID, para que quede completo, no es ni snapshots ni copias de seguridad: eso es disponibilidad, una tercera cosa.)

Nivel 2: vzdump, bien configurado

vzdump es el motor de copias de seguridad integrado de Proxmox: produce un archivo completo y autocontenido de un invitado, restaurable en cualquier host Proxmox. La diferencia entre «hacemos correr vzdump» y una estrategia real está en cuatro ajustes.

Modo: snapshot, con el guest agent

Usa el modo snapshot para los programas rutinarios: hace copias de seguridad de invitados en ejecución con, como mucho, una breve interrupción. Su coherencia depende de una cosa que mucha gente se salta: el guest agent de QEMU en cada VM (el paquete qemu-guest-agent, más la casilla en las opciones de la VM). Con él, vzdump congela los sistemas de archivos del invitado (fs-freeze/fs-thaw) en el momento de la captura, de modo que el archivo contiene una imagen crash-consistent (o mejor) en lugar de una incoherente. Reserva el modo stop para los invitados en los que la certeza de una copia en frío merece la pena frente al tiempo de inactividad programado, y para las bases de datos, sigue mereciendo la pena la doble seguridad: un dump a nivel de aplicación (pg_dump, etc.) según un programa dentro del invitado cuesta poco y permite restauraciones que una imagen de disco no puede.

Programación y retención

Configura esto en Datacenter → Backup: qué invitados, cuándo (cada noche, escalonado si el almacenamiento es compartido), y (la parte que evita tanto la pérdida de datos como los discos llenos) la retención. Proxmox purga según reglas: keep-daily=7, keep-weekly=4, keep-monthly=6 te da, por ejemplo, un mes de granularidad diaria y una cola de dos estaciones, purgada automáticamente. Cualquier regla de retención supera a las dos que la gente usa realmente por defecto: «guardarlo todo hasta que el disco se llene» y «guardar 1».

Destino: no los mismos discos

Una copia de seguridad en el almacenamiento que protege no es más que un snapshot complicado innecesariamente. Destino mínimo viable: cualquier almacenamiento que falle de forma independiente, un segundo array local, NFS en otro sitio, o (nivel 3) un datastore de PBS en otra máquina.

Fleecing: para destinos lentos

Si las copias de seguridad hacia un destino lento (NFS por un enlace estrecho, un array HDD muy ocupado) hacen que los invitados vayan lentos, es porque las escrituras del invitado están esperando al destino de la copia. Fleecing (--fleecing enabled=1,storage=local-lvm) almacena en búfer los bloques antiguos en almacenamiento local rápido en su lugar, desacoplando así la E/S del invitado de la velocidad del destino: una función discreta que resuelve la queja más habitual, «las copias de seguridad perjudican la producción».

Nivel 3: Proxmox Backup Server

La limitación de vzdump es aritmética: cada copia de seguridad es un archivo completo, así que las copias diarias de una VM de 200 GB cuestan 200 GB al día, y la mayoría de esos bytes son idénticos día tras día. Proxmox Backup Server (un producto complementario gratuito y de código abierto que instalas en una segunda máquina) cambia esa aritmética:

• Deduplicación + transferencia incremental. Los datos se almacenan como content-addressed chunks; los chunks sin cambios se almacenan una sola vez, y las VM en ejecución se respaldan de forma incremental usando dirty bitmaps de QEMU: solo se leen, y mucho menos se envían, los bloques escritos desde la última copia de seguridad. Efecto práctico: después de la primera copia, las copias nocturnas de VM grandes tardan minutos y cuestan gigabytes, no cientos de ellos. (Los contenedores tienen su propio acelerador: el modo de detección de cambios metadata se salta los archivos sin cambios comparándolos con los metadatos del snapshot anterior.)
• ¿Cuánto ahorra la dedup? Proxmox, sinceramente, no publica ningún ratio oficial. Depende de la profundidad de retención y de cuánto se parezcan tus invitados entre sí. Los informes de la comunidad suelen situarse en el rango de 5–12× con copias diarias y una retención sensata; un ratio cercano a 1× normalmente solo significa que la retención está fijada en un único snapshot.
• Verificación contra el bit rot. Los verify jobs programados recalculan las sumas de comprobación de los chunks almacenados, de modo que la corrupción silenciosa del almacenamiento se detecta antes de la restauración que habría necesitado esos datos. Esta es la función letal y discreta de PBS: los archivos fríos se pudren de forma invisible; los verificados no.
• Cifrado del lado del cliente (AES-256-GCM): las copias de seguridad se cifran antes de salir del host PVE, de modo que la máquina PBS (o el bucket S3 detrás de ella) nunca contiene texto plano. Protege bien la clave; PBS admite una clave maestra imprimible en papel para emergencias.
• Sincronización externa. Los sync jobs replican datastores entre instancias de PBS (push o pull, solo delta). Un segundo PBS en otra ubicación convierte la instalación en un verdadero 3-2-1. Desde PBS 4.2, el almacenamiento de objetos compatible con S3 es un backend de datastore oficialmente compatible, lo que también convierte la «copia externa en un bucket» en una opción de pleno derecho.
• Ergonomía de restauración: restauración de un solo archivo (sacar un archivo de una copia de seguridad de imagen de VM desde la interfaz) y live-restore (arrancar una VM directamente desde su copia de seguridad mientras se transmite de vuelta en streaming, RTO en minutos para los impacientes).

La forma de despliegue en servidores dedicados es sencilla: PBS quiere su propia máquina (las copias de seguridad en el hipervisor no protegen nada), con un almacenamiento orientado a la capacidad (en materia de RAID: territorio raidz2/RAID 6) y una conexión lo bastante ancha como para que las ventanas de restauración sean tolerables (el cálculo de ventana de restauración de la guía de dimensionamiento también se aplica aquí: 4 TB a 1 Gbit/s son ~9 horas; a 10 Gbit/s baja a menos de una). Los hosts PVE reciben después cada noche un trabajo Datacenter → Backup dirigido al datastore de PBS, PBS ejecuta prune + garbage collection + verify semanal, y (si el volumen de datos lo justifica) un sync job envía los datos a una segunda ubicación.

¿Qué pasa con la replicación y Ceph?

Dos funciones vecinas se confunden con copias de seguridad. La replicación ZFS (pvesr) copia volúmenes de invitados a otro nodo según un programa (hasta cada minuto), excelente para un failover rápido con almacenamiento local, pero replica fielmente cada borrado y cada corrupción en cuestión de minutos; eso es disponibilidad, no historial. Ceph hace lo mismo: almacenamiento replicado autorreparable que conservará tus bloques cifrados por ransomware con una redundancia impecable. Ambos trabajan junto a las copias de seguridad (cubren el caso «el nodo ha muerto»; las copias de seguridad cubren el caso «necesitamos el estado del martes pasado»). Ninguno de los dos las sustituye. Más sobre ambos en la guía de cluster y HA.

El simulacro de restauración

Como mínimo cada trimestre: restaura una VM a un VMID desechable (qmrestore o interfaz, restore-as-new: no sobrescribe el original), arráncala, confirma que la aplicación realmente funciona, bórrala. Veinte minutos que convierten «tenemos copias de seguridad» en «tenemos restauraciones». Ya que estás: cronometra el proceso. Si el tiempo te sorprende, mejor descubrirlo ahora que durante un incidente: es entonces cuando descubres si live-restore, más ancho de banda o una granularidad de retención mejor merecen la pena configurarse.

Preguntas frecuentes

¿Son seguras las copias de seguridad en modo snapshot de una base de datos en ejecución?

Seguras, pero mejorables. Como el guest agent congela los sistemas de archivos en el momento de la captura, la imagen es coherente a nivel de sistema de archivos, y las bases de datos modernas (PostgreSQL, MySQL/InnoDB) se recuperan de eso sin problemas: equivale a recuperarse de un corte de luz, para lo cual están diseñadas. Lo que una imagen de disco no te da es la libertad de volver a un momento concreto o de hacer fácilmente una restauración parcial, así que para las bases de datos que importan, añade dumps a nivel de aplicación o archivado de WAL dentro del invitado. La combinación (copias de seguridad de imagen para la recuperación de todo el sistema, dumps para una recuperación quirúrgica) es la respuesta sensata.

¿Con qué frecuencia debo hacer copias de seguridad?

Parte de la pregunta «¿cuánto trabajo podemos permitirnos perder?» Ese es tu intervalo de copias de seguridad. Una copia cada noche es el mínimo estándar para invitados normales; con el modelo de coste incremental de PBS, varias veces al día para bases de datos muy exigentes resulta perfectamente asequible (y la replicación pvesr puede además reducir la brecha de disponibilidad a un minuto). La cifra que pesa tanto como esa: la profundidad de retención. La corrupción y el ransomware se descubren a menudo días después. Una estrategia que solo conserva tres copias nocturnas puede arrastrar el daño a cada copia antes de que nadie se dé cuenta.

¿Puede PBS hacer copias de seguridad de cosas que no son invitados de Proxmox?

Sí: el proxmox-backup-client se ejecuta en cualquier host Linux y envía copias de seguridad a nivel de archivo a los mismos datastores deduplicados, cifrados y verificados. Si de todos modos ya tienes PBS en marcha, es un lugar natural también para la configuración y los datos de tus máquinas no virtualizadas: una sola infraestructura de copias de seguridad, una sola política de retención, un solo lugar donde probar las restauraciones.

¿Esto protege contra el ransomware?

Es la mayor parte de la respuesta, con dos condiciones. Primero, la separación: un PBS accesible solo a través de su API con sus propias credenciales no es cifrable por un invitado comprometido, pero las copias de seguridad escritas en un recurso compartido NFS que el hipervisor monta en lectura-escritura sí lo son. Segundo, historial y sincronización: una retención que se remonte lo bastante atrás como para superar la infección, verify jobs para saber que los chunks están intactos, y una sincronización externa (un segundo PBS o S3) que un único sitio comprometido no pueda alcanzar. El cifrado del lado del cliente de PBS protege tus copias de seguridad del almacenamiento; la separación de accesos las protege del atacante.

Desplegar en Serverside

El despliegue natural de PBS aquí es un segundo servidor dedicado: una configuración de almacenamiento centrada en la capacidad, en la red privada con tus hosts Proxmox para que el tráfico nocturno de copias de seguridad nunca toque tu ancho de banda público, en un dominio de fallo distinto al del host que protege. Aprovisionamiento en menos de un minuto sobre el ASN 55285, y las mismas imágenes con Proxmox preinstalado en todas partes.

El resto de la serie: configuración inicial, redes, LXC frente a VM, y (donde la replicación y el failover toman el relevo de las copias de seguridad) clustering y alta disponibilidad.