Problema

Los equipos de infraestructura que manejan cientos de terabytes de datos suelen combinar sistemas de archivos avanzados (ZFS, Btrfs) con soluciones de backup de terceros. Cuando el motor de backup no reconoce nativamente el sistema de archivos, los trabajos pueden fallar al intentar crear archivos de backup (VBK) que superan el límite interno de Veeam (≈ 218 TiB). El síntoma típico es un error inmediato al iniciar el job, sin que se haya procesado ni un solo bloque de datos. El problema se vuelve crítico cuando la arquitectura de almacenamiento está basada en pools grandes y la estrategia de backup necesita cubrir todo el volumen.

En entornos mixtos (Linux + Windows) la presión aumenta: los servidores de archivos pueden estar en Linux con ZFS, mientras que la mayor parte de la carga de trabajo (bases de datos, aplicaciones) corre en Windows Server. La incompatibilidad entre Veeam y ZFS obliga a replantear la capa de file server o a introducir una capa de traducción que mantenga la integridad de los backups.

Causa

  1. Falta de soporte nativo – Veeam interactúa con los volúmenes a través de los controladores del sistema operativo. ZFS en Linux no expone una API de snapshots compatible con Veeam, por lo que el agente no puede crear los puntos de restauración requeridos.

  2. Límite de tamaño de archivo VBK – Cada archivo de backup (VBK) está limitado a 218 TiB. Cuando el pool supera ese umbral, Veeam intenta crear un único archivo que excede el límite y aborta el job.

  3. Fragmentación de snapshots – En ZFS, los snapshots pueden crecer rápidamente en entornos de alta escritura. Veeam necesita leer los snapshots de forma secuencial; la fragmentación provoca tiempos de respuesta elevados y, en algunos casos, time‑outs.

  4. Configuración de red y credenciales – Cuando se mezcla Linux y Windows, los permisos de acceso (SMB, NFS) pueden no estar alineados con los requisitos de Veeam, generando fallos de autenticación antes de que el job alcance la fase de copia.

  5. Diseño de replicación – Tener dos pools idénticos en RAIDZ2 no elimina la necesidad de un mecanismo de backup que sea consciente de la topología. Si la replicación se gestiona fuera de Veeam, el motor de backup no tiene visibilidad de los cambios y puede intentar respaldar datos ya replicados, duplicando el consumo de espacio.

Solución

1. Migrar a un file server nativo de Windows

Windows Server ofrece SMB 3.x con soporte de snapshots a través de Volume Shadow Copy Service (VSS). Veeam se integra directamente con VSS, creando VBK que respetan el límite de 218 TiB porque el motor divide automáticamente el backup en archivos de 2 TB (por defecto). La migración implica:

  • Crear volúmenes en Storage Spaces Direct (S2D) o en discos físicos configurados en RAID‑5/6 según la tolerancia deseada.
  • Habilitar SMB Multichannel y SMB Direct (RDMA) si la red lo permite, para maximizar el rendimiento.
  • Configurar DFS Namespaces para presentar una única jerarquía lógica que agrupe varios volúmenes físicos. DFS permite mover carpetas entre servidores sin cambiar la ruta UNC, facilitando la expansión futura.

2. Usar Azure Files con tiering automático

Azure Files soporta Premium (SSD) y Standard (HDD) con tiering basado en acceso. Con Azure File Sync se pueden mantener copias locales en servidores Windows y dejar que Azure gestione el almacenamiento frío. Veeam reconoce Azure Files como un recurso SMB y puede respaldar directamente los shares, respetando los límites de tamaño porque cada share se trata como un volumen independiente.

Pasos clave:

  • Crear una cuenta de almacenamiento y habilitar File Sync.
  • Instalar el agente de Azure File Sync en los servidores Windows que actuarán como sync endpoints.
  • Definir políticas de tiering (por ejemplo, “Only files not accessed in 30 días → Cool tier”).
  • Añadir los shares a Veeam como NAS backup y habilitar la opción de split VBK para evitar el límite de 218 TiB.

3. Introducir una capa de exportación de ZFS a SMB/NFS

Si la migración completa a Windows no es viable, se puede exponer los pools ZFS mediante Samba con la opción vfs objects = shadow_copy2. Esta configuración genera snapshots compatibles con VSS a nivel de cliente, aunque con limitaciones de rendimiento. En la práctica funciona para entornos donde solo una fracción del pool necesita respaldo frecuente.

Configuración mínima:

[backupshare]
   path = /pool1/data
   read only = no
   vfs objects = shadow_copy2
   shadow:snapdir = .zfs/snapshot
   shadow:basedir = /pool1/.zfs/snapshot
   shadow:localtime = yes

Una vez expuesto, Veeam trata el share como un recurso SMB y crea backups incrementales. Es crucial dividir el pool en varios shares de < 200 TiB para que Veeam no intente crear un VBK único demasiado grande.

4. Dividir el backup en varios jobs

Cuando la arquitectura no permite cambiar el file server, la alternativa práctica es crear jobs segmentados por carpeta o por rango de datos. Cada job tiene un size limit que fuerza a Veeam a generar varios archivos VBK, manteniéndolos por debajo del umbral. Esta solución incrementa la complejidad de la gestión (más jobs, más retenciones) pero evita la re‑arquitectura inmediata.

Cuándo aplicar esta solución

  • Migración a Windows: Ideal cuando la mayor parte de la carga de trabajo ya se ejecuta en Windows Server y se busca una integración sin fricción con Veeam. Señales: uso intensivo de SMB, necesidad de VSS, problemas recurrentes de snapshot en ZFS.

  • Azure Files: Conviene cuando se necesita escalabilidad ilimitada, tiering automático y la posibilidad de off‑load a la nube. Señales: crecimiento rápido del dataset, requerimientos de recuperación ante desastres fuera del sitio, presupuesto para consumo de Azure.

  • Exportación Samba: Apropiado cuando la infraestructura Linux es crítica y no se puede migrar inmediatamente. Señales: pools ZFS con datos “fríos” que rara vez cambian, limitaciones de presupuesto para hardware Windows.

  • Jobs segmentados: Útil como solución temporal o en entornos híbridos donde la re‑arquitectura completa es costosa. Señales: errores de “VBK exceeds limit”, falta de tiempo para migrar, necesidad de mantener la continuidad del backup.

Código

# Crear un Storage Pool en Windows Server (PowerShell)
New-StoragePool -FriendlyName "PoolBackup" -StorageSubsystemFriendlyName "Windows Storage*" -PhysicalDisks (Get-PhysicalDisk -CanPool $true)

# Crear un volumen resiliente 6+2 (RAID‑6) de 150 TB
New-VirtualDisk -StoragePoolFriendlyName "PoolBackup" -FriendlyName "VolBackup" -Size 150TB -ResiliencySettingName "Parity"

# Formatear y montar
Initialize-Disk -Number 3 -PartitionStyle GPT
New-Partition -DiskNumber 3 -UseMaximumSize -AssignDriveLetter
Format-Volume -DriveLetter F -FileSystem NTFS -NewFileSystemLabel "BackupData"

Verificación

  1. Comprobar visibilidad del share

    Test-Path \\servidor\backupshare

    Debe devolver True.

  2. Crear snapshot manual (VSS)

    vssadmin Create Shadow /For=F:

    Verificar que el snapshot aparece en la lista vssadmin List Shadows.

  3. Ejecutar job de prueba en Veeam

    • Seleccionar el share como origen.
    • Configurar “Split backup files” a 2 TB.
    • Iniciar job y observar que se genera al menos un archivo .vbk y un .vib.

  4. Validar integridad

    • En Veeam, usar la opción “SureBackup” para montar el backup y comprobar que los archivos son accesibles.

Notas adicionales

  • Cuando se usa Azure File Sync, la latencia de la primera copia puede ser alta; planificar una ventana de sincronización inicial de 24‑48 h para evitar saturación de red.
  • En entornos con alta concurrencia SMB, habilitar SMB Encryption solo si la red no está aislada; el cifrado añade sobrecarga de CPU que puede afectar al backup.
  • Si se opta por Samba + shadow_copy2, monitorizar la métrica zfs get used para evitar que el pool alcance el 80 % de capacidad; ZFS pierde rendimiento drásticamente después de ese punto.
  • Mantener al menos dos copias de seguridad fuera del sitio (por ejemplo, replicar los VBK a Azure Blob Storage) mejora la resiliencia frente a fallos catastróficos del data‑center.