Proxmox ZFS Degradado: Reemplazar un disco sin daños colaterales

Qué significa realmente DEGRADED en Proxmox + ZFS

En ZFS, DEGRADED significa que el pool sigue siendo utilizable, pero al menos un vdev (dispositivo virtual) ha perdido redundancia
o tiene un componente que no está disponible o se comporta mal. La parte importante no es la palabra; son las implicaciones:

• Estás a una falla de perder datos si estás en espejos con un lado caído, o en RAIDZ sin tolerancia de paridad restante.
• El rendimiento suele empeorar porque ZFS puede estar reconstruyendo lecturas, reintentando I/O o evitando un dispositivo inestable.
• Los scrubs y resilvers se convierten en eventos de riesgo: estresan los discos restantes, que es exactamente lo que no quieres cuando están envejeciendo.

Proxmox aquí es mayormente un mensajero. Ejecuta ZFS como backend de almacenamiento (a menudo para rpool y a veces para pools de VM),
y muestra zpool status en la interfaz. La superficie de control real es la shell.

“Reemplazar un disco” suena a tarea de hardware. En ZFS, es una operación de migración de datos con dependencia de hardware. Trátala así.

Guion de diagnóstico rápido (comprueba primero/segundo/tercero)

Cuando un pool se degrada, tu trabajo es responder tres preguntas rápido: ¿Qué disco? ¿Está realmente fallando o solo falta?
¿Está el pool lo suficientemente estable como para resilverizar con seguridad?

Primero: confirma el estado del pool y el miembro del vdev exacto que está enfermo

No adivines por la UI de Proxmox. Obtén el estado autorizado de ZFS.

Segundo: determina si es un “disco muerto” o un “problema de path”

Un disco puede parecer fallido porque un reset del controlador, un cable SATA malo, una bahía de backplane defectuosa o un renumerado de dispositivos lo hicieron desaparecer.
La solución es diferente—y reemplazar hardware a ciegas puede empeorar las cosas.

Tercero: evalúa el riesgo antes de empezar a estresar el pool

Si tienes discos restantes que muestran sectores realocados, errores de lectura o timeouts, quizá quieras reducir I/O,
programar una ventana o tomar un snapshot/replicación de respaldo antes del resilver.

La manera más rápida de encontrar el cuello de botella: estado ZFS → logs del kernel → SMART. Si esos tres coinciden, actúa.
Si no coinciden, pausa y averigua por qué.

Hechos interesantes y contexto histórico (por qué ZFS actúa así)

• ZFS nació en Sun Microsystems a mediados de los 2000 con checksumming de extremo a extremo como característica principal, no como añadido.
• “Copy-on-write” es la razón por la que ZFS odia las verdades a medias: escribe bloques nuevos y luego actualiza punteros, lo que facilita detectar corrupción silenciosa.
• ZFS no “reconstruye”; hace “resilver”, lo que significa que solo reconstruye los bloques que realmente están en uso—no el dispositivo bruto entero.
• RAIDZ fue diseñado para arreglar el write hole de RAID-5/6 integrando la gestión de paridad con el modelo de transacciones del sistema de archivos.
• Los nombres de dispositivo como /dev/sda no son estables; el uso de nombres persistentes vía /dev/disk/by-id se volvió práctica recomendada porque la enumeración en Linux cambia.
• Los scrubs existen porque los checksums necesitan ejercitarse: ZFS puede detectar corrupción, pero un scrub fuerza la lectura y verificación de datos proactivamente.
• Los discos Advanced Format (sectores de 4K) crearon una era de problemas; ashift es la forma de ZFS de alinear asignaciones al tamaño físico del sector.
• SMART no es un veredicto, es un informe meteorológico: muchos discos mueren “sanos”, mientras otros cojean “fallando” durante meses.

Una idea de fiabilidad parafraseada que sigue siendo dolorosamente cierta viene de Gene Kranz (director de vuelo de la NASA): paraphrased idea: be tough and competent.
En términos de almacenamiento: no improvises y no toques dos cosas a la vez.

Antes de tocar el hardware: barandillas de seguridad que previenen daños colaterales

Usa identidades de disco estables (basadas en serie), no lo que Linux llamó hoy

Si trabajas con discos solo por /dev/sdX, estás jugando a la ruleta con una rueda cargada. Las actualizaciones de Proxmox,
actualizaciones del kernel, resets del controlador o simplemente reiniciar pueden reordenar la enumeración. ZFS también puede almacenar rutas en múltiples formas.
Quieres anclar tus decisiones a hechos inmutables: WWN, número de serie y ubicación de la bahía.

Decide tu radio de impacto

Si el pool aloja discos de VM (zvols), un resilver es un I/O intenso. Si puedes evacuar VM críticas,
hazlo. Si no puedes, aún procedes—pero lo haces intencionalmente: limita la carga, evita mantenimiento concurrente
y vigila la latencia como un halcón.

No “arregles” dos problemas a la vez

Reemplazar un disco ya es una emergencia controlada. No lo combines con una actualización del kernel, firmware del HBA,
cambios de feature flag de ZFS o una “limpieza rápida de cables.” Quieres causalidad. Quieres reversibilidad.

Broma #1: Los arreglos de almacenamiento no tienen estados de ánimo. Tienen consecuencias, y siempre recuerdan lo que hiciste.

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

Todo lo siguiente está escrito para un nodo Proxmox típico usando ZFS en Linux. Los comandos asumen privilegios de root o sudo.
Sustituye nombres de pool/dispositivo por los de tu realidad. Si tu pool es rpool, perfecto. Si es tank, úsalo.

Tarea 1: Confirma la salud del pool e identifica el miembro que falla

cr0x@server:~$ sudo zpool status -v
  pool: rpool
 state: DEGRADED
status: One or more devices has experienced an unrecoverable error.
action: Replace the device using 'zpool replace'.
  scan: scrub repaired 0B in 00:14:12 with 0 errors on Thu Dec 19 02:10:03 2025
config:

        NAME                                         STATE     READ WRITE CKSUM
        rpool                                        DEGRADED     0     0     0
          mirror-0                                   DEGRADED     0     0     0
            ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K123456   ONLINE       0     0     0
            ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K654321   FAULTED     12     0     0  too many errors

errors: No known data errors

Qué significa: Tienes un mirror con un lado faulted. Las lecturas se están sirviendo desde el disco restante.
El pool sigue en funcionamiento, pero la redundancia está perdida para ese vdev.
Decisión: Reemplaza ...654321. No separes el disco sano. No “cleanes” errores y esperes.

Tarea 2: Mapea los IDs de dispositivo de ZFS a discos físicos (WWN/serie)

cr0x@server:~$ ls -l /dev/disk/by-id | egrep 'S2Y3NX0K123456|S2Y3NX0K654321'
lrwxrwxrwx 1 root root  9 Dec 26 09:10 ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K123456 -> ../../sda
lrwxrwxrwx 1 root root  9 Dec 26 09:10 ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K654321 -> ../../sdb

Qué significa: Ahora mismo el disco sano es /dev/sda y el disco malo es /dev/sdb.
Ese mapeo puede cambiar tras un reinicio.
Decisión: Trabaja en términos de /dev/disk/by-id/ata-..., y usa /dev/sdb solo para comprobaciones SMART inmediatas.

Tarea 3: Revisa los logs del kernel por timeouts/resets (distinguir disco vs path)

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'sdb|ata|I/O error|timeout|reset' | tail -n 25
Dec 26 08:41:12 server kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Dec 26 08:41:12 server kernel: ata2.00: failed command: READ DMA EXT
Dec 26 08:41:12 server kernel: blk_update_request: I/O error, dev sdb, sector 118782976 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Dec 26 08:41:13 server kernel: ata2: hard resetting link
Dec 26 08:41:18 server kernel: ata2: link is slow to respond, please be patient (ready=0)
Dec 26 08:41:23 server kernel: ata2.00: configured for UDMA/133

Qué significa: Esto parece errores reales de I/O y resets de enlace. Podría ser el disco, podría ser el cable/backplane.
Decisión: Si es una bahía hot-swap, vuelve a asentar el disco una vez (con cuidado) antes de reemplazar. Si persiste, reemplaza el disco y considera cambiar luego la bahía/cable.

Tarea 4: Obtén un resumen rápido de SMART

cr0x@server:~$ sudo smartctl -H /dev/sdb
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.12-5-pve] (local build)
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!

Qué significa: La unidad admite que está muerta.
Decisión: Reemplaza la unidad. No más teatro de diagnóstico.

Tarea 5: Extrae los atributos SMART que importan (timeouts vs desgaste vs medio)

cr0x@server:~$ sudo smartctl -a /dev/sdb | egrep -i 'Serial Number|Reallocated|Pending|Offline_Uncorrectable|CRC|Power_On_Hours|Media_Wearout|Percentage_Used' 
Serial Number:                       S2Y3NX0K654321
Power_On_Hours:                      43120
Reallocated_Sector_Ct:               48
Current_Pending_Sector:              9
Offline_Uncorrectable:               9
UDMA_CRC_Error_Count:                0

Qué significa: Sectores pendientes e incorrigibles son un fallo clásico de medio. El conteo CRC es 0, así que es menos probable que sea un problema de cable.
Decisión: Reemplaza la unidad. Si los CRC fueran altos, sospecharías cableado/backplane y aun así reemplazarías—solo con mayor escrutinio.

Tarea 6: Verifica la topología del pool (mirror vs RAIDZ) antes de los comandos de reemplazo

cr0x@server:~$ sudo zpool get -H -o value ashift rpool
12

Qué significa: ashift=12 (sectores de 4K). Esto es lo que quieres en sistemas modernos.
Decisión: Asegura que el disco de reemplazo no sea más pequeño y sea adecuado para alineación 4K. No puedes cambiar ashift de un miembro de vdev existente in-place.

Tarea 7: Comprueba que el disco de reemplazo sea visible y no esté en uso

cr0x@server:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,TYPE,MOUNTPOINT
NAME    SIZE MODEL             SERIAL           TYPE MOUNTPOINT
sda   476.9G SAMSUNG MZ7LN512  S2Y3NX0K123456   disk 
├─sda1 1007K                    0               part 
├─sda2    1G                    0               part 
└─sda3 475.9G                    0               part 
sdb   476.9G SAMSUNG MZ7LN512  S2Y3NX0K654321   disk 
├─sdb1 1007K                    0               part 
├─sdb2    1G                    0               part 
└─sdb3 475.9G                    0               part 
sdc   476.9G SAMSUNG MZ7LN512  S2Y3NX0K777777   disk 

Qué significa: El disco nuevo es sdc y parece en blanco (no muestra particiones). Bien.
Decisión: Usa /dev/disk/by-id para sdc también. Confirma que el número de serie coincide con la etiqueta de la caja/bahía.

Tarea 8: Confirma el ID persistente del disco nuevo

cr0x@server:~$ ls -l /dev/disk/by-id | grep S2Y3NX0K777777
lrwxrwxrwx 1 root root  9 Dec 26 09:16 ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K777777 -> ../../sdc

Qué significa: Tienes un identificador estable para el disco de reemplazo.
Decisión: Procede con zpool replace usando rutas by-id.

Tarea 9: Reemplaza el miembro correctamente (deja que ZFS haga lo correcto)

cr0x@server:~$ sudo zpool replace rpool \
  /dev/disk/by-id/ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K654321 \
  /dev/disk/by-id/ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K777777

Qué significa: ZFS adjuntará el disco nuevo y comenzará a resilverizar sobre él.
Decisión: No reinicies. No retires el disco sano restante. Monitorea el progreso del resilver.

Tarea 10: Vigila el progreso del resilver y confirma que realmente progresa

cr0x@server:~$ watch -n 5 sudo zpool status rpool
  pool: rpool
 state: DEGRADED
status: One or more devices is being resilvered.
action: Wait for the resilver to complete.
  scan: resilver in progress since Fri Dec 26 09:18:41 2025
        112G scanned at 1.21G/s, 38.2G issued at 423M/s, 475G total
        38.2G resilvered, 8.04% done, 00:17:42 to go
config:

        NAME                                         STATE     READ WRITE CKSUM
        rpool                                        DEGRADED     0     0     0
          mirror-0                                   DEGRADED     0     0     0
            ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K123456   ONLINE       0     0     0
            ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K777777   ONLINE       0     0     0  (resilvering)

Qué significa: El resilver está activo, muestra throughput, ETA y escaneado vs emitido. Eso es una buena señal.
Decisión: Si “issued” se queda en 0 durante minutos mientras “scanned” aumenta lentamente, podrías estar limitado o bloqueado por errores. Revisa logs y SMART del disco sobreviviente.

Tarea 11: Revisa el impacto en carga/latencia del nodo (evita una caída accidental)

cr0x@server:~$ sudo iostat -x 2 5
Linux 6.8.12-5-pve (server) 	12/26/2025 	_x86_64_	(32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.12    0.00    3.44   24.66    0.00   63.78

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await wareq-sz  aqu-sz  %util
sda              98.0   91200.0     0.0   0.00    3.10   930.6     21.0    980.0    8.60    46.7     0.41  38.0
sdc              44.0   40120.0     0.0   0.00    4.90   912.7     62.0   15200.0    2.40   245.2     0.44  29.5

Qué significa: %iowait está elevado. Eso es normal durante un resilver. %util sin estar al máximo sugiere que aún tienes margen.
Decisión: Si iowait está afectando drásticamente la latencia de VM, limita la carga o programa una ventana tranquila. Evita iniciar backups o migraciones pesadas durante el resilver.

Tarea 12: Confirma que el pool vuelve a ONLINE y que el dispositivo antiguo desapareció

cr0x@server:~$ sudo zpool status -v rpool
  pool: rpool
 state: ONLINE
  scan: resilvered 475G in 00:22:19 with 0 errors on Fri Dec 26 09:41:00 2025
config:

        NAME                                         STATE     READ WRITE CKSUM
        rpool                                        ONLINE       0     0     0
          mirror-0                                   ONLINE       0     0     0
            ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K123456   ONLINE       0     0     0
            ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K777777   ONLINE       0     0     0

errors: No known data errors

Qué significa: Has recuperado la redundancia. Sin errores. Ese es el estado objetivo.
Decisión: Ahora haz limpieza y verificación: programación de scrub, alertas, etiquetado y notas de postmortem.

Tarea 13: Si el disco está “UNAVAIL” y no “FAULTED”, verifica si solo falta

cr0x@server:~$ sudo zpool status rpool
  pool: rpool
 state: DEGRADED
config:

        NAME                                         STATE     READ WRITE CKSUM
        rpool                                        DEGRADED     0     0     0
          mirror-0                                   DEGRADED     0     0     0
            ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K123456   ONLINE       0     0     0
            ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K654321   UNAVAIL      0     0     0  cannot open

Qué significa: ZFS no puede abrir el dispositivo; eso puede ser un disco muerto o un problema de path.
Decisión: Comprueba si el dispositivo existe en /dev/disk/by-id. Si desapareció, busca problemas de controlador/backplane antes de declararlo “fallado.”

Tarea 14: Valida si la ruta del dispositivo faltante existe (o no)

cr0x@server:~$ test -e /dev/disk/by-id/ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K654321; echo $?
1

Qué significa: El código de salida 1 significa que la ruta no existe. El OS no la ve.
Decisión: Revisa el asiento físico, la bahía del backplane y los logs del HBA. Si vuelve, podrías usar zpool online en lugar de reemplazar.

Tarea 15: Si un disco volvió, intenta ponerlo en línea (solo si confías en él)

cr0x@server:~$ sudo zpool online rpool /dev/disk/by-id/ata-SAMSUNG_MZ7LN512HMJP_S2Y3NX0K654321

Qué significa: ZFS intentará volver a activar el dispositivo. Si fue algo transitorio, el pool podría volver a ONLINE sin reemplazo.
Decisión: Si SMART sigue mostrando problemas o los logs indican resets repetidos, no te pongas sentimental. Reemplázalo de todos modos.

Tarea 16: Limpia los contadores de error solo después de arreglar el problema subyacente

cr0x@server:~$ sudo zpool clear rpool

Qué significa: Esto limpia contadores de error y algunos estados de fallo.
Decisión: Úsalo para confirmar que la solución se mantuvo (los errores permanecen en 0). No lo uses para “poner en verde” un pool sin reemplazo.

Broma #2: Si “limpias” los errores del pool sin arreglar nada, felicitaciones—has silenciado la alarma de humo mientras la tostada sigue en llamas.

Flujos de trabajo de reemplazo: mirror vs RAIDZ, hot-swap vs cold-swap

vdev de espejo: el caso directo (aún fácil de estropear)

Los espejos son operativamente amigables. Reemplaza un disco, resilveriza, y listo. El modo de falla es humano:
alguien extrae el disco equivocado, o reemplaza con uno un poco más pequeño, o usa nombres de dispositivo inestables,
o desprende el miembro equivocado.

Enfoque recomendado:

• Identifica el disco fallido por serie y bahía, no por sdb.
• Usa zpool replace con rutas /dev/disk/by-id.
• Monitorea el resilver y el I/O del sistema. El resilver no es un susurro en segundo plano; es una carretilla elevadora.
• Verifica que zpool status vuelva a ONLINE, luego programa un scrub en una ventana de mantenimiento si puedes tolerar la carga.

RAIDZ vdevs: el reemplazo sigue siendo simple; las consecuencias no lo son

Con RAIDZ, el pool puede quedarse online con uno o más discos faltantes dependiendo del nivel de paridad (RAIDZ1/2/3).
Pero durante la degradación, cada lectura de datos que tocó el disco faltante puede requerir reconstrucción, lo que estresa a los discos restantes.
Luego el resilver añade más I/O. Así es como “un disco fallado” se convierte en “por qué tres discos hacen timeout.”

El método es el mismo: zpool replace al miembro. La postura operativa cambia:

• No ejecutes un scrub y un resilver concurrentemente a menos que disfrutes noches largas.
• Considera reducir la carga de trabajo durante el resilver.
• Si otro disco está lanzando errores, pausa y decide si debes respaldar/replicar antes de continuar.

Bahías hot-swap: confía pero verifica

Hot swap no es “enchufar y rezar.” Es “hot swap si tu backplane, HBA y OS están de acuerdo en la realidad.”
En Proxmox, típicamente puedes reemplazar un disco fallido en caliente, pero debes:

• Confirmar el LED de la bahía correcto (si está disponible) o usar un proceso de mapeo (serie ↔ bahía).
• Insertar el disco nuevo y asegurarte de que aparezca bajo /dev/disk/by-id.
• Luego ejecutar zpool replace. No antes.

Cold swap (apagado): a veces lo aburrido es correcto

Si estás en hardware cuestionable (controladores SATA de consumo, backplanes inestables, BIOS antiguo o historial de resets de enlace),
un cold swap puede reducir riesgo. También es más limpio operativamente si el pool ya está inestable.
Aun así haces las mismas verificaciones de identidad después del arranque, porque la enumeración puede cambiar.

Listas de verificación / plan paso a paso (listo para producción)

Lista A: Plan de respuesta “Vi DEGRADED”

1. Captura el estado actual: zpool status -v y guarda la salida en tu ticket/notas.
2. Revisa si los errores suben: ejecuta zpool status otra vez en 2–5 minutos. ¿Aumentan READ/WRITE/CKSUM?
3. Revisa logs del kernel por resets/timeouts: journalctl -k -b.
4. Chequeo SMART en el disco sospechoso y en los miembros sobrevivientes del mismo vdev.
5. Decide si puedes proceder en caliente o necesitas una ventana de mantenimiento.

Lista B: Pasos seguros de reemplazo (miembro de mirror o RAIDZ)

1. Identifica el miembro que falla por zpool status (prefiere by-id).
2. Mapéalo a serie y etiqueta de bahía usando ls -l /dev/disk/by-id y tu inventario del chasis.
3. Inserta el disco de reemplazo. Confirma que aparece en /dev/disk/by-id.
4. Confirma que el disco de reemplazo no es más pequeño que el viejo: lsblk.
5. Ejecuta zpool replace <pool> <old> <new>.
6. Monitorea el resilver: zpool status hasta que termine. Vigila la latencia del sistema.
7. Cuando esté ONLINE, registra la duración del resilver y cualquier error observado.
8. Opcionalmente ejecuta un scrub en la próxima ventana tranquila (no inmediatamente si el sistema está bajo alta carga).

Lista C: Validación post-reemplazo

1. zpool status -v muestra ONLINE y 0 errores de datos conocidos.
2. SMART del disco nuevo muestra una línea base limpia (guarda el informe SMART).
3. Confirma que las alertas están claras en Proxmox y en tu sistema de monitorización.
4. Actualiza inventario: mapeo bahía → serie, seguimiento de garantía y fecha del reemplazo.

Lista D: Si el resilver está lento o atascado

1. Revisa si otro disco ahora está mostrando errores (SMART + logs del kernel).
2. Revisa saturación: iostat -x y carga de VM.
3. Considera pausar trabajos no críticos (backups, replicación, movimientos masivos de almacenamiento).
4. Si los errores suben, deja de hacer cambios y planea una parada controlada con backups listos.

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

1) El pool sigue DEGRADED después del reemplazo

Síntoma: Reemplazaste un disco, pero zpool status sigue mostrando DEGRADED y el nombre del dispositivo antiguo persiste.

Causa raíz: Usaste el identificador equivocado (por ejemplo, reemplazaste /dev/sdb pero ZFS rastreaba by-id), o adjuntaste sin reemplazar.

Solución: Usa zpool status para encontrar la cadena exacta del dispositivo, luego ejecuta zpool replace pool <that-exact-old> <new-by-id>. Evita usar /dev/sdX.

2) El disco de reemplazo es “demasiado pequeño” aunque es el mismo modelo

Síntoma: zpool replace falla con “device is too small.”

Causa raíz: Los fabricantes varían silenciosamente la capacidad usable entre revisiones de firmware, o el disco viejo reportaba un tamaño ligeramente mayor.

Solución: Usa un disco de igual o mayor capacidad. Para pools de arranque mirror, compra la siguiente capacidad y evita jugar a adivinar por número de modelo.

3) El resilver va lento y el nodo es inutilizable

Síntoma: La latencia de VM se dispara, iowait alto, usuarios se quejan y la ETA del resilver sigue creciendo.

Causa raíz: Contención de carga (escrituras de VM + lecturas/escrituras del resilver), más posiblemente un disco sobreviviente marginal.

Solución: Reduce la carga (pausa trabajos pesados, migra VM no críticas), revisa SMART de los discos sobrevivientes y considera una ventana de mantenimiento. Si el disco sobreviviente está fallando, la verdadera emergencia es “el segundo disco está muriendo”.

4) Sacaste el disco equivocado y ahora el pool está OFFLINE

Síntoma: El pool cae, las VM se pausan/crashean y zpool status muestra dispositivos faltantes.

Causa raíz: Fallo humano en identificación: el mapeo de bahías no fue confirmado, inestabilidad en nombres de dispositivo o falta de procedimiento de localización LED.

Solución: Vuelve a insertar el disco correcto inmediatamente. Si retiraste un miembro espejo sano, colócalo de nuevo primero. Luego reevalúa. Por eso etiquetar las bahías y registrar series es vital.

5) Reemplazaste el disco del pool de arranque, pero el nodo no arranca

Síntoma: Tras reemplazar un disco en rpool, el sistema no arranca desde el disco nuevo si el viejo se retira.

Causa raíz: El bootloader/entrada EFI no fue instalado o reflejado al nuevo dispositivo. La redundancia de datos de ZFS no refleja automáticamente el estado del bootloader.

Solución: Asegura que la herramienta de arranque de Proxmox/configuración EFI esté replicada en los discos de arranque. Valida ajustando temporalmente el orden de arranque en BIOS o realizando una prueba de arranque controlada.

6) Errores CKSUM con SMART “sano”

Síntoma: zpool status muestra errores de checksum en un dispositivo, pero SMART parece bien.

Causa raíz: Frecuentemente es cableado, backplane, problemas del HBA o alimentación provocando corrupción de datos en tránsito.

Solución: Reasienta/reemplaza cables, mueve el disco a otra bahía/puerto del controlador, revisa la estabilidad del firmware del HBA. Limpia errores después de arreglar y observa si regresan.

Tres micro-historias corporativas de la vida real

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

Una empresa mediana ejecutaba Proxmox en dos nodos, cada uno con un pool de arranque ZFS en espejo y un RAIDZ separado para almacenamiento de VM.
Una mañana, un nodo marcó DEGRADED. El ingeniero on-call vio /dev/sdb en un vistazo rápido a zpool status,
asumió que se correspondía con “Bahía 2” y pidió a facilities que extrajeran esa unidad.

Facilities hizo exactamente lo solicitado, excepto que las bahías no estaban etiquetadas y el chasis había sido recableado durante una “limpieza”.
La unidad retirada fue el miembro espejo sano, no el fallado. El pool no murió instantáneamente porque ZFS es cortés—hasta que deja de serlo.
El nodo sufrió una caída de rendimiento y luego un segundo disco arrojó errores bajo la carga extra de lectura.

La recuperación fue fea pero educativa: volver a insertar el disco retirado, dejar que el pool se estabilizara y luego rehacer la identificación correctamente usando
/dev/disk/by-id y contrastando con las etiquetas físicas que crearon durante el incidente.
La solución a largo plazo no fue sofisticada: documentaron el mapeo bahía-a-serie y dejaron de hablar en términos de sdX.

La suposición equivocada no fue “la gente comete errores.” Fue “los nombres de dispositivo son estables.” No lo son. Ni en un buen día.

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

Otra organización quería resilvers y scrubs más rápidos. Alguien leyó que “más paralelismo es mejor” y afinó ZFS agresivamente:
mayores tasas de scan, más operaciones concurrentes, la jugada de “hacer que los gráficos suban.”
En laboratorio todo bien. En producción colisionó con cargas reales: bases de datos, backups y tráfico de replicación.

Durante un evento degradado, el resilver arrancó a throughput impresionante, luego el nodo empezó a tirar timeouts en I/O de invitados.
El cluster de VM no colapsó; se volvió lentamente como melaza. Los operadores intentaron arreglar reiniciando servicios y migrando VMs,
lo que añadió más I/O. El resilver se volvió aún más lento. Más reintentos. Más dolor.

Se estabilizaron retrocediendo la “optimización” y dejando que el resilver corriera a un ritmo sostenible,
priorizando la latencia de servicio sobre números de benchmark. Después del incidente, mantuvieron valores conservadores y crearon un runbook:
durante resilver, pausar trabajos no esenciales y tratar la latencia de almacenamiento como un SLO primario.

Lección: la velocidad de resilver no es una métrica de vanidad. El único número que importa es “terminó sin una segunda falla mientras los usuarios seguían trabajando.”

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

Una empresa regulada ejecutaba nodos Proxmox con espejos ZFS y una estricta costumbre: cada bahía tenía una etiqueta,
cada etiqueta correspondía a un número de serie registrado y cada reemplazo se hacía por by-id con capturas de pantalla de zpool status
pegadas en el ticket.

Cuando un pool se degradó durante una semana de vacaciones, el ingeniero on-call era un generalista, no un especialista en almacenamiento.
Siguió el runbook: comprobar estado ZFS, mapear serie, validar SMART, confirmar serie del reemplazo,
y solo entonces reemplazar. Sin astucias. Sin atajos.

El resilver terminó limpio. Un scrub posterior no mostró errores. La revisión post-incidente fue breve porque no hubo mucho que revisar.
Su “práctica aburrida” evitó el desastre más común: quitar el disco equivocado o reemplazar el miembro de vdev incorrecto.

Aburrido es subestimado. Aburrido es como duermes tranquilo.

FAQ

1) ¿Debo usar la GUI de Proxmox para reemplazar un disco o la CLI?

Usa la CLI para las operaciones reales de ZFS. La GUI está bien para visibilidad, pero zpool status es la fuente de verdad,
y quieres comandos y salidas copiables para tus notas del incidente.

2) ¿Puedo reiniciar durante un resilver?

Evítalo. ZFS suele poder reanudar el resilver, pero reiniciar introduce riesgo: renumerado de dispositivos, peculiaridades del HBA y la posibilidad de que un disco marginal no vuelva.
Si debes reiniciar por estabilidad, hazlo intencionalmente y documenta el estado antes y después.

3) ¿Cuál es la diferencia entre zpool replace y zpool attach?

replace sustituye un dispositivo por otro y dispara resilver. attach agrega un nuevo dispositivo a un mirror (convirtiendo un vdev de un solo disco en un mirror, o ampliando el ancho de un mirror).
Para un miembro mirror fallado, casi siempre quieres replace.

4) ¿Debería ejecutar un scrub inmediatamente después del reemplazo?

No inmediatamente, a menos que estés en una ventana tranquila y puedas tolerar la carga. Un resilver ya lee mucho.
Programa un scrub después de que el sistema se enfríe, especialmente en pools RAIDZ.

5) El disco aparece como UNAVAIL. ¿Está muerto?

No necesariamente. UNAVAIL puede significar que el OS no lo ve (path/cable/controlador) o que el disco está muerto.
Revisa /dev/disk/by-id, logs del kernel y SMART si el dispositivo reaparece.

6) ¿Puedo reemplazar un disco por uno más grande y obtener más espacio?

Puedes reemplazar por discos mayores, pero solo ganas espacio usable después de que todos los miembros de un vdev se actualicen y ZFS pueda expandir.
Los espejos aumentan después de que ambos lados sean más grandes; RAIDZ lo hace cuando todos los discos del vdev son más grandes.

7) ¿Por qué ZFS muestra errores pero las aplicaciones parecían bien?

Porque ZFS puede corregir muchos errores de forma transparente usando redundancia y checksums. Eso no es “bien”, es “lo detectó en el acto.”
Trata los errores corregidos como advertencia: algo se está degradando.

8) ¿Qué pasa si el disco sobreviviente en un mirror empieza a mostrar errores SMART durante el resilver?

Ese es el momento incómodo: podrías estar en un escenario de falla doble a punto de ocurrir.
Si es posible, reduce la carga, prioriza respaldar/replicar datos críticos y considera si deberías parar y hacer un plan de recuperación controlada.
Continuar podría funcionar—pero estás jugando con tu última copia buena dentro de ese vdev.

9) ¿ZFS refleja automáticamente el bootloader de Proxmox en rpool?

No de forma fiable por sí solo. ZFS refleja bloques de datos; la capacidad de arranque depende de la instalación del EFI/bootloader y de las entradas firmware.
Tras reemplazar discos de arranque, valida que cada disco sea arrancable de forma independiente si tu diseño lo requiere.

10) ¿Es seguro “offline” un disco antes de extraerlo?

Sí, cuando vas a retirar deliberadamente un miembro (especialmente en hot-swap). Ponerlo offline reduce sorpresas al decirle a ZFS que el dispositivo se va a ir.
Pero nunca pongas offline al último miembro bueno de un vdev. Confirma la topología primero.

Conclusión: próximos pasos después de volver a ONLINE

Pasar de DEGRADED a ONLINE es la victoria táctica. La victoria estratégica es asegurarte de que la próxima falla de disco
sea aburrida, rápida y no requiera héroes.

1. Registra el incidente: pega zpool status -v antes/después, salida SMART y qué serie fue reemplazada.
2. Corrige la deuda de identificación: etiqueta bahías, mantiene un mapa serie-a-slot y estandariza en /dev/disk/by-id.
3. Verifica la monitorización: alertas para estado de pool ZFS, atributos SMART críticos y resets de enlace en el kernel.
4. Programa scrubs intencionalmente: lo suficientemente frecuentes para detectar degradación, no tan agresivos que siempre estés estresando discos.
5. Practica el runbook: el mejor momento para aprender zpool replace no es la primera vez que tu pool se degrada.

ZFS te da una oportunidad de pelea. No la desperdicies con conjeturas. Reemplaza el disco correcto, de la manera correcta, y mantén los daños colaterales donde pertenecen: en ningún lugar.