Proxmox Backup Server vs Veeam para VMware: qué es mejor para restauraciones rápidas y operaciones simples

La decisión en 60 segundos

Si tu entorno es mayoritariamente VMware y necesitas flujos de trabajo probados de “ponme en marcha ahora” (Recuperación instantánea, restauración granular, elementos de aplicación, ecosistema amplio, opciones de cinta/nube, muchas salvaguardas), Veeam suele ser la opción más segura. No siempre es elegante. Pero ha sido probada en los modos de fallo exactos que tienen la mayoría de los entornos VMware.

Si quieres tubería de backup simple, rápida y nativa de Linux con excelente dedupe y rendimiento de restauración predecible y te sientes cómodo construyendo algo del pegamento de integración por tu cuenta, PBS puede ser un repositorio + motor de backup muy potente. Brilla cuando lo tratas como almacenamiento: buenos discos, ZFS ajustado sensatamente y una ruta de red que no sea una ocurrencia tardía.

La parte opinativa: no elijas basándote en ratios teóricos de dedupe. Elige según tu flujo de trabajo de restauración, la madurez operativa de tu equipo y qué pasa cuando el único administrador de backups está en un avión.

Broma #1: Los backups son como los paracaídas: tener uno es estupendo, descubrir que está empaquetado mal es un momento increíblemente malo.

Hechos y contexto que puedes usar en reuniones

• Las instantáneas de VMware cambiaron el diseño de backups. Las herramientas modernas de copia a nivel de imagen dependen de snapshots para obtener una vista consistente en el tiempo y luego mover los datos a otro sitio.
• Changed Block Tracking (CBT) fue un punto de inflexión. CBT permitió incrementales rápidos al rastrear regiones de disco cambiadas. También creó una clase de “incrementales silenciosamente incorrectos” cuando CBT se invalida o tiene bugs—de ahí la necesidad de fulls periódicos o verificación sintética de fulls.
• La deduplicación pasó de “agradable” a “obligatoria” conforme aumentó el sprawl de VMs. Pero desplazó el cuello de botella de la capacidad de disco a CPU, RAM y patrones de I/O aleatorio.
• ZFS popularizó el almacenamiento con integridad primero para hardware commodity. Checksums y corrección mediante scrub cambiaron las expectativas: el almacenamiento no debería podrir silenciosamente tus backups.
• La inmutabilidad se volvió mainstream porque el ransomware empezó a atacar backups. Cuando los atacantes aprendieron a borrar repositorios y catálogos, “air gap” e inmutabilidad dejaron de ser palabras de moda.
• La arquitectura proxy/repository de Veeam nació de restricciones de la era Windows. Es modular porque tenía que serlo: diferentes modos de transporte, distintos almacenamientos, diferentes redes, muchos patrones de despliegue.
• PBS se construyó con chunks direccionados por contenido desde el inicio. Almacena chunks deduplicados con checksums fuertes y expone un modelo directo: datastores, namespaces, verify, prune.
• Las funciones de “recuperación instantánea” son más antiguas de lo que la gente piensa. Montar un backup como una VM en ejecución es básicamente virtualización de almacenamiento—maduro en concepto, difícil en implementación.
• Los repositorios Linux se convirtieron en una buena práctica para Veeam con el tiempo, sobre todo porque XFS/Reflink y patrones de repositorio endurecidos encajan mejor con modelos de amenaza modernos que “un share de Windows”.

Qué significa realmente “restauración rápida” (y qué la ralentiza)

El tiempo de restauración no es un número único. Es una canalización:

1. Localizar la metadata rápido: catálogo, índices, cadenas de backup.
2. Leer los datos de backup rápido: throughput del repositorio, I/O aleatorio, rehidratación de dedupe, descompresión.
3. Escribir en producción rápido: rendimiento del datastore, red, comportamiento del controlador de almacenamiento.
4. Hacer que arranque: diferencias de drivers, consistencia de aplicaciones, peculiaridades de AD/SQL/Exchange, etc.

Los asesinos ocultos:

• I/O aleatorio pequeño en el repositorio (bases de datos de dedupe, stores de chunks, búsquedas de metadata).
• CPU infralimentada (descompresión/encriptación/rehidratación de dedupe no son gratis).
• Sobresuscripción de la red (10GbE que se comporta como 1GbE cuando el buffer del switch está sufriendo).
• Patología de cadenas de snapshots (stun durante la eliminación de snapshots, picos de latencia de almacenamiento).
• “Restaurar al mismo lugar roto” (escribir de vuelta en un datastore que ya está con latencia elevada).

Las restauraciones rápidas vienen de un principio aburrido: haz que la ruta de restauración sea la ruta más simple. Las funciones elegantes no vencen a la física. La sortean.

Arquitecturas: cómo PBS y Veeam realmente mueven bytes

PBS en la práctica

PBS es un servidor de backup dedicado con datastores. Los backups se fragmentan en chunks, se comprimen y se deduplican. La integridad es de primera clase: los chunks tienen checksums; puedes verificar datastores y detectar corrupción temprano. Operativamente, se siente como un appliance de almacenamiento que además habla backup.

Para VMware, el enfoque habitual es: un proceso de backup lee datos de VM (a menudo vía agentes o herramientas de integración) y los deposita en PBS. PBS en sí no es una suite “clic siguiente para proteger todo” para VMware de la misma manera que Veeam lo es. Es excelente en lo que hace: almacenar y servir backups rápido y de forma fiable. La historia de integración puede requerir más ingeniería según tu entorno.

Veeam para VMware en la práctica

Veeam es una plataforma: servidor de backup, proxies, repositorios, scale-out repositories (SOBR), varios transportes (HotAdd, NBD, Direct SAN), procesamiento consciente de aplicaciones y una larga lista de modalidades de restauración. Está diseñada para situarse en medio del caos empresarial y aun así hacer el trabajo.

El intercambio: más perillas, más piezas móviles, más cosas que parchear, más modelos de permisos, más certificados, más “por qué este servicio usa este puerto”. Obtienes poder, pero también responsabilidad.

Implicación en velocidad de restauración:

• PBS tiende a ser predecible si el almacenamiento subyacente es sano y no lo privas de RAM/CPU.
• Veeam tiende a ser adaptable—puedes añadir proxies, cambiar transporte, hacer tiering a distinto almacenamiento—pero es más fácil construir accidentalmente una ruta de restauración que es rápida en el papel y lenta en la realidad.

Implicación operativa:

• PBS es tipo appliance. Menos componentes. Modelo mental fuerte.
• Veeam es tipo sistema. Necesitas estándares: nombres, diseño de repositorios, colocación de proxies, gestión de credenciales y control de cambios.

Rutas de restauración que importan: VM completa, nivel archivo y momentos de “oops”

Restauración de VM completa (RTO es rey)

La ventaja de Veeam es la amplitud de flujos de restauración y el pulido operativo alrededor de ellos. Recuperación instantánea de VM (ejecutar la VM desde el repositorio de backup) puede reducir drásticamente el RTO cuando el almacenamiento de producción es lento, está muerto o políticamente no disponible. El riesgo es que “instantáneo” se convierta en “instantáneamente lento” si el repositorio no fue construido para patrones de I/O de VM.

PBS puede restaurar eficientemente si tu canal escribe de vuelta a almacenamiento VMware a velocidad de línea y no te atrapa en thrash de metadata. Pero PBS no crea mágicamente una VM en ejecución desde un store deduplicado sin la orquestación orientada a VMware que lo rodea. Si esperas un arranque instantáneo con un solo botón para VMware, Veeam es simplemente más probable que te dé lo que quieres hoy.

Restauración a nivel archivo (la solicitud más común)

La mayoría de las restauraciones no son desastres. Son “quién borró la hoja de cálculo” y “ese archivo de configuración de la semana pasada”. Veeam tiene explorers maduros para sistemas de archivos invitados y aplicaciones en muchos entornos. PBS puede soportar restauración a nivel archivo dependiendo de cómo hagas el backup (agentes, nivel invitado o imágenes montadas), pero no es un universo “Explorer” uniforme para cada carga de trabajo.

Elementos de aplicación (donde el tiempo se va a morir)

Restaurar objetos de AD, puntos en el tiempo de SQL, recuperación de ítems de Exchange: aquí es donde los vendors empresariales de backup justifican su coste. Veeam es fuerte aquí porque ha invertido años en procesamiento consciente de aplicaciones y herramientas de recuperación. PBS puede ser parte de una estrategia, pero quizá estés ensamblando backups nativos de la app, scripts y validación por tu cuenta.

Ransomware y restauraciones cuando “no confío en el entorno”

Backups inmutables y repositorios endurecidos son ahora requisitos básicos. Veeam tiene patrones sólidos para repositorios Linux endurecidos y ventanas de inmutabilidad. PBS, al ser nativo de Linux con verificación por checksum y un modelo de datastore claro, se presta a diseñar soluciones robustas y resistentes a manipulaciones—especialmente combinado con acceso administrativo restringido y destinos de replicación offline.

Broma #2: Lo único más optimista que “restauraremos rápido” es “probamos las restauraciones el próximo trimestre”.

Operaciones simples: lo que harás cada semana

Las restauraciones rápidas son principalmente consecuencia de operaciones simples hechas de forma consistente.

Cómo se ve “simple” con PBS

• Monitorizar uso del datastore, conteo de chunks, horarios de verify y horarios de prune.
• Mantener ZFS sano: scrubs, SMART, dimensionamiento de ARC, elecciones de recordsize.
• Probar restauraciones restaurando realmente (no admirando dashboards).
• Replicar a un segundo PBS o a un objetivo offline con control de acceso estricto.

Las operaciones con PBS se sienten como “operaciones de almacenamiento más una UI de backup”. Eso es bueno si tienes competencia en Linux. Es malo si la habilidad principal de tu equipo de backups es hacer clic en asistentes esperando que el asistente sea amable.

Cómo se ve “simple” con Veeam

• Mantener cadenas de backup, repositorios, extents de SOBR e inmutabilidad.
• Parchear el servidor de backup y los componentes. Mantener certificados y credenciales en orden.
• Vigilar carga de proxies y rendimiento de transporte (HotAdd vs NBD vs Direct SAN).
• Ejecutar jobs de SureBackup / validación para que no descubras restauraciones rotas durante un corte.

Las operaciones con Veeam se sienten como “gestionar un servicio pequeño”. Si lo haces bien, es fluido. Si lo haces de manera casual, se vuelve complicado.

Una cita de confiabilidad que importa

Esperanza no es una estrategia. — idea parafraseada comúnmente atribuida al liderazgo de operaciones (usada ampliamente en cultura de confiabilidad)

No la cito literalmente más allá de eso porque la atribución varía, pero el punto es sólido: si no puedes describir tu proceso de restauración sin la palabra “esperanza”, no tienes un proceso de restauración.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estos son los tipos de comprobaciones que ejecutas cuando las restauraciones son lentas o cuando diseñas para restauraciones rápidas. Cada tarea incluye: un comando, salida realista, lo que significa y qué decisión tomar.

Tarea 1: Demostrar que el repositorio no está con CPU escasa (PBS)

cr0x@pbs01:~$ lscpu | egrep 'Model name|CPU\\(s\\)|Thread|Core'
CPU(s):                          16
Model name:                      AMD EPYC 7302P 16-Core Processor
Thread(s) per core:              2
Core(s) per socket:              16

Qué significa: Bastantes cores para compresión/encriptación y trabajo de metadata. Si vieras 2–4 cores aquí, esperarías que las restauraciones “se sientan” lentas incluso con discos rápidos.

Decisión: Si la CPU es pequeña, escala la CPU antes de culpar a los discos. Los stores de dedupe consumen CPU, no solo capacidad.

Tarea 2: Comprobar RAM disponible y comportamiento de swap (PBS/Veeam Linux repo)

cr0x@pbs01:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            64Gi        18Gi        12Gi       1.2Gi        34Gi        45Gi
Swap:          4.0Gi          0B       4.0Gi

Qué significa: Bien. “Available” es alto y swap no se usa. Si el swap está activo, es probable que haya picos de latencia durante restauraciones.

Decisión: Si swap se usa durante restauraciones, añade RAM y ajusta servicios que consumen mucha memoria. Para ZFS, valida que ARC no esté estrangulando el sistema.

Tarea 3: Confirmar salud del pool ZFS (PBS en ZFS)

cr0x@pbs01:~$ zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 05:12:44 with 0 errors on Sun Dec 22 03:10:11 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            ata-SSD1                ONLINE       0     0     0
            ata-SSD2                ONLINE       0     0     0
            ata-SSD3                ONLINE       0     0     0
            ata-SSD4                ONLINE       0     0     0

errors: No known data errors

Qué significa: Scrub limpio, sin errores de checksum. Si ves errores CKSUM, tu “restauración lenta” podría ser en realidad “el hardware está mintiendo”.

Decisión: Cualquier error de checksum: deja de tunear y empieza a reemplazar componentes. Los backups almacenados en almacenamiento inestable son ficción cara.

Tarea 4: Vigilar saturación de I/O (ambos)

cr0x@pbs01:~$ iostat -xm 2 3
Linux 6.2.16 (pbs01)  12/28/2025  _x86_64_ (16 CPU)

Device            r/s     w/s   rkB/s   wkB/s  await  %util
nvme0n1          5.2    210.4    980   52240   2.10  48.5
nvme1n1          4.9    208.8    910   51800   2.04  46.9

Qué significa: Utilización por debajo del 80% y await ~2ms está sano. Si %util está cerca del 100% con await subiendo, tu repositorio es el cuello de botella.

Decisión: Si está saturado: mueve a almacenamiento más rápido, añade vdevs, repara el layout de RAID o separa workloads con mucha metadata en SSD/NVMe.

Tarea 5: Verificar integridad del datastore regularmente (PBS)

cr0x@pbs01:~$ proxmox-backup-manager datastore verify backup-store
Starting datastore verification...
Checked 124988 chunks, 0 errors, 0 corruptions detected
Verification finished successfully

Qué significa: Tus datos de backup son legibles y consistentes ahora, no solo “presentes”. La verificación es la diferencia entre confianza y sensaciones.

Decisión: Si la verificación encuentra corrupción: aisla el almacenamiento, restaura desde réplica/offsite y trátalo como un incidente de almacenamiento.

Tarea 6: Inspeccionar estado de prune y realidad de retenciones (PBS)

cr0x@pbs01:~$ proxmox-backup-manager prune-job list
ID   Store        Schedule          Keep Last  Keep Daily  Keep Weekly  Keep Monthly
1    backup-store 02:30             7          14          8            12

Qué significa: La retención está explícitamente configurada. Si prune falla o falta, los datastores crecerán hasta que te enteres por un outage.

Decisión: Si el crecimiento de uso es inesperado, valida que prune se ejecute y que “keep” se alinee con cumplimiento y matemáticas de capacidad.

Tarea 7: Confirmar ruta de red y desajustes de MTU (ambos)

cr0x@veeamproxy01:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
ens192           UP             00:50:56:aa:bb:cc
ens224           UP             00:50:56:dd:ee:ff

cr0x@veeamproxy01:~$ ip -d link show ens224 | egrep 'mtu|state'
2: ens224: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 state UP mode DEFAULT group default qlen 1000

Qué significa: Jumbo frames habilitados en una interfaz. Eso está bien solo si todo el camino lo soporta.

Decisión: Si las restauraciones son extrañamente lentas o los retransmisos se disparan, fuerza consistencia de MTU de extremo a extremo (todo 9000 o todo 1500) y vuelve a probar.

Tarea 8: Medir throughput real con iperf3 (ambos)

cr0x@pbs01:~$ iperf3 -s
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------

cr0x@esxjump01:~$ iperf3 -c pbs01 -P 4
[SUM]   0.00-10.00  sec  37.5 GBytes  32.2 Gbits/sec                  receiver

Qué significa: La red no es tu cuello de botella. Si obtienes 3–5 Gbits/sec en una red “10Gb”, empieza a buscar problemas en el switch, offloads de la NIC o congestión.

Decisión: Si el throughput es bajo, arregla la red antes de rediseñar el software de backup. No te adelantes a un cable defectuoso.

Tarea 9: Comprobar latencia de disco en datastores VMware (enfoque en síntoma)

cr0x@esx01:~$ esxcli storage core device stats get -d naa.600508b1001c3ad5
Device: naa.600508b1001c3ad5
  Successful Commands:  18922301
  Failed Commands:      0
  Read Latency (ms):    3.12
  Write Latency (ms):   18.47

Qué significa: La latencia de escritura es alta. Las restauraciones que escriben en este datastore se arrastrarán, independientemente de la velocidad del repositorio.

Decisión: Restaura a almacenamiento alterno (otro datastore/cluster) o arregla el almacenamiento de producción primero. No viertas backups en un desagüe bloqueado.

Tarea 10: Identificar transporte y cuellos de botella del proxy Veeam (servidor Windows Veeam)

cr0x@veeam-win:~$ powershell -NoProfile -Command "Get-Service Veeam* | Select Name,Status | Format-Table -Auto"
Name                           Status
----                           ------
VeeamBackupSvc                 Running
VeeamBrokerSvc                 Running
VeeamCatalogSvc                Running
VeeamCloudSvc                  Running

Qué significa: Los servicios principales están en ejecución. Si los jobs de restauración se quedan en “Initializing”, este es el paso uno: confirma que los servicios estén vivos antes de perseguir fantasmas de almacenamiento.

Decisión: Si los servicios no están corriendo, arregla eso primero (logs, dependencias, parches). Sin servicio, no hay restauración.

Tarea 11: Validar opciones de montaje de inmutabilidad en repositorio Linux endurecido (repo Veeam Linux)

cr0x@veeamrepo01:~$ mount | grep /backup
/dev/sdb1 on /backup type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,prjquota)

Qué significa: XFS montado con project quotas (común en patrones de repositorio endurecido). Si esto falta, la inmutabilidad y los controles de espacio pueden no comportarse como esperas.

Decisión: Si las opciones de montaje no coinciden con tu diseño endurecido, detente y corrígelo. Las características de seguridad que no están realmente habilitadas son solo teatro.

Tarea 12: Confirmar espacio libre del repositorio y saneidad de inodos (ambos)

cr0x@veeamrepo01:~$ df -h /backup
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1        80T   61T   19T  77% /backup

Qué significa: 77% usado está generalmente bien. Muchos sistemas se degradan operativamente cerca de lleno; las operaciones de prune y merge pueden provocar picos.

Decisión: Si estás por encima de ~85–90% en repositorios, planifica capacidad antes de “optimizar”. Operar cerca del máximo causa sorpresas feas en restauraciones.

Tarea 13: Detectar pérdida de paquetes y retransmisos (clásico de lentitud en restauración)

cr0x@pbs01:~$ ss -ti dst :5201 | head -n 12
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0      0      10.10.20.10:5201   10.10.20.50:50944
	 cubic wscale:7,7 rto:204 rtt:0.402/0.033 ato:40 mss:8960 pmtu:9000 rcvmss:536 advmss:8960 cwnd:560 bytes_acked:24389425 segs_out:31233 segs_in:29112 send 99.1Mbps lastsnd:4 lastrcv:4 lastack:4 pacing_rate 198Mbps retrans:12/31320

Qué significa: Hay retransmisos. Algunos son normales; muchos no. La pérdida convierte “10GbE” en “¿por qué mi restauración aún está en 12%?”

Decisión: Si los retransmisos suben durante ventanas de restauración, inspecciona desajustes de MTU, errores en puertos de switch, firmware de NIC y congestión.

Tarea 14: Detectar configuraciones de compresión/datasets ZFS que te perjudiquen (PBS)

cr0x@pbs01:~$ zfs get -o name,property,value compression,recordsize tank/pbs
NAME      PROPERTY     VALUE
tank/pbs  compression  zstd
tank/pbs  recordsize   128K

Qué significa: Valores razonables por defecto para muchas cargas de backup. Si recordsize es pequeño, el overhead de metadata crece; si la compresión está apagada, pagas en capacidad e I/O.

Decisión: No “tunes” al azar. Si la restauración está limitada por CPU, prueba cambiar niveles de compresión. Si está limitada por I/O, evita ajustes que exploten IOPS.

Tarea 15: Confirmar sincronización horaria (a los catálogos no les gusta el viaje en el tiempo)

cr0x@pbs01:~$ timedatectl status | egrep 'System clock synchronized|NTP service|Time zone'
Time zone: UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active

Qué significa: El tiempo está sano. Puntos de restauración, retención y validez de certificados pueden salir por la tangente cuando el tiempo se desvía.

Decisión: Si el tiempo no está sincronizado, arregla NTP primero. Luego revisa los problemas “misteriosos” de retención y autenticación.

Tres mini-historias corporativas desde las trincheras

1) Incidente causado por una suposición errónea: “La red está bien”

Tenían un diseño limpio en papel: almacenamiento de repositorio rápido, múltiples proxies de backup y una separación clara entre VLANs de producción y backup. Las restauraciones eran lentas, pero solo a veces. El equipo culpó a la dedupe y la compresión, porque son las piezas visibles.

La suposición equivocada fue sutil: “Si los backups terminan de noche, las restauraciones serán rápidas”. Los backups eran mayormente escrituras secuenciales en el repositorio. Las restauraciones eran lecturas mixtas, más aleatorias y más sensibles a pérdida de paquetes. Diferente patrón de tráfico, diferente dolor.

Durante una restauración real—una VM de aplicación con un RTO ajustado—el throughput osciló salvajemente. El equipo de backup escaló a almacenamiento, almacenamiento escaló a VMware, VMware escaló a networking. Todos llegaron con gráficos. Nadie tenía una medida end-to-end única.

Una vez que ejecutaron pruebas sostenidas de iperf3 durante la ventana de restauración, la verdad apareció: microbursts y drops de buffer en un puerto top-of-rack que servía al repositorio. No estaba “caído”. Simplemente castigaba el tráfico silenciosamente en el peor momento.

Arreglar la configuración del puerto y alinear MTU end-to-end hizo más por el tiempo de restauración que cualquier ajuste al repositorio. La lección quedó: mide la ruta por la que restauras, no la ruta que esperas tener.

2) Optimización que salió mal: “Dedupe máxima en todos lados”

Otro equipo persiguió ahorro de costos. Estaban orgullosos de sus ratios de dedupe. Sintonizaron todo para máxima compresión y dedupe agresiva, luego presumiendo la reducción de capacidad en las revisiones trimestrales. El repositorio de backups parecía un milagro.

Entonces una actualización de cluster salió mal y necesitaban restaurar varias VMs medianas rápidamente. Las restauraciones empezaron rápidas y luego se estancaron. La CPU en el repositorio se quedó al máximo; las colas de I/O crecieron; la latencia pasó de milisegundos a “vete a tomar un café”.

La optimización era matemáticamente correcta e operativamente errónea: su hardware de repositorio estaba dimensionado para ingest de backup, no para rehidratación de restore a escala. La compresión máxima significó coste máximo de CPU justo cuando necesitaban throughput.

Lo arreglaron de forma aburrida: redujeron niveles de compresión, aumentaron CPU y separaron workloads para que VMs de alto cambio no compartieran el mismo cuello de botella que objetivos críticos de restauración. La dedupe siguió siendo buena. Las restauraciones se volvieron predecibles.

Conclusión: optimiza para RTO primero, eficiencia de almacenamiento segundo. Nadie gana un outage presentando ratios impresionantes.

3) Práctica aburrida pero correcta que salvó el día: tests rutinarios de restauración

Una organización tenía reputación de aburrida. Control de cambios. Ventanas de parches. Documentación molosamente actual. Cada mes, ejecutaban pruebas de restauración: una restauración completa de VM, una restauración de archivo, una recuperación de elemento de aplicación y una prueba de “restaurar a red alternativa”.

No era glamuroso. Tampoco opcional. Trataron la prueba de restauración como simulacros de incendio: no los cancelas porque el edificio no se ha incendiado últimamente.

Cuando el ransomware golpeó una unidad de negocio, el plan de respuesta ya era memoria muscular. Restauraron sistemas críticos en un segmento de red aislado, validaron integridad y luego planearon la reintroducción. La línea temporal no fue “heroica”. Fue constante.

Aún así perdieron tiempo. Todos lo hacen. Pero no perdieron la trama. Sin improvisación, sin “alguien recuerda la contraseña del repositorio”, sin descubrimiento frenético de drivers faltantes.

Eso es lo que compra la operativa simple: menos sorpresas. En una crisis, el aburrimiento es una característica.

Guion de diagnóstico rápido

Cuando las restauraciones son lentas, no tienes tiempo para filosofar. Necesitas encontrar el cuello de botella en 15 minutos, no después del postmortem.

Primero: determina dónde vas lento (lectura, escritura o cómputo)

• ¿Está saturada la lectura del repositorio? Comprueba iostat -xm en el repositorio durante la restauración. Busca %util alto y await en aumento.
• ¿Está saturada la escritura de producción? Comprueba la latencia del datastore en ESXi. Latencia de escritura alta significa “restaurar en arena movediza”.
• ¿La CPU está al límite? Comprueba CPU en repositorio y proxy/servidor de backup. CPU de usuario alta durante la restauración suele significar sobrecarga por descompresión/encriptación.

Segundo: confirma que la red no te está mintiendo

• Ejecuta iperf3 entre redes de origen y destino de la restauración.
• Revisa retransmisos con ss -ti (Linux) y contadores del puerto del switch si están disponibles.
• Valida MTU end-to-end. MTU mezclada es un fallo clásico de “funciona pero lento”.

Tercero: comprueba la cadena de backup y salud de la metadata

• Para PBS: ejecuta schedules de datastore verify y busca errores; asegúrate de que prune no esté atascado y el almacenamiento no esté casi lleno.
• Para Veeam: confirma servicios, disponibilidad de repositorio y que la cadena de jobs no esté en un estado extraño (p. ej., incrementos corruptos, extents faltantes).

Cuarto: aisla con una prueba de restauración controlada

• Restaura una sola VM a almacenamiento/red alternos.
• Compara throughput con la restauración en producción para demostrar si el datastore destino es el culpable.
• Mide. No adivines.

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

1) Síntoma: “La recuperación instantánea es instantánea… pero dolorosamente lenta”

Causa raíz: El almacenamiento del repositorio está optimizado para ingest secuencial de backups, no para I/O aleatorio de lectura necesario para ejecutar VMs.

Solución: Pon workloads de “ejecución instantánea” en medios rápidos (NVMe/SSD), extents separados, o acepta que la recuperación instantánea es una herramienta de triage, no un estado de ejecución a largo plazo.

2) Síntoma: La velocidad de restauración varía salvajemente día a día

Causa raíz: Congestión de red, pérdida de paquetes o un sistema de almacenamiento compartido con vecinos ruidosos.

Solución: Mide throughput durante ventanas de restauración (iperf3), revisa retransmisos, implementa QoS o aísla el tráfico de backup y evita restaurar en un datastore muy ocupado.

3) Síntoma: Los backups tienen éxito, las restauraciones fallan por corrupción o puntos faltantes

Causa raíz: No hay verificación rutinaria; errores en el almacenamiento subyacente; cadenas rotas.

Solución: PBS: programa datastore verify y scrubs; reemplaza discos fallando. Veeam: habilita health checks, fulls activos/sintéticos periódicos con verificación y ejecuta tests de restauración.

4) Síntoma: El repositorio se llena “inesperadamente” y los jobs empiezan a fallar

Causa raíz: Misconfiguración de retención/prune, limpieza deshabilitada o ventanas de inmutabilidad que exceden la planificación de capacidad.

Solución: Audita retención e inmutabilidad, verifica operaciones de prune/merge, aplica umbrales de capacidad y alertas antes de 85–90% de uso.

5) Síntoma: Las instantáneas de VMware crecen y las VMs quedan stun durante ventanas de backup/restore

Causa raíz: La eliminación de snapshots es costosa para el almacenamiento; cadenas largas de snapshots por lecturas de backup lentas; problemas con CBT o quiescing.

Solución: Mejora el throughput de lectura de backup (modo de transporte, colocación de proxies), mantén snapshots de corta duración e investiga la configuración de quiescing de VM/aplicación.

6) Síntoma: “Restauramos, pero la app está rota”

Causa raíz: Backups crash-consistent donde se requería application-consistent, o dependencias faltantes (DNS/AD/sincronización horaria).

Solución: Usa procesamiento consciente de aplicaciones cuando sea necesario, documenta el orden de dependencias y valida la recuperación de la app en pruebas.

7) Síntoma: El equipo de seguridad dice que los backups no son resilientes frente a ransomware

Causa raíz: Infraestructura de backup comparte credenciales admin con producción, repositorios son borrables o la inmutabilidad no está realmente aplicada.

Solución: Separa identidades, aplica inmutabilidad/repositorios endurecidos, restringe acceso shell y mantiene una copia offline/offsite con credenciales independientes.

Listas de verificación / planes paso a paso

Plan A: Si eliges Veeam y quieres restauraciones rápidas sin drama

1. Diseña para la restauración, no para el backup. Elige almacenamiento de repositorio que soporte lecturas aleatorias (SSD/NVMe tiering ayuda).
2. Coloca proxies intencionalmente. Evita “un proxy VM en el mismo host sobrecargado”. Usa varios proxies si la concurrencia importa.
3. Estandariza el modo de transporte. Prueba HotAdd vs NBD vs Direct SAN en tu entorno y documenta el ganador.
4. Construye la inmutabilidad correctamente. Patrones de repositorio Linux endurecido, credenciales separadas y acceso estricto. No hay admin de dominio compartido.
5. Define SLOs operativos. Ejemplo: “Restaurar una VM tier-1 dentro de X minutos en condiciones de prueba”.
6. Automatiza pruebas de restauración. Usa jobs de verificación y simulacros regulares. Hazlo evento de calendario, no estado de ánimo.
7. Alerta sobre salud del repositorio. Espacio libre, fallos de jobs y comportamiento inusual de cadenas. Detecta antes del outage.

Plan B: Si eliges PBS como tu almacenamiento de backups y quieres operaciones simples

1. Sobredimensiona discos y RAM un poco. Los stores de dedupe aman RAM y IOPS consistentes.
2. Usa ZFS como un adulto. Scrubs programados, monitorización SMART, ashift razonable y sin “controladora RAID misteriosa” haciendo cosplay de write-hole.
3. Programa verify y prune. Haz las comprobaciones de integridad rutinarias, no heroicas.
4. Separa dominios de fallo. Replica a otro PBS o a un target independiente. Evita “mismo rack, mismo switch, misma alimentación”.
5. Documenta runbooks de restauración. Exactamente cómo restauras a VMware, incluidas credenciales, red y dónde caen las VMs restauradas.
6. Prueba restauraciones mensualmente. VM completa, nivel archivo y al menos un procedimiento de recuperación específico de app.
7. Limita el radio de blast de admins. Los admins de backup no deberían ser las mismas cuentas que pueden borrar todo al instante.

Plan C: Enfoque híbrido que suele ganar

Si eres pragmático (bien), notarás esto: Veeam y PBS no tienen que ser mutuamente excluyentes en espíritu. Muchos equipos tienen éxito con:

• Veeam para orquestación nativa de VMware y flujos de restauración.
• Disciplina de almacenamiento Linux/ZFS/PBS para repositorios: comprobaciones de integridad, rendimiento predecible, principios de inmutabilidad.

Incluso si PBS no es tu orquestador primario para VMware, aún puedes aprender de su filosofía de diseño: verify, prune, checksum, replicate y mantenerlo simple.

Preguntas frecuentes

1) ¿Cuál es más rápido en restauraciones: PBS o Veeam?

Veeam es más rápido para “poner algo en marcha” en muchas empresas VMware porque Recuperación instantánea de VM está madura. PBS puede ser extremadamente rápido moviendo datos de vuelta cuando la canalización está bien diseñada. La respuesta práctica: Veeam gana en modalidades de restauración; PBS gana en comportamiento de almacenamiento predecible cuando está bien construido.

2) ¿Cuál es el mayor predictor del rendimiento de restauración?

El rendimiento de lectura del repositorio bajo I/O aleatorio más la latencia de escritura del datastore de producción. Si cualquiera de los dos es malo, las restauraciones serán malas. Las funciones no te salvarán.

3) ¿Puedo obtener resiliencia contra ransomware con ambos?

Sí, pero debes implementarlo. Veeam usa comúnmente repositorios Linux endurecidos y ventanas de inmutabilidad. PBS soporta verificación de integridad y puede desplegarse con controles de acceso estrictos y replicación a un objetivo aislado. El punto débil suele ser identidad y acceso, no el software.

4) ¿Por qué fallan restauraciones cuando los backups “tuvieron éxito”?

Porque “job de backup exitoso” a menudo significa “datos movidos”, no “datos restaurables”. Necesitas verificación (PBS verify / scrubs ZFS) y pruebas rutinarias de restauración (verificación Veeam / pruebas estilo SureBackup) para atrapar fallos silenciosos.

5) ¿Vale siempre la pena la dedupe para backups VMware?

Usualmente sí por capacidad, pero puede perjudicar el rendimiento de restauración si CPU e IOPS no están dimensionados para la rehidratación. Si tu RTO es estricto, considera menos compresión/dedupe agresiva o compute/almacenamiento más rápido en el repositorio.

6) ¿Debo restaurar de vuelta al mismo datastore?

Sólo si el datastore está sano. Si la latencia de escritura del datastore es alta, restaurar a él es sabotaje propio. Restaura a almacenamiento alterno, valida que la VM arranca y luego migra cuando el entorno esté estable.

7) ¿Cuál es el fallo operativo más común con Veeam?

La proliferación: demasiados proxies/repositorios configurados sin estándares, además de parches inconsistentes y mala higiene de credenciales. Terminas con un sistema potente que es difícil de razonar durante un incidente.

8) ¿Cuál es el fallo operativo más común con PBS?

Subestimar la ingeniería del almacenamiento. La gente lo trata como una caja mágica de dedupe y la despliega sobre discos mediocres, controladoras RAID cuestionables o hardware subdimensionado. PBS te dirá la verdad—siendo lento.

9) ¿Necesito 10GbE (o más) para restauraciones rápidas?

Si tienes VMs grandes y RTOs estrictos, sí—al menos 10GbE, a menudo más. Pero ancho de banda sin baja pérdida y MTU consistente es un tigre de papel. Mide throughput y retransmisos durante ventanas de restauración.

10) ¿Cómo hago que las operaciones de restauración sean “simples” para el on-call?

Escribe un runbook con: dónde caen las restauraciones, cómo validar el arranque/salud de la app, quién aprueba la colocación en la red y qué significa “terminado”. Luego ejecuta simulacros mensuales. La simplicidad se entrena, no se compra.

Próximos pasos que realmente puedes hacer

1. Elige tu flujo de restauración primario. Si necesitas arranque instantáneo desde backups como movimiento estándar, inclínate por Veeam.
2. Benchmarkea tu ruta de restauración. Ejecuta iperf3, comprueba iostat del repositorio y la latencia de datastores ESXi. Arregla el enlace más lento primero.
3. Implementa verificación. PBS datastore verify + scrubs ZFS, o health checks de Veeam más pruebas programadas de restauración. Hazlo rutinario.
4. Diseña inmutabilidad y control de acceso deliberadamente. Separa credenciales, reduce el radio de blast y conserva al menos una copia fuera del alcance de identidades de producción comprometidas.
5. Haz un drill de restauración completa este mes. No una restauración de archivo. No una captura de pantalla. Una VM real arrancada con una lista de verificación de validación.

Si quieres la recomendación directa: la mayoría de las empresas VMware deberían empezar con Veeam por seguridad operativa, luego aplicar la disciplina al estilo PBS en la capa de repositorio. Si ya gestionas bien Linux/almacenamiento y valoras un núcleo de backup más simple, PBS puede ser una elección limpia, rápida y que preserva la cordura—siempre que ingenieres la integración con VMware y pruebes las restauraciones en serio.