Proxmox en ZFS: la estrategia de copias de seguridad que no miente (snapshots vs copias reales)

diciembre 28, 2025 • febrero 3, 2026 • Lectura: 27 min • Views: 11

¿Te fue útil?

Si ejecutas Proxmox sobre ZFS, puedes crear snapshots tan rápido que parece trampa. Y esa es la trampa.
El día que necesites una restauración real—tras un fallo de pool, un rm por error, o una actualización del hipervisor que sale mal—tu “estrategia de snapshots” puede resultar ser una estrategia para sentirte tranquilo, no para recuperar datos.

Las copias de seguridad son un producto: deben entregar restauraciones. Los snapshots de ZFS son una función: entregan conveniencia. Deja de mezclarlos.
Aquí tienes el manual crudo que mantiene los clústeres Proxmox honestos.

La afirmación central: los snapshots no son copias de seguridad

Un snapshot de ZFS es una referencia en un punto en el tiempo a bloques en el mismo pool. Es fantástico para rollback rápido y momentos de “ups”.
Pero vive y muere con el pool. Si el pool desaparece, tus snapshots desaparecen. Si el pool está cifrado y la clave se pierde, tus snapshots siguen “ahí” de la misma manera que tus archivos “están” en un disco que no puedes desbloquear: técnicamente, espiritualmente, no operativamente.

Una copia de seguridad es otra cosa: es independiente. Se guarda en otro lugar, está sujeta a modos de fallo distintos y se prueba rutinariamente mediante restauraciones.
Si tu “respaldo” no sale del dominio de fallo, no tienes una copia de seguridad; tienes una máquina del tiempo atornillada al mismo coche que acaba de caer al lago.

La prueba operativa es directa: si la placa base del hipervisor se quema, ¿puedes restaurar tus VMs en otro host sin forenses heroicos?
Si la respuesta implica “bueno, los snapshots están en el pool”, eso no es un plan. Es una anécdota.

Broma #1: Un snapshot es como un botón de guardar que solo funciona si tu portátil no se cae al océano. Gran función, recuperación ante desastres discutible.

Datos interesantes y breve historia (que realmente ayuda a decidir)

Los snapshots de ZFS son copy-on-write: no “congelan” datos copiándolos; preservan referencias a bloques y escriben bloques nuevos para los cambios.
ZFS fue diseñado con sumas de verificación end-to-end: los bloques de datos y metadatos tienen checksum, así que la corrupción silenciosa se detecta al leer y durante scrubs.
La herencia de Solaris importa: ZFS creció en entornos empresariales donde “rollback” y “replicación” eran ideas separadas—snapshots y send/receive juegan roles distintos.
zfs send es transmisión basada en snapshots: la replicación y muchas workflows tipo “backup” dependen de snapshots como unidad de transferencia.
Los scrubs de ZFS son lecturas de patrulla: no son copias de seguridad, pero son cómo ZFS encuentra bit rot antes de que sea un evento de restauración.
Proxmox históricamente dependió de vzdump: las copias clásicas eran archivos de archivo en targets de almacenamiento; los despliegues modernos usan cada vez más Proxmox Backup Server (PBS) para backups chunked y con deduplicación.
Los snapshots se hicieron populares por ser baratos: la sensación de “costo casi cero” lleva a equipos a usarlos en exceso como retención, y luego se sorprenden por la contabilidad del espacio.
RAID no es una copia de seguridad—sigue sin serlo: RAID (incluido RAIDZ) reduce el tiempo de inactividad por fallos de disco pero no hace nada contra borrados lógicos, ransomware o “ups borré el dataset”.

Modelo de amenazas: contra qué te estás defendiendo realmente

Tu estrategia de copias debe mapearse a modos de fallo, no a buenas sensaciones. Aquí están los que realmente aparecen:

1) El factor humano (a.k.a. “yo soy el outage”)

Borras accidentalmente, destruyes el dataset equivocado, reinstalas el nodo equivocado, borras el disco equivocado. Esto no es raro; es un impuesto recurrente.
Los snapshots son excelentes para esto cuando el pool está sano.

2) Pérdida del dominio de fallo del almacenamiento

Un HBA muere y deja múltiples discos offline, fallo de backplane, bug de firmware, corrupción del pool, o el horror en cámara lenta de un pool que no se importa tras un reinicio.
Si tus snapshots están en ese pool, son un bonito memorial.

3) Ransomware y compromiso de credenciales

Si un atacante obtiene root en el hipervisor, puede borrar snapshots. Puede borrar backups locales. Puede ejecutar zfs destroy y eliminar tu historial con una sola línea.
Necesitas inmutabilidad y separación de credenciales. Aquí es donde brilla PBS, pero solo si lo despliegas con límites de autenticación sensatos.

4) “Todo funciona” hasta que no: incertidumbre de restauración

Las copias fallan silenciosamente. Las restauraciones fallan ruidosamente. La única copia que cuenta es la que has restaurado recientemente, idealmente en un entorno de prueba en red aislado que se parezca a producción.

5) Regresiones de rendimiento que convierten los backups en su propio incidente

Los backups pueden destruir la latencia, especialmente con I/O aleatorio de bloques pequeños, pools ocupados o retención agresiva de snapshots.
Necesitas gestionar cuándo se ejecutan los backups, qué tocan y con qué compiten.

Cómo usa Proxmox ZFS (y por qué importa para las copias)

Proxmox normalmente almacena discos de VM como ZVOLs (dispositivos de bloque) cuando eliges almacenamiento ZFS. Los contenedores pueden usar datasets.
La distinción importa: los backups de ZVOL y de dataset se comportan diferente, especialmente para snapshotting y uso de espacio.

VMs en ZVOLs: snapshots rápidos, espacio complicado

Un disco de VM como ZVOL es un dispositivo de bloque con volblocksize (a menudo 8K/16K). Las escrituras vienen desde el sistema de archivos invitado, no desde semánticas conscientes de ZFS.
Los snapshots preservarán bloques antiguos; una retención larga puede crear una presión de espacio seria en VMs con muchas escrituras (las bases de datos adoran hacerte esto).

Contenedores en datasets: más visibilidad, pero no magia

Los datasets pueden ser snapshotados y replicados limpiamente, y ZFS puede tomar mejores decisiones de compresión basadas en recordsize.
Pero los contenedores aún sufren de “estaba en el mismo pool”, lo que significa que los snapshots no te salvan de la pérdida del pool.

Backups en Proxmox: `vzdump` vs Proxmox Backup Server

vzdump crea archivos de archivo (.vma.zst, .tar.zst, etc.) en un target de almacenamiento. Puede usar snapshots para lograr consistencia mientras copia.
PBS almacena backups en chunks, deduplica entre VMs y soporta cifrado y (opcionalmente) políticas de retención que no implican “borrar tarballs antiguos a mano”.

Las mejores configuraciones a menudo usan ambos conceptos:
snapshots locales en ZFS para rollback rápido y errores operativos;
PBS (u otro backup fuera del host) para recuperación ante desastres real.

Snapshots: en qué son buenos y en qué no

Son geniales para:

Rollback rápido tras actualizaciones de paquetes malas, cambios rotos en la configuración de la VM o un despliegue de aplicación que detona.
Barreras de seguridad a corto plazo durante operaciones riesgosas: migraciones, cambios de sistema de archivos, cambios de esquema.
Entradas para replicación: los snapshots son la unidad de transferencia incremental con zfs send -i.

No son buenos para:

Pérdida del pool: no salen del pool.
Compromiso de credenciales: root puede destruirlos.
Retención larga sin planificación de capacidad: los bloques antiguos anclan espacio; tu pool se llena “misteriosamente”.
Recuperación consistente a nivel de aplicación: un snapshot crash-consistente suele bastar para sistemas de archivos journaling, no siempre para bases de datos sin coordinación.

La retención de snapshots debe ser corta e intencional. Horas a días, quizá un par de semanas para ventanas de “ups”—dependiendo de la tasa de cambios.
Si mantienes meses de snapshots en pools de producción, no estás haciendo “backup.” Estás haciendo “fuga de espacio con API”.

Copias reales: qué “cuenta” en producción

Una copia real debe cumplir tres condiciones:

Separación: almacenada fuera del host o al menos fuera del pool, idealmente fuera del sitio. Diferentes credenciales, distinto radio de explosión.
Recuperabilidad: puedes restaurar a un entorno limpio, dentro de un RTO aceptable.
Verificación: has realizado restauraciones de prueba recientemente. No “revisar logs”, no “validar checksums”, sino arrancar o verificar la integridad de datos realmente.

En el ecosistema Proxmox, las implementaciones de “copias reales” más comunes son:

Proxmox Backup Server: la mejor opción por defecto para muchos equipos: dedupe, cifrado, poda, trabajos de verificación.
vzdump a NFS/SMB/otro servidor ZFS: funcional y simple, pero sé honesto sobre inmutabilidad y verificación.
ZFS send/receive a un target de respaldo: potente, transparente, rápido para incrementales; también fácil de mal configurar hasta convertirlo en un desastre sincronizado.

“Copias sin simulacros de restauración” son teatro de cumplimiento. Y sí, el teatro tiene presupuestos.

Cita (idea parafraseada) de W. Edwards Deming: Sin medición, no estás gestionando—solo adivinando. Las copias se miden por la restauración.

Un diseño de copias que sobrevive a los malos días

Aquí tienes una estrategia que funciona para equipos pequeños y escala sin cambiar su personalidad:

Capa 1: Snapshots ZFS locales para rollback rápido

Manténlos de corta duración.
Haz snapshot antes de cambios riesgosos y en un horario (por ejemplo, horario cada hora durante 24 h, diario durante 7 d).
Automatiza con una herramienta de snapshots o tu propio cron, pero mantén nombres consistentes.

Capa 2: Copias a un sistema separado (preferible PBS)

PBS en hardware separado, idealmente en rack / dominio de energía distinto si puedes.
Usa credenciales separadas; no montes el datastore en lectura-escritura desde los hipervisores “solo porque”.
Activa cifrado en el momento del backup si tu modelo de amenazas incluye robo del almacenamiento de backups.

Capa 3: Copia fuera del sitio (replicación o sincronización)

O bien sincronización de PBS a un segundo PBS, o replicación ZFS a otro target ZFS, o exportar backups a almacenamiento de objetos mediante una canalización controlada.
Asegúrate de que esta capa no sea un espejo de la eliminación. La replicación retardada es una característica, no un defecto.

Retención: deja de fingir que es una sensación

La retención es una decisión política basada en:
requisitos regulatorios, tolerancia del negocio y costes de almacenamiento.
Una línea base sensata:

Snapshots locales: 24–72 horas con copias horarias + 7–14 días diarias (ajusta según la tasa de escritura).
Backups en PBS: 14–30 días diarios + 3–12 meses semanales/mensuales, según lo que el negocio llame “ups”.
Fuera del sitio: al menos semanal, idealmente diario, con retención más larga para ventanas de recuperación ante ransomware.

Consistencia: decide qué quieres decir

Para muchas VMs, crash-consistent es suficiente. Para bases de datos, quieres application-consistent cuando sea posible: flush, freeze o usar backups nativos de la base.
ZFS no sabe lo que es “una transacción”. Sabe bloques.

Broma #2: “Replicamos instantáneamente al sitio de DR” es la versión de backup de “siempre respondo los mensajes inmediatamente.” Impresiona hasta que te arrepientes de lo que enviaste.

Tareas prácticas con comandos: inspeccionar, decidir, actuar

Estas son las tareas que ejecutas durante la configuración, durante un incidente y durante el ritual mensual de “pruébalo aún funciona”.
Cada tarea incluye: comando, ejemplo de salida, qué significa y qué decisión tomar.

Task 1: Verificar la salud del pool antes de culpar a los backups

cr0x@server:~$ zpool status -v
  pool: rpool
 state: ONLINE
  scan: scrub repaired 0B in 02:11:40 with 0 errors on Sun Dec 22 03:00:01 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        rpool                       ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-SAMSUNG_SSD_1       ONLINE       0     0     0
            ata-SAMSUNG_SSD_2       ONLINE       0     0     0

errors: No known data errors

Qué significa: Tu pool está sano, los scrubs se completan y no hay errores de checksum.
Decisión: Procede con el ajuste de snapshots/backups; no estás luchando contra corrupción de almacenamiento subyacente.
Si ves DEGRADED, FAULTED o errores de checksum, arregla eso primero—hacer churn de backups en un pool enfermo es una excelente forma de empeorarlo.

Task 2: Comprobar capacidad y si los snapshots están anclando espacio

cr0x@server:~$ zfs list -o name,used,avail,refer,usedbysnapshots -r rpool/data
NAME                  USED  AVAIL  REFER  USEDBYSNAPSHOTS
rpool/data            3.2T   410G    96K            0B
rpool/data/vm-101     420G   410G   110G          210G
rpool/data/vm-102     610G   410G   240G          290G

Qué significa: Para estos datasets ZVOL, una gran porción del espacio usado se debe a “used by snapshots.” Esos son bloques antiguos retenidos.
Decisión: Ajusta la retención de snapshots o mueve la retención larga a PBS/fuera del host. Considera si las VMs con muchas escrituras deberían estar en su propio pool o en un calendario distinto.

Task 3: Ver tus snapshots y si la nomenclatura es sensata

cr0x@server:~$ zfs list -t snapshot -o name,creation,used -r rpool/data/vm-101 | tail -n 5
rpool/data/vm-101@auto-2025-12-27_0100  Sun Dec 27 01:00  1.2G
rpool/data/vm-101@auto-2025-12-27_0200  Sun Dec 27 02:00  1.0G
rpool/data/vm-101@auto-2025-12-27_0300  Sun Dec 27 03:00  980M
rpool/data/vm-101@auto-2025-12-27_0400  Sun Dec 27 04:00  1.1G
rpool/data/vm-101@pre-upgrade           Sat Dec 27 04:22  0B

Qué significa: Tienes snapshots regulares más un snapshot manual “pre-upgrade”. Bien.
Decisión: Asegura que la retención coincida con la intención. El ascenso de la columna “used” es normal; picos súbitos apuntan a cambios grandes (actualizaciones del invitado, alta rotación en BDs).

Task 4: Identificar rápidamente los mayores responsables de snapshots

cr0x@server:~$ zfs list -o name,usedbysnapshots -s usedbysnapshots -r rpool/data | tail -n 5
rpool/data/vm-215     180G
rpool/data/vm-102     290G
rpool/data/vm-101     210G
rpool/data/vm-330     340G
rpool/data/vm-407     390G

Qué significa: Estos datasets están anclando la mayor parte del espacio de snapshots.
Decisión: Revisa la retención y el enfoque de backup para estas VMs primero. Si necesitas historial largo, no lo guardes en el pool primario.

Task 5: Confirmar propiedades de ZVOL que afectan backup/replicación

cr0x@server:~$ zfs get -o name,property,value -s local,default volblocksize,compression,recordsize rpool/data/vm-101
NAME               PROPERTY      VALUE
rpool/data/vm-101   volblocksize  16K
rpool/data/vm-101   compression   zstd

Qué significa: ZVOL usa volblocksize 16K, compresión activada. Recordsize no aplica a ZVOLs.
Decisión: No cambies volblocksize al azar después del aprovisionamiento a menos que entiendas las consecuencias. La compresión suele ser buena; mide CPU y latencia si estás en el límite.

Task 6: Verificar programación y resultados de scrub

cr0x@server:~$ zpool get scrubtime rpool
NAME   PROPERTY  VALUE                  SOURCE
rpool  scrubtime Sun Dec 22 03:00 2025  -

Qué significa: La última hora de scrub está registrada. Los scrubs detectan errores latentes antes de que una reconstrucción o restauración necesite esos bloques.
Decisión: Si no estás haciendo scrubs mensuales (o más a menudo para discos grandes/antiguos), prográmalos. Si los scrubs fallan o nunca se completan, trátalo como alarma roja.

Task 7: Comprobar presión del ARC antes de culpar a la “lentitud del backup”

cr0x@server:~$ arc_summary | egrep "ARC Size|ARC Target|Cache Hits|Cache Misses"
ARC Size:                               31.2 GiB
ARC Target Size:                        32.0 GiB
Cache Hits:                             92.1%
Cache Misses:                           7.9%

Qué significa: ARC está cerca del objetivo y la tasa de aciertos es saludable.
Decisión: Tu pool no está obviamente falto de memoria. Si la tasa de aciertos es baja y las misses altas durante backups, considera programar, limitar o aumentar memoria—especialmente en nodos todo-en-uno hipervisor/almacenamiento.

Task 8: Vigilar la latencia de I/O mientras corren los backups

cr0x@server:~$ zpool iostat -v rpool 5 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
rpool                        3.1T   410G    820   1600   110M   220M
  mirror-0                   3.1T   410G    820   1600   110M   220M
    ata-SAMSUNG_SSD_1           -      -    410    800    55M   110M
    ata-SAMSUNG_SSD_2           -      -    410    800    55M   110M
--------------------------  -----  -----  -----  -----  -----  -----

Qué significa: Ves escrituras sostenidas durante los backups. Esto es normal, pero la clave es si la latencia de los invitados se dispara.
Decisión: Si tus VMs se quejan en esa ventana, mueve ventanas de backup, reduce concurrencia o añade un target de backup separado para evitar golpear el pool principal.

Task 9: Confirmar definiciones de almacenamiento en Proxmox (y evitar respaldar a “local” por accidente)

cr0x@server:~$ pvesm status
Name             Type     Status     Total     Used     Available        %
local             dir     active      94G      12G         82G       12.8%
local-zfs         zfspool active     3.5T     3.1T        410G       88.3%
pbs-prod          pbs     active      18T      6.2T       11.8T      34.4%

Qué significa: Tienes un datastore PBS disponible. Bien. El almacenamiento local dir no es un destino de backup a menos que esté en hardware separado (normalmente no lo está).
Decisión: Asegura que los backups programados apunten a pbs-prod, no a local o local-zfs.

Task 10: Inspeccionar trabajos de backup y sus targets

cr0x@server:~$ cat /etc/pve/jobs.cfg | sed -n '1,120p'
backup: nightly-pbs
        enabled 1
        schedule 03:15
        storage pbs-prod
        mode snapshot
        compress zstd
        mailnotification always
        prune-backups keep-daily=14,keep-weekly=8,keep-monthly=6

Qué significa: Backups nocturnos van a PBS, con poda definida.
Decisión: Si falta la poda, añádela. Si el horario se solapa con scrub, replicación o carga máxima, muévelo.

Task 11: Ejecutar un vzdump manual para una sola VM y leer el resultado

cr0x@server:~$ vzdump 101 --storage pbs-prod --mode snapshot --compress zstd --notes-template '{{vmid}} {{name}}'
INFO: starting new backup job: vzdump 101 --storage pbs-prod --mode snapshot --compress zstd
INFO: Starting Backup of VM 101 (qemu)
INFO: Backup started at 2025-12-28 03:22:11
INFO: status = running
INFO: VM Name: app-prod-01
INFO: including disk 'scsi0' 'local-zfs:vm-101-disk-0' 110G
INFO: creating Proxmox Backup Server archive 'vm/101/2025-12-28T03:22:11Z'
INFO: transferred 33.1 GiB in 04:18 min, average speed 131.2 MiB/s
INFO: backup successful
INFO: Backup finished at 2025-12-28 03:26:30
INFO: Finished Backup of VM 101 (00:04:19)

Qué significa: Éxito no es solo “exit code 0”; es “archivo creado en PBS” con rendimiento y duración plausibles.
Decisión: Si la velocidad es muy baja, verifica iostat del pool, red y carga de PBS. Si dice que hizo backup a almacenamiento local, corrige los targets del trabajo de inmediato.

Task 12: Verificar salud del datastore PBS desde el nodo Proxmox (alcance básico + autenticación)

cr0x@server:~$ pvesm list pbs-prod | head
Volid                                                        Format  Type         Size  VMID
pbs-prod:backup/vm/101/2025-12-28T03:22:11Z                   pbs     backup   35567616   101
pbs-prod:backup/vm/102/2025-12-28T03:15:01Z                   pbs     backup   74448896   102
pbs-prod:backup/vm/215/2025-12-28T03:18:45Z                   pbs     backup   118382592  215

Qué significa: El nodo puede listar backups en PBS. Eso valida la configuración de almacenamiento y la autenticación a un nivel básico.
Decisión: Si listar falla intermitentemente, investiga la fiabilidad de la red y la salud del servicio PBS antes de confiar en los trabajos nocturnos.

Task 13: Comprobar la sanidad de la replicación ZFS (si usas send/receive)

cr0x@server:~$ zfs send -nP rpool/data/vm-101@auto-2025-12-27_0400 | head
size	11811160064

Qué significa: El dry-run muestra el tamaño del stream. Así pronosticas tiempo y ancho de banda para replicación.
Decisión: Si el tamaño es enorme para un “pequeño cambio”, puede que no estés haciendo sends incrementales, o la VM churnea bloques agresivamente. Ajusta calendario y retención, o cambia a PBS para eficiencia de dedupe.

Task 14: Confirmar que realmente puedes recibir en el destino (y que no estás sobrescribiendo producción)

cr0x@server:~$ ssh root@backupzfs "zfs list -o name,used,avail -r bpool/replica | head"
NAME                 USED  AVAIL
bpool/replica        1.1T  7.8T
bpool/replica/rpool  1.1T  7.8T

Qué significa: El target tiene un dataset/pool replica dedicado. Esto es higiene básica.
Decisión: Si estás recibiendo en un pool con nombre similar sin separación, estás a un bug de script de enviar destrucción en ambas direcciones.

Task 15: Hacer una restauración de prueba de una VM en un ID aislado (la única prueba que importa)

cr0x@server:~$ qmrestore pbs-prod:backup/vm/101/2025-12-28T03:22:11Z 9101 --storage local-zfs
restore vma archive: vm/101/2025-12-28T03:22:11Z
creating VM 9101 on target node
  restoring disk scsi0 size 110G to local-zfs:vm-9101-disk-0
progress 15% (read 5.0 GiB, write 5.0 GiB)
progress 62% (read 21.0 GiB, write 21.0 GiB)
progress 100% (read 33.1 GiB, write 33.1 GiB)
restore successful

Qué significa: Puedes restaurar. No “en teoría”, no “los logs están verdes”, sino creación real de VM y materialización del disco.
Decisión: Arráncala en una red aislada, valídala, luego destrúyela. Programa esto mensualmente como mínimo para servicios críticos.

Task 16: Comprobar correlación carga snapshot/backup con latencia de VM (vista rápida)

cr0x@server:~$ iostat -x 5 3
Linux 6.8.12 (server)   12/28/2025

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.10    0.00    6.55    8.40    0.00   72.95

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
nvme0n1         220.0  1400.0  95000  210000   9.80   0.35  58.00

Qué significa: %iowait y await elevados muestran que el sistema espera por almacenamiento. Durante backups eso puede ser esperado; await sostenido alto se correlaciona con lentitud de VMs.
Decisión: Si await salta a decenas/centenas de ms, reduce concurrencia de backups, cambia horario o separa I/O de backup del almacenamiento de producción.

Guion de diagnóstico rápido

Cuando los backups se ponen lentos, fallan o “suceden” pero las restauraciones son dolorosas, no quieres un seminario filosófico. Quieres una secuencia.

Primero: confirma que estás respaldando al lugar correcto

Revisa config de trabajos de Proxmox: target de almacenamiento, modo, poda.
Confirma que el destino es accesible y tiene espacio libre.

Segundo: identifica el dominio del cuello de botella (disco, CPU, red, PBS)

Latencia de disco: zpool iostat, iostat -x
Presión de CPU: top y “¿está la compresión consumiendo núcleos?”
Red: ip -s link, ss -s o los contadores del switch
Carga de PBS: trabajos de verificación del datastore, garbage collection, clientes concurrentes

Tercero: verifica presión de snapshots y capacidad del pool

zfs list -o usedbysnapshots para encontrar espacio anclado.
zpool list para la capacidad total; evita vivir por encima de ~80–85% en pools ocupados.

Cuarto: valida la mecánica de restauración

Elige una VM y ejecuta una restauración de prueba a un VMID temporal.
Si la restauración es lenta, el mismo cuello de botella probablemente existe, solo invertido (lectura intensiva desde el target de backup).

Quinto: reduce concurrencia antes de rediseñar el mundo

Muchos “incidentes” de backup en Proxmox son autoinfligidos por ejecutar demasiados backups al mismo tiempo.
La concurrencia es una perilla. Úsala.

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

1) “Tenemos snapshots, así que estamos respaldados.”

Sintoma: El pool no se importa y todo—discos de VM y snapshots—son inaccesibles.

Causa raíz: Los snapshots nunca salieron del dominio de fallo del pool.

Solución: Implementa PBS o replicación ZFS fuera del host. Requiere restauraciones de prueba mensuales como puerta para llamar a algo “respaldado”.

2) Los trabajos de backup están verdes, pero las restauraciones fallan

Sintoma: Ves entradas de backup, pero errores de restauración (chunks faltantes, fallos de autenticación, archivos corruptos).

Causa raíz: No hay simulacros de restauración; los problemas se acumulan en silencio (permisos, errores de poda del datastore, red intermitente).

Solución: Añade pruebas de restauración programadas. Para PBS, ejecuta trabajos de verificación y vigila tasas de fallo. Arregla límites de autenticación y la inestabilidad de red.

3) El pool ZFS se llena inesperadamente

Sintoma: df muestra espacio en algún sitio, pero ZFS reporta bajo AVAIL. Las escrituras de VM empiezan a fallar.

Causa raíz: La retención de snapshots ancla bloques; las VMs con alta rotación mantienen bloques antiguos vivos. También común: vivir al 90%+ de uso del pool.

Solución: Reduce la retención de snapshots. Mueve retenciones largas a PBS. Mantén pools por debajo de ~80–85% para control de rendimiento y fragmentación.

4) La replicación “funciona” y luego te das cuenta que replicó el desastre

Sintoma: Un borrado o encriptación por ransomware aparece en el réplica rápidamente.

Causa raíz: Replicación continua sin checkpoints retardados; la réplica se trata como espejo, no como copia de seguridad.

Solución: Usa replicación retardada, conserva historial de snapshots en la réplica y protege la réplica de las credenciales de producción. Para ransomware, la inmutabilidad importa.

5) Las copias provocan picos de latencia en VMs

Sintoma: Timeouts de aplicación durante la ventana de backup; gráficos de latencia de almacenamiento se disparan.

Causa raíz: Trabajos de backup compitiendo por IOPS y caché; demasiadas VMs concurrentes; scrubs/resilver ocurriendo al mismo tiempo.

Solución: Cambia horario, reduce concurrencia, mueve backups fuera del host, separa pools o añade medios más rápidos para la carga caliente.

6) “Ciframos el pool así que los backups están seguros”

Sintoma: El target de backup está sin cifrar, o las claves están almacenadas en el mismo hipervisor.

Causa raíz: Confundir cifrado en reposo con controles operativos de acceso; la gestión de claves tratada como ocurrencia tardía.

Solución: Cifra backups en el momento del backup (PBS lo soporta). Guarda claves por separado. Limita quién puede borrar backups y cómo.

Tres mini-historias corporativas desde el terreno

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

Una empresa mediana ejecutaba Proxmox en un host potente con SSDs en espejo. Tenían snapshots horarios durante dos semanas.
El equipo creía que estaban “cubiertos”, porque los rollbacks les habían salvado más de una vez tras despliegues de aplicaciones fallidos.

Entonces llegó un reinicio no planificado tras un corte de energía. El pool no se importó correctamente. Tenían un entorno de arranque, tenían snapshots
y tenían confianza. Lo que no tenían era una segunda copia de los discos de VM en ningún otro sitio.

La recuperación se convirtió en un proyecto de arqueología de almacenamiento: intentos de import con distintas banderas, comprobaciones de hardware y un miedo creciente a que la “solución” empeorara el daño.
Eventualmente recuperaron la mayoría, pero tomó tanto tiempo que el negocio empezó a tomar decisiones operativas basadas en servicio parcial.

El postmortem fue incómodo porque la “asunción equivocada” no era técnica; era semántica. Llamaban snapshots “backups.”
Una vez corregido el lenguaje, la arquitectura siguió. Desplegaron PBS en hardware separado, las pruebas de restauración se volvieron ticket recurrente y los snapshots fueron degradados a lo que son: barandillas de seguridad locales.

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

Otra organización decidió que los backups eran demasiado lentos, así que persiguieron el rendimiento. Aumentaron la concurrencia de backups y ajustaron la compresión para ser lo más agresiva posible.
La ventana de backup se redujo. Los gráficos lucían genial. Todos chocaron las manos.

Dos semanas después, los usuarios empezaron a quejarse de picos de latencia aleatorios a primera hora de la mañana. Nada obvio estaba “caído”, pero todo se sentía lento.
El equipo miró CPU primero—bien. Red—bien. Luego latencia de almacenamiento: feo.

La optimización había convertido los backups en una tormenta sostenida de lecturas/escrituras aleatorias justo cuando trabajos batch nocturnos también corrían dentro de invitados.
ZFS hacía su trabajo, pero el pool estaba fragmentado y muy utilizado. Los backups competían con producción, y producción perdió.

La solución fue aburrida: reducir concurrencia, mover las VMs más pesadas a otra ventana y dejar de tratar el rendimiento de backup como único KPI.
También añadieron una regla: si un cambio mejora la velocidad de backup pero aumenta la latencia p95 para producción, no es una optimización. Es un intercambio que no presupuestaste.

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

Un equipo de servicios financieros tenía una costumbre que parecía papeleo: cada mes, un ingeniero restauraba dos VMs críticas desde PBS en una red aislada.
Verificaban los health checks del servicio, entraban en la app y luego destruían las VMs de prueba. Tomaba una hora y no producía dashboards emocionantes.

Un día, una actualización del hipervisor salió mal. El nodo no arrancó y la importación del pool local fue inestable. No fue una pérdida total, pero no era confiable.
El equipo decidió rápidamente: dejar de tocar el host roto, restaurar en otro nodo y devolver servicios en limpio.

El plan de restauración funcionó porque lo habían ensayado. Ya sabían qué backups eran más rápidos de restaurar, qué redes conectar y qué credenciales eran necesarias.
Su outage se midió en unas pocas horas, no en días de “quizá podamos arreglar el pool.”

La moraleja: el ritual mensual de restauración había sido cuestionado como “trabajo administrativo.”
Después, nadie lo cuestionó de nuevo. Aburrido es una característica cuando el edificio está en llamas.

Listas de verificación / plan paso a paso

Paso a paso: construye una estrategia de copias que no mienta

Define RPO/RTO por servicio. Si no puedes decir “podemos perder X horas y estar inactivos Y horas”, no puedes elegir herramientas honestamente.
Mantén snapshots locales cortos. Úsalos para rollback, no para historial.
Despliega PBS en hardware separado. Discos distintos, energía distinta si es posible. Credenciales separadas.
Programa backups fuera de picos de I/O. Evita solapamiento con scrubs, resilvers y trabajos batch pesados.
Configura retención en el sistema de backup. Podar en PBS (o equivalente) para que la retención sea aplicable y visible.
Activa cifrado donde tenga sentido. Especialmente si los backups están fuera del sitio o accesibles por muchos sistemas.
Haz simulacros de restauración mensuales. Restaura una VM a un VMID nuevo, arráncala, valida y luego borra.
Monitoriza las señales aburridas. Capacidad del pool, finalización de scrubs, duración de trabajos de backup, duración de restauración, fallos de verificación.
Documenta el runbook de restauración. Dónde viven los backups, quién tiene acceso, cómo restaurar redes, en qué orden restaurar dependencias.

Checklist: antes de confiar en tu configuración

Backups almacenados fuera del host y fuera del pool
Credenciales separadas para borrar backups
Retención y poda configuradas
Al menos una restauración de prueba exitosa en los últimos 30 días
Scrubs de ZFS programados y completándose
Capacidad del pool bajo control (no vivir al 90% lleno)
Ventanas de backup que no dañan la latencia de producción

Checklist: cuando cambias algo riesgoso

Toma un snapshot manual con nombre humano (@pre-upgrade)
Confirma que existe el último backup exitoso en PBS para VMs críticas
Asegura que puedes alcanzar el target de backup ahora mismo
Tener un plan de rollback y un plan de restauración—son planes diferentes

Preguntas frecuentes

1) ¿Los snapshots de ZFS alguna vez son “suficientes” como backups?

Solo si tu definición de “copia de seguridad” excluye pérdida de hardware, corrupción del pool y compromiso de root—lo cual es una definición usada principalmente por gente que vende optimismo.
Para entornos reales: no.

2) Si replico snapshots ZFS a otro host, ¿es eso una copia de seguridad?

Puede serlo, si el destino es independiente y está protegido. Pero la replicación a menudo replica errores rápidamente.
Haz la replicación retardada, conserva historial en el destino y usa credenciales separadas para que root de producción no pueda destruir la réplica.

3) ¿Debo usar Proxmox Backup Server o vzdump a NFS?

PBS es la mejor opción por defecto: dedupe, cifrado, verificación, poda. NFS puede funcionar, pero debes diseñar inmutabilidad y verificación por tu cuenta,
y probablemente lo pagarás después con un desorden operativo.

4) ¿Necesito tanto snapshots como backups?

En la práctica, sí. Los snapshots son para rollback rápido y gestión de cambios. Las copias son para recuperación ante desastres y retención con auditoría.
Intentar forzar uno para hacer lo del otro suele producir dolor.

5) ¿Cuántos snapshots debo mantener en el pool de producción?

Mantén los mínimos necesarios para rollback. Para muchos entornos: horario cada hora durante 24–72 horas y diario durante 7–14 días.
Si necesitas meses, mantenlos fuera del host en el sistema de backup.

6) Mi pool está al 90% pero “todavía funciona.” ¿Por qué me dices que me importe?

Porque el rendimiento y el comportamiento de asignación de ZFS degradan a medida que el espacio libre disminuye, especialmente en pools ocupados. Además, los snapshots hacen que el “espacio libre” sea engañoso.
No quieres descubrir el acantilado durante un incidente cuando necesitas escrituras para restauraciones.

7) ¿Cómo hago los backups resilientes frente a ransomware?

Usa separación de credenciales, inmutabilidad (donde esté disponible), copias retardadas/offline y un sistema de backup que no pueda ser borrado por hipervisores comprometidos.
Además: simulacros de restauración, porque la recuperación ante ransomware es sobre todo “qué tan rápido podemos restaurar limpio.”

8) ¿Los scrubs de ZFS sustituyen a las copias de seguridad?

No. Los scrubs detectan y reparan corrupción usando redundancia. No protegen contra borrados, encriptación o pérdida catastrófica del pool.
Los scrubs ayudan a asegurar que cuando necesites tus datos, se lean correctamente.

9) ¿Cuál es la métrica más importante para las copias?

El tiempo de restauración para una carga representativa. No la duración del backup, no la ratio de dedupe. El negocio experimenta el tiempo de restauración.

10) ¿Qué debo hacer si los backups se ralentizan con el tiempo?

Revisa la capacidad (incluido el anclaje de snapshots), la latencia durante la ventana de backup y la concurrencia. Luego revisa la salud del target de backup.
Los backups lentos suelen ser síntoma de “pool demasiado lleno” o “demasiados trabajos a la vez”, no una maldición mística.

Conclusión: siguientes pasos que pagan la renta

Deja de llamar snapshots copias de seguridad. Súbelos a “herramientas de rollback” y automáticamente tomarás mejores decisiones sobre retención, capacidad y riesgo.
Luego construye copias reales que salgan del dominio de fallo, estén protegidas contra borrados fáciles y se prueben mediante restauraciones.

Pasos prácticos:

Elige una VM crítica y realiza una restauración de prueba desde tu sistema de backups esta semana. Cronométrala. Anota los pasos.
Audita dónde aterrizan tus backups. Si algo dice “local” en el mismo host, trátalo como conveniencia, no protección.
Mide el espacio anclado por snapshots y reduce retención en los peores responsables.
Programa scrubs y asegúrate de que se completen.
Implementa backups fuera del host (se recomienda PBS) con poda y verificación, y credenciales separadas para borrado.

Cuando llegue el mal día—y llegará—quieres que tu estrategia de backups sea aburrida, repetible y un poco arrogante. No porque ames la arrogancia,
sino porque tus usuarios aman el servicio.