Problema

En entornos de servidor único se suele buscar una solución de redundancia “barata” que no requiera hardware RAID. Storage Spaces con un mirror de dos discos y formato ReFS parece cumplir ese objetivo: ofrece tolerancia a fallos y, según la documentación, auto‑reparación sin coste adicional.

Sin embargo, cuando el pool se llena más allá de la mitad de su capacidad útil, la capa de metadatos pierde espacio para registrar su propio estado. Un error lógico o un aumento de latencia en cualquiera de los discos lleva al pool a un estado degradado que, mientras el servidor sigue encendido, puede pasar desapercibido. Al reiniciar, Storage Spaces intenta volver a montar el virtual disk, pero al no disponer del margen necesario para reescribir la metadata de salud, el volumen se marca como Detached o aparece como partición RAW. En ese momento las herramientas de reparación habituales (por ejemplo Repair‑VirtualDisk) no logran recuperar el acceso y la única salida práctica es recrear el pool y restaurar desde backup.

El síntoma típico es la imposibilidad de montar el volumen después de un reboot, a pesar de que los discos físicos aparecen sanos en el Administrador de discos y en Get-PhysicalDisk. El problema no es exclusivo de ReFS; NTFS sufre el mismo bloqueo de metadata, aunque su herramienta chkdsk permite una recuperación parcial cuando el pool sigue accesible.

Causa

1. Falta de margen para metadata

Un mirror de dos discos necesita espacio libre para almacenar información de salud, bitmaps y registros de transacciones. Cuando el uso supera aproximadamente el 50 % del espacio total del pool, el motor de Storage Spaces no puede reservar bloques adicionales para estas estructuras. Cualquier degradación (errores de lectura, latencia alta, pérdida temporal de un disco) obliga al pool a actualizar su metadata; sin espacio disponible, la operación falla y el pool entra en modo “silencioso”.

2. Gestión de errores en un nodo único

En configuraciones de varios nodos (Storage Spaces Direct, S2D) el motor reparte la carga de metadata entre muchos discos, lo que reduce la presión sobre cada unidad. En un nodo único con solo dos discos, la tolerancia a fallos depende exclusivamente de la capacidad de cada disco para albergar tanto datos de usuario como metadatos. Un solo evento de latencia o un sector defectuoso desencadena la condición descrita.

3. Dependencia de ReFS para “auto‑healing”

ReFS implementa Integrity Streams, que corrige bitrot leyendo la copia del espejo cuando detecta corrupción a nivel de archivo. Esta capacidad no se extiende a la capa de Storage Spaces; si la metadata del pool se corrompe, ReFS simplemente bloquea el acceso al volumen para evitar lecturas inconsistentes. La percepción de que ReFS “soluciona todo” lleva a subestimar la necesidad de espacio libre y de backups.

4. Falta de monitoreo proactivo

Muchos administradores confían en la alerta de “degraded” que aparece solo cuando el pool ya ha perdido la capacidad de escribir metadata. Sin un monitoreo continuo del porcentaje de uso y de la salud de los discos (Get‑StoragePool –IsPrimordial $false | Select‑Object HealthStatus, Size, AllocatedSize), el problema se descubre tarde, normalmente después del reinicio.

Solución

A. Dimensionar el pool con margen del 50 %

Mantenga el uso del pool por debajo del 50 % de su capacidad total. En un mirror de 2 × 2 TB, limite la ocupación a 1 TB o menos. Esto garantiza bloques libres suficientes para la metadata y permite que el motor realice actualizaciones sin bloquearse.

B. Configurar alertas de capacidad y salud

Utilice PowerShell o un sistema de monitorización (por ejemplo, SCOM, Zabbix) para crear alertas que se disparen cuando AllocatedSize supere el 45 % del Size del pool o cuando cualquier PhysicalDisk reporte HealthStatus distinto de Healthy. Un ejemplo de script rápido:

Get-StoragePool -IsPrimordial $false |
  Where-Object { $_.AllocatedSize / $_.Size -gt 0.45 } |
  ForEach-Object {
    $msg = "Pool $($_.FriendlyName) supera el 45 % de uso."
    # Enviar correo o webhook
    Write-Host $msg
  }

C. Plan de recuperación con backup fuera del pool

No confíe en la auto‑reparación como sustituto de backup. Realice copias periódicas (VSS o robocopy) a un medio externo o a un storage independiente. En caso de que el pool quede Detached, la restauración será la única vía fiable.

D. Procedimiento de reparación paso a paso

  1. Diagnóstico inicial

    Get-StoragePool -IsPrimordial $false | Format-Table FriendlyName, HealthStatus, Size, AllocatedSize
Get-VirtualDisk | Format-Table FriendlyName, HealthStatus, ResiliencySettingName
Get-PhysicalDisk | Format-Table FriendlyName, HealthStatus, OperationalStatus

  2. Intentar reparar el virtual disk

    Repair-VirtualDisk -FriendlyName "MiMirror" -Verbose

  3. Si la reparación falla y el pool está Detached

    • Desconectar el pool: Set-StoragePool -FriendlyName "MiPool" -IsReadOnly $true
    • Exportar la configuración del pool (solo metadatos): Export-StoragePool -FriendlyName "MiPool" -Path "C:\Temp\PoolExport"
    • Eliminar el pool problemático: Remove-StoragePool -FriendlyName "MiPool"
    • Recrear el pool con los discos intactos, asegurándose de que el nuevo pool tenga al menos 50 % de espacio libre.
    • Importar la configuración exportada si es posible, o recrear los virtual disks manualmente.
    • Restaurar los datos desde backup.

E. Alternativas de hardware

Cuando el presupuesto lo permite, opte por una controladora RAID hardware con espejo (RAID 1) o por volúmenes dinámicos tradicionales. Estas soluciones gestionan la metadata en el propio controlador y no dependen del espacio libre del pool, reduciendo la probabilidad de bloqueos al reiniciar.

Cuándo aplicar esta solución

  • Síntomas: El pool muestra HealthStatus = Degraded o Detached después de un reinicio; los discos aparecen Healthy pero el volumen no se monta; Get-PhysicalDisk no muestra errores críticos.
  • Entorno: Servidor único con Storage Spaces espejo de 2 o 4 discos, uso superior al 50 % del pool, y sin infraestructura de S2D.
  • No aplica: Clusters de varios nodos con decenas de discos, o entornos donde el pool nunca supera el 30 % de uso. En esos casos, la presión sobre la metadata es mínima y la solución de hardware RAID puede ser innecesaria.

Código

# Ver estado del pool y discos
Get-StoragePool -IsPrimordial $false |
  Select-Object FriendlyName, HealthStatus, Size, AllocatedSize |
  Format-Table -AutoSize

Get-PhysicalDisk |
  Select-Object FriendlyName, HealthStatus, OperationalStatus |
  Format-Table -AutoSize

# Reparar virtual disk (si está accesible)
Repair-VirtualDisk -FriendlyName "MirrorVD" -Verbose

# Exportar configuración antes de eliminar pool (opcional)
Export-StoragePool -FriendlyName "MyPool" -Path "C:\Temp\PoolExport"

Verificación

  1. Después de la reparación: Get-VirtualDisk debe mostrar HealthStatus = Healthy y el volumen debe aparecer en el Administrador de discos con letra asignada.
  2. Reinicio de prueba: Reinicie el servidor y confirme que el pool se monta automáticamente sin pasar a Detached.
  3. Espacio libre: Verifique que AllocatedSize / Size sea ≤ 0.45. Si supera ese umbral, reduzca la carga o añada discos al pool.
  4. Backup: Realice una restauración de prueba desde la copia de seguridad para asegurarse de que el proceso de recuperación funciona.

Notas adicionales

  • La regla del 50 % no es una especificación oficial de Microsoft; es una práctica derivada de la observación de que la metadata de Storage Spaces crece rápidamente bajo carga.
  • En entornos con SSD, la latencia puede disparar falsos positivos de degradación; ajuste los umbrales de alerta según el tipo de medio.
  • Si necesita más capacidad sin sacrificar la regla del 50 %, añada discos al pool y convierta el mirror en un parity o dual‑parity (dependiendo de la tolerancia requerida).
  • Mantenga siempre una copia de la configuración del pool (Export-StoragePool) antes de realizar cambios estructurales; facilita la recuperación en caso de corrupción.