Crear almacenamiento resiliente en un servidor independiente con Storage Spaces, y sustituir un disco averiado

Objetivo

Agrupar varios discos físicos de un único host Windows Server independiente en un disco virtual resiliente con Storage Spaces, y sustituir un disco físico averiado sin perder datos ni tener que reconstruir el pool desde cero.

Requisitos previos

Suficientes discos físicos de tamaño similar para la resiliencia elegida — en un servidor independiente, un espejo doble (two-way mirror) necesita al menos dos, un espejo triple (three-way mirror) al menos cinco, la paridad simple al menos tres y la paridad doble al menos siete; derechos de administrador local; el módulo Storage.

Pasos

1. Identificar los discos candidatos que aún no forman parte de un pool: Get-PhysicalDisk -CanPool $true | Select-Object FriendlyName, SerialNumber, Size, HealthStatus.
2. Crear el pool: New-StoragePool -FriendlyName "Pool1" -StorageSubSystemFriendlyName "*Storage*" -PhysicalDisks (Get-PhysicalDisk -CanPool $true).
3. Crear sobre él un disco virtual resiliente: New-VirtualDisk -StoragePoolFriendlyName "Pool1" -FriendlyName "Data1" -ResiliencySettingName Mirror -UseMaximumSize (usar en su lugar -ResiliencySettingName Parity para una resiliencia optimizada en capacidad, con menor rendimiento de escritura).
4. Inicializar, particionar y formatear el disco resultante exactamente como cualquier otro disco (Initialize-Disk, New-Partition -UseMaximumSize, Format-Volume).
5. Vigilar de forma continua el estado del pool y de los discos: Get-PhysicalDisk | Select-Object FriendlyName, HealthStatus, OperationalStatus y Get-StorageJob para ver cualquier operación de reparación o resincronización en curso y su porcentaje completado.
6. Cuando el HealthStatus de un disco físico indique Unhealthy o el OperationalStatus indique un fallo, identificarlo por número de serie (los modelos idénticos comparten FriendlyName) y sustituirlo en su alojamiento, después añadir el disco nuevo al pool (Add-PhysicalDisk -StoragePoolFriendlyName "Pool1" -PhysicalDisks (Get-PhysicalDisk -SerialNumber <new>) -Usage Automatic), retirar el averiado (Get-PhysicalDisk -SerialNumber <old> | Set-PhysicalDisk -Usage Retired), reparar los discos virtuales afectados (Get-StoragePool -FriendlyName "Pool1" | Get-VirtualDisk | Repair-VirtualDisk -AsJob), y, una vez que Get-StorageJob muestre la reparación terminada, quitar del pool el disco retirado (Remove-PhysicalDisk -StoragePoolFriendlyName "Pool1" -PhysicalDisks (Get-PhysicalDisk -SerialNumber <old>)).

Resultado esperado

Get-VirtualDisk muestra HealthStatus: Healthy y OperationalStatus: OK una vez que finaliza el trabajo de reparación (visible mediante Get-StorageJob); no se produce pérdida de datos en un disco virtual Mirror o Parity que haya perdido solo el número de discos que su resiliencia tolera.

Límites y base de verificación

New-StoragePool, New-VirtualDisk, Get-PhysicalDisk y Get-StorageJob son cmdlets documentados del módulo Storage; la secuencia de sustitución de discos (sustituir y añadir el disco nuevo, retirar el antiguo, reparar y luego quitar el antiguo del pool) está documentada en la guía de Microsoft sobre la sustitución de discos averiados y la reparación de JBOD para Storage Spaces. Reparar un disco virtual grande tras el fallo completo de una unidad de varios terabytes puede tardar muchas horas, durante las cuales el pool tiene una redundancia reducida — conviene evitar apilar una segunda retirada de disco planificada sobre una reparación en curso. No existe un deshacer de un único comando para un pool; hay que respaldar sus datos de forma independiente, ya que la resiliencia de Storage Spaces protege contra el fallo de disco, no contra la eliminación o la corrupción a nivel de archivo.