La página está en rojo. La latencia sube. Alguien dice “just run a scrub” como si fuera una toallita milagrosa.
Otra persona responde “it’s already resilvering.” Ahora hay dos adultos discutiendo sobre verbos mientras tu
almacenamiento intenta no comerse a sí mismo.
scrub y resilver no son sinónimos. No tienen el mismo objetivo, no se activan por lo mismo,
y —críticamente— no tienen el mismo perfil de riesgo cuando ya vas cojeando con un vdev degradado.
Confundirlos es la forma de convertir una falla de disco recuperable en una reunión de “restauraremos desde backups”.
El modelo mental: verificación vs reconstrucción
Piensa en un pool ZFS como dos tareas que ocurren a lo largo del tiempo:
probar que los datos son correctos y restaurar la redundancia.
Scrub es la primera. Resilver es la segunda.
Un scrub es una auditoría completa de integridad. ZFS recorre bloques asignados, los lee, verifica checksums,
y si existe redundancia (mirror, RAIDZ), repara copias malas reescribiendo los datos buenos sobre los malos.
Scrub busca la corrección en todo lo que has guardado.
Un resilver es una reconstrucción dirigida a un dispositivo que necesita volver a ser miembro correcto de un vdev:
después de reemplazar un disco, tras un evento offline/online, una desconexión transitoria, o después de quitar y reintroducir un dispositivo.
Resilver trata de restaurar la redundancia para ese único dispositivo (o su porción), no de auditar el universo.
Aquí está la frase que previene incidentes: Scrub prueba tus datos; resilver reconstruye tu redundancia.
Ambos pueden descubrir errores. Ambos pueden reparar. Pero parten de intenciones distintas y cubren alcances diferentes.
Definiciones precisas (y qué no son)
Scrub: una auditoría impulsada por checksum de los datos asignados
Scrub lee bloques asignados en el pool. No el espacio libre. No “el disco crudo”. Datos y metadatos vivos.
Se verifica el checksum de cada bloque. Si un bloque está corrupto, ZFS intenta obtener una copia correcta desde la redundancia y repararlo.
Si ZFS no encuentra una copia buena, obtienes un error permanente: el checksum no coincidió y no había fuente buena.
Lo que scrub no es:
- No es un escaneo de superficie del disco (eso queda más para diagnósticos del proveedor o tests SMART largos).
- No es una “limpieza de rendimiento”. Si scrub te hizo más rápido, estabas roto.
- No reemplaza a las copias de seguridad. Puede detectar corrupción; no puede conjurar datos perdidos.
Resilver: devolver a un dispositivo a la membresía correcta
Resilver copia (o reconstruye) los datos necesarios para que un dispositivo vuelva a integrarse en un vdev con el contenido correcto.
En un mirror, eso significa copiar bloques desde el lado sano al disco nuevo/reintroducido.
En RAIDZ, significa reconstruir desde la paridad para poblar el disco nuevo/reintroducido.
Las implementaciones modernas de ZFS hacen resilver secuencial y rastrean bitácoras de tiempo sucio / puntos de control de resilver,
por lo que resilver tiende a centrarse en los datos realmente asignados en lugar de “todo el disco”. Eso es bueno.
También es por lo que la gente a veces subestima la carga del resilver: es menos que una reconstrucción de disco completo, pero sigue siendo una carga pesada,
sensible a la latencia, de lectura+escritura.
Lo que resilver no es:
- No es una comprobación proactiva de integridad. Puede descubrir errores, pero eso es colateral, no el objetivo.
- No es opcional cuando la redundancia está comprometida. Si estás degraded, estás apostando con cada lectura.
- No es “simplemente copiar archivos”. Copia bloques, incluyendo metadatos, a menudo con patrones de acceso algo aleatorios.
Una cita que la gente de operaciones aprende por las malas:
La esperanza no es una estrategia.
— idea parafraseada común en círculos SRE (asociada frecuentemente a la frase de Gordon R. Sullivan)
Qué desencadena un scrub, qué desencadena un resilver
Si no puedes responder “¿por qué está escaneando ahora?” no controlas tu sistema. ZFS hará lo que le pidas,
y también hará lo que deba.
Desencadenantes de scrub
- Tú lo inicias:
zpool scrub pool. - Tu programador lo inicia: cron, timer de systemd, o una UI de NAS.
- Algunos appliances lo lanzan automáticamente tras actualizaciones o ciertos eventos de mantenimiento.
Scrub es una decisión de política. Es higiene programada. Elige la frecuencia según riesgo, carga de trabajo y qué tan rápido quieres detectar errores latentes.
Desencadenantes de resilver
- Reemplazo de disco:
zpool replace. - Retorno de dispositivo: un fallo transitorio de cable o HBA y el disco vuelve.
- Online después de offline:
zpool offlineluegozpool onlineo un reinicio. - Attach en mirrors:
zpool attachpara convertir un disco solo en un mirror.
Resilver es un evento de disponibilidad. Algo cambió en el conjunto de dispositivos que forman la redundancia, y ZFS está reparando ese contrato de redundancia.
Broma #1: Un scrub es como hacer inventario; un resilver es como reabastecer después de que alguien robó un pallet. Confundirlos es cómo pides clips mientras hay un incendio.
Qué se lee, qué se escribe y por qué desaparecen tus IOPS
Perfil de I/O de scrub
Scrub lee cada bloque asignado y lo verifica. Eso significa:
- Predominan las lecturas, a menudo en streaming pero no perfectamente secuenciales (las búsquedas de metadatos saltan).
- Las escrituras ocurren solo cuando se necesita reparar (o al reescribir metadatos debido a la detección/mecánica de reparación).
- En el peor caso, lecturas aleatorias aparecen en pools fragmentados o datasets ocupados con muchos bloques pequeños.
En pools sanos, scrub es “principalmente lectura”. En pools no saludables, scrub puede convertirse en “leer todo y luego escribir reparaciones”, que es cuando las quejas por latencia se hacen fuertes.
Perfil de I/O de resilver
Resilver es lectura + escritura por definición: debe poblar un dispositivo con datos correctos. Dependiendo de la topología:
- Resilver en mirror: leer desde discos sanos, escribir en el disco nuevo/retornado.
- Resilver en RAIDZ: leer desde todos los discos restantes (para reconstruir), escribir en el disco objetivo.
- Vdevs especiales (metadatos/bloques pequeños) pueden hacer que el resilver sea sorprendentemente “punteado”.
Resilver compite con tu carga de producción por IOPS y ancho de banda. Si el pool está degraded, resilver también compite porque “cada lectura normal ahora tiene menos redundancia”, lo que incrementa el costo de manejar errores.
Implicación operativa
Scrub es dolor planificado; resilver es dolor no planificado. Planea lo primero para que lo segundo no se convierta en catástrofe.
Si estás resilvering, trata el tuning de rendimiento como secundario frente a la seguridad de los datos. Tu trabajo es terminar el resilver sin perder otro disco.
Cómo leer zpool status como si lo entendieras
zpool status es donde vive la realidad. Te dice si estás scrubing o resilvering, cuánto ha avanzado,
y si se están encontrando o reparando errores.
Campos clave que importan en incidentes
- state: ONLINE / DEGRADED / FAULTED / UNAVAIL. Esto marca tu urgencia.
- scan: scrub in progress, resilver in progress, scrub repaired X, resilvered X, y una tasa/ETA.
- errors: “No known data errors” no es una victoria absoluta, pero es una buena señal.
- READ/WRITE/CKSUM columnas por dispositivo: te dicen si el dispositivo miente, falla o está siendo expulsado.
Si te llevas nada más: la línea “scan” dice qué proceso está corriendo. Deja de adivinar.
Tareas prácticas: comandos, salidas, decisiones (12+)
Estas son las cosas que realmente haces a las 02:13 cuando alguien pregunta “¿es seguro?”. Cada tarea incluye:
el comando, qué significa la salida y qué decisión debe impulsar.
Task 1: Confirmar si es un scrub o un resilver
cr0x@server:~$ sudo zpool status -v tank
pool: tank
state: DEGRADED
status: One or more devices is currently being resilvered.
action: Wait for the resilver to complete.
scan: resilver in progress since Thu Dec 26 00:41:11 2025
1.23T scanned at 612M/s, 742G issued at 369M/s, 5.41T total
742G resilvered, 13.40% done, 03:46:12 to go
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz2-0 DEGRADED 0 0 0
sda ONLINE 0 0 0
sdb ONLINE 0 0 0
sdc ONLINE 0 0 0
sdd ONLINE 0 0 0
sde ONLINE 0 0 0
sdf ONLINE 0 0 0
sdg ONLINE 0 0 0
sdh ONLINE 0 0 0
sdi ONLINE 0 0 0
sdj ONLINE 0 0 0
sdk ONLINE 0 0 0
sdl ONLINE 0 0 0
sdm ONLINE 0 0 0
sdn ONLINE 0 0 0
sdo ONLINE 0 0 0
sdp ONLINE 0 0 0
sdq ONLINE 0 0 0
sdr ONLINE 0 0 0
sds ONLINE 0 0 0
sdt ONLINE 0 0 0
sdu ONLINE 0 0 0
sdv ONLINE 0 0 0
sdw ONLINE 0 0 0
sdx ONLINE 0 0 0
sdy ONLINE 0 0 0
sdz ONLINE 0 0 0
sdaa ONLINE 0 0 0
sdab ONLINE 0 0 0
sdac ONLINE 0 0 0
sdad ONLINE 0 0 0
sdae ONLINE 0 0 0
sdaf ONLINE 0 0 0
sdag ONLINE 0 0 0
sdah ONLINE 0 0 0
sdai ONLINE 0 0 0
sdaj ONLINE 0 0 0
sdak ONLINE 0 0 0
sdal ONLINE 0 0 0
sdam ONLINE 0 0 0
sdan ONLINE 0 0 0
sdao ONLINE 0 0 0
sdap ONLINE 0 0 0
sdaq ONLINE 0 0 0
sdar ONLINE 0 0 0
sdas ONLINE 0 0 0
sdat ONLINE 0 0 0
sdau ONLINE 0 0 0
sdav ONLINE 0 0 0
sdaw ONLINE 0 0 0
sdax ONLINE 0 0 0
sday ONLINE 0 0 0
sdaz ONLINE 0 0 0
sdba ONLINE 0 0 0
sdbb ONLINE 0 0 0
sdbc ONLINE 0 0 0
sdbd ONLINE 0 0 0
sdbe ONLINE 0 0 0
sdbf ONLINE 0 0 0
sdbg ONLINE 0 0 0
sdbh ONLINE 0 0 0
sdbi ONLINE 0 0 0
sdbj ONLINE 0 0 0
sdbk ONLINE 0 0 0
sdbl ONLINE 0 0 0
sdbm ONLINE 0 0 0
sdbn ONLINE 0 0 0
sdbo ONLINE 0 0 0
sdbp ONLINE 0 0 0
sdbq ONLINE 0 0 0
sdbr ONLINE 0 0 0
sdbs ONLINE 0 0 0
sdbt ONLINE 0 0 0
sdbu ONLINE 0 0 0
sdbv ONLINE 0 0 0
sdbw ONLINE 0 0 0
sdbx ONLINE 0 0 0
sdby ONLINE 0 0 0
sdbz ONLINE 0 0 0
errors: No known data errors
Significado: Es un resilver, no un scrub (“scan: resilver in progress”). El pool está DEGRADED pero no fallando.
Decisión: No inicies un scrub “para ayudar”. Deja que el resilver termine a menos que tengas evidencia de corrupción silenciosa que debas auditar inmediatamente (raro durante un resilver activo).
Task 2: Iniciar un scrub a propósito (y solo a propósito)
cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
scan: scrub in progress since Thu Dec 26 01:12:03 2025
388G scanned at 1.05G/s, 122G issued at 331M/s, 5.41T total
0B repaired, 2.20% done, 04:41:09 to go
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sda ONLINE 0 0 0
sdb ONLINE 0 0 0
errors: No known data errors
Significado: Scrub está en ejecución; “0B repaired” es bueno hasta ahora. La tasa “issued” muestra el I/O real enviado, a veces menor que “scanned.”
Decisión: Déjalo correr si la carga puede tolerarlo. Si la producción sufre, limita vía tunables (dependiente de la plataforma) o ejecútalo fuera de horas la próxima vez.
Task 3: Parar un scrub (porque te importa la latencia)
cr0x@server:~$ sudo zpool scrub -s tank
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
scan: scrub canceled on Thu Dec 26 01:24:55 2025
512G scanned at 1.02G/s, 0B repaired, 9.24% done
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sda ONLINE 0 0 0
sdb ONLINE 0 0 0
errors: No known data errors
Significado: Scrub detenido. No “rompiste” el pool; solo cancelaste la auditoría.
Decisión: Reprograma el scrub para una ventana donde no compita con el pico de I/O. No pases seis meses sin uno porque cancelar se sintió bien.
Task 4: Identificar qué dispositivo está siendo resilvered (y por qué)
cr0x@server:~$ sudo zpool status -P tank
pool: tank
state: DEGRADED
status: One or more devices is currently being resilvered.
scan: resilver in progress since Thu Dec 26 00:41:11 2025
742G resilvered, 13.40% done, 03:46:12 to go
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
/dev/disk/by-id/ata-WDC_WD80EFAX_A1A... ONLINE 0 0 0
/dev/disk/by-id/ata-WDC_WD80EFAX_B2B... ONLINE 0 0 0 (resilvering)
Significado: La etiqueta “(resilvering)” te indica el objetivo. -P muestra rutas persistentes, no nombres frágiles /dev/sdX.
Decisión: Verifica que el disco físico coincida con la ruta by-id antes de sacar nada del chasis. Esto evita desastres de “disco equivocado reemplazado”.
Task 5: Reemplazar un disco fallado correctamente
cr0x@server:~$ sudo zpool replace tank /dev/disk/by-id/ata-WDC_WD80EFAX_B2B... /dev/disk/by-id/ata-WDC_WD80EFAX_NEW...
cr0x@server:~$ sudo zpool status tank
pool: tank
state: DEGRADED
scan: resilver in progress since Thu Dec 26 02:03:22 2025
96.4G scanned at 485M/s, 62.1G issued at 313M/s, 5.41T total
62.1G resilvered, 1.15% done, 05:02:10 to go
Significado: Reemplazo iniciado; resilver comienza. “Issued” muestra trabajo de reconstrucción real.
Decisión: Si la tasa de resilver es extremadamente baja, pasa inmediatamente al diagnóstico de cuellos de botella (ver playbook). Resilvers lentos extienden la ventana de riesgo.
Task 6: Detectar corrupción silenciosa frente a errores de dispositivo
cr0x@server:~$ sudo zpool status -v tank
pool: tank
state: ONLINE
scan: scrub repaired 0B in 06:11:44 with 0 errors on Thu Dec 26 08:02:13 2025
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sda ONLINE 0 0 2
sdb ONLINE 0 0 0
errors: No known data errors
Significado: El dispositivo sda tiene errores de checksum. Scrub no reparó nada, pero ZFS observó datos malos en ese dispositivo y los corrigió desde la redundancia.
Decisión: Investiga sda de inmediato: cableado/HBA, firmware, SMART, y considera reemplazo preventivo. Los errores de checksum son ZFS diciéndote educadamente que un disco mintió.
Task 7: Correlacionar errores ZFS con logs del kernel
cr0x@server:~$ sudo dmesg -T | tail -n 20
[Thu Dec 26 03:11:19 2025] sd 2:0:8:0: [sda] tag#231 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Thu Dec 26 03:11:19 2025] sd 2:0:8:0: [sda] Sense Key : Medium Error [current]
[Thu Dec 26 03:11:19 2025] sd 2:0:8:0: [sda] Add. Sense: Unrecovered read error
[Thu Dec 26 03:11:19 2025] blk_update_request: I/O error, dev sda, sector 2384812048
[Thu Dec 26 03:11:21 2025] ata3: hard resetting link
Significado: Esto no es “ZFS siendo quisquilloso.” El kernel reporta errores reales de lectura y resets de enlace.
Decisión: Trátalo como un disco o ruta fallando. Si ves resets, también sospecha de cableado SATA/SAS, expander o HBA—no solo del disco.
Task 8: Revisar SMART rápidamente (triage)
cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i 'Reallocated|Pending|Offline_Uncorrectable|UDMA_CRC|SMART overall'
SMART overall-health self-assessment test result: PASSED
5 Reallocated_Sector_Ct 0x0033 098 098 010 Pre-fail Always - 12
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 4
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 4
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 87
Significado: “PASSED” no exime. Sectores pendientes/uncorrectable son malos; CRC altos gritan problemas de cableado/ruta.
Decisión: Si CRC sube, arregla cableado/backplane/HBA primero. Si hay pendientes/uncorrectable, planifica reemplazo aunque el disco aún “funcione”.
Task 9: Encontrar ashift y topología del pool (establece expectativas)
cr0x@server:~$ sudo zdb -C tank | egrep 'ashift|vdev_tree|type'
ashift: 12
type: 'root'
type: 'mirror'
type: 'disk'
type: 'disk'
Significado: ashift: 12 implica sectores de 4K. Elecciones de ashift malas pueden castigar I/O aleatorio y hacer scrubs/resilvers más lentos de lo esperado.
Decisión: Si ashift está mal (demasiado pequeño), no puedes arreglarlo in-place. Planifica migración, no heroísmos durante un incidente.
Task 10: Comprobar si autotrim afecta al rendimiento del scan
cr0x@server:~$ sudo zpool get autotrim tank
NAME PROPERTY VALUE SOURCE
tank autotrim on local
Significado: Autotrim puede añadir trabajo en background en pools SSD. Normalmente está bien, a veces contribuye a “por qué todo está lento ahora”.
Decisión: Si estás resilvering en SSD bajo carga, considera desactivar temporalmente trabajo de fondo no esencial—pero solo si entiendes el comportamiento y resistencia de tus SSD.
Task 11: Observar I/O en tiempo real mientras corre scrub/resilver
cr0x@server:~$ sudo iostat -x 2 5
Linux 6.8.0 (server) 12/26/2025 _x86_64_ (32 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
3.1 0.0 2.8 18.6 0.0 75.5
Device r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 415.2 18.1 54032 6120 252.1 9.84 23.5 22.9 37.2 1.9 82.4
sdb 402.7 17.5 52810 5904 251.6 9.21 22.1 21.6 35.8 1.8 79.3
Significado: %util alto y colas (avgqu-sz) con await en aumento indican discos saturados. Eso estirará tu scan y golpeará la latencia de la app.
Decisión: Si los SLO de producción importan, limita el scan o mueve la carga. Si la prioridad es resilver, aceptas el dolor pero vigila que no aparezca un segundo disco con errores.
Task 12: Identificar si la presión de ARC empeora todo
cr0x@server:~$ sudo arcstat 2 3
time read miss miss% dmis dm% pmis pm% mmis mm% size c avail
01:33:20 328K 112K 34 28K 25 72K 64 12K 11 92G 104G 18G
01:33:22 341K 126K 36 31K 25 83K 66 12K 10 92G 104G 18G
01:33:24 355K 149K 42 45K 30 96K 64 8K 5 92G 104G 18G
Significado: La tasa de misses subiendo durante el scan sugiere que el scan está expulsando caché útil, especialmente en sistemas ocupados.
Decisión: Si los scans rutinariamente destrozan caché y perjudican apps, prográmalos mejor, o ajusta el comportamiento del scan (dependiente de plataforma), o añade RAM si la carga lo justifica.
Task 13: Verificar la última vez que se hizo scrub y si estás atrasado
cr0x@server:~$ sudo zpool status tank | grep -E 'scan:|scrub'
scan: scrub repaired 0B in 06:11:44 with 0 errors on Thu Dec 26 08:02:13 2025
Significado: Tienes una referencia: duración y resultado.
Decisión: Si no encuentras una línea reciente “scrub repaired … with … errors” en tu historial, estás volando a ciegas. Implementa un calendario y alertas.
Task 14: Comprobar si un resilver se está reiniciando o no avanza
cr0x@server:~$ sudo zpool status tank | sed -n '1,25p'
pool: tank
state: DEGRADED
scan: resilver in progress since Thu Dec 26 00:41:11 2025
1.23T scanned at 612M/s, 742G issued at 369M/s, 5.41T total
742G resilvered, 13.40% done, 03:46:12 to go
Significado: “Scanned” aumentando mientras “issued” se estanca puede indicar que el scan está recorriendo metadatos pero no emitiendo I/O útil—a veces por contención, a veces por errores.
Decisión: Si el porcentaje no se mueve en varias comprobaciones, busca errores de dispositivo y cuellos de botella. No te cruces de brazos esperando.
Task 15: Confirmar salud del pool al completarse
cr0x@server:~$ sudo zpool status -v tank
pool: tank
state: ONLINE
scan: resilvered 5.41T in 06:02:18 with 0 errors on Thu Dec 26 06:43:29 2025
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sda ONLINE 0 0 0
sdb ONLINE 0 0 0
errors: No known data errors
Significado: Resilver terminó con 0 errores y el pool está ONLINE.
Decisión: Ahora haz un scrub (pronto) si no lo has hecho recientemente, porque la finalización del resilver no garantiza que no haya corrupción latente en otra parte.
Guía de diagnóstico rápido (encuentra el cuello de botella rápido)
Cuando un scrub/resilver es lento, los equipos pierden horas discutiendo sobre “overhead de ZFS.” No lo hagas.
Encuentra el cuello de botella. Casi siempre es una de: dispositivo, controlador/ruta, contención por carga,
recordsize/patrones de bloques pequeños o presión de memoria del sistema.
Primero: establece qué está corriendo y qué significa “lento”
-
Revisa tipo de scan y progreso:
ejecutazpool status. Registra tasa scanned/issued, ETA y si aparecen errores.
Si el ETA aumenta, no es solo lento; es inestable. -
Revisa el estado del pool:
ONLINE vs DEGRADED cambia todo. Si está DEGRADED, terminar el resilver es la prioridad uno.
Segundo: encuentra la capa limitante (disco vs ruta vs CPU vs caché)
-
Saturación de disco:
iostat -x. Busca %util alto, await alto, colas grandes.
Si un disco tiene latencia mucho peor que sus pares, es el villano. -
Errores del kernel:
dmesg -T. Resets de enlace, timeouts, “Medium Error”, “I/O error” son evidencia sólida.
Arregla rutas antes de tunear ZFS. -
Presión de ARC:
arcstato equivalente de la plataforma.
Si el scan expulsa datos calientes, las aplicaciones sufrirán y pueden amplificar I/O. -
Cuellos de CPU (menos comunes pero reales en cargas con muchos checksums):
verifica la CPU del sistema, y si hay compresión/encriptación en juego. Scrub verifica checksums; eso consume CPU.
Tercero: decide el modo de operación
-
Modo seguridad-primero (degraded, errores recientes de disco, hardware incierto):
minimiza churn adicional, no inicies nuevos scrubs, reduce ráfagas de escritura de la app y evita reinicios. -
Modo rendimiento-primero (pool sano, scrub planificado):
programa, limita y mantenlo predecible. La meta es “terminar sin que nadie se dé cuenta”, no “ganar benchmarks”.
Errores comunes: síntomas → causa raíz → solución
Mistake 1: “Scrub reconstruirá el disco faltante”
Síntomas: El pool está DEGRADED. Alguien ejecuta scrub. Nada se “arregla.” El estado degraded persiste.
Causa raíz: Scrub no es una operación de reconstrucción de redundancia. Audita y repara bloques corruptos; no repuebla un dispositivo ausente/fallado.
Solución: Reemplaza/online/attach el dispositivo para disparar resilver. Usa zpool replace o zpool online según corresponda. Luego monitorea el resilver.
Mistake 2: “Resilver terminó, así que los datos están verificados”
Síntomas: Tras reemplazar un disco, el equipo se relaja. Semanas después, una lectura arroja errores de checksum o una app reporta corrupción.
Causa raíz: Resilver reconstruye redundancia para un dispositivo; no necesariamente recorre y verifica cada bloque de todo el pool.
Solución: Programa scrubs regulares. Después de eventos mayores (fallas de disco, resets de controladora), ejecuta un scrub en la próxima ventana segura.
Mistake 3: Cancelar scrubs para siempre porque “doler”
Síntomas: Los scrubs siempre se cancelan. Finalmente un segundo disco falla durante una reconstrucción y aparecen errores latentes en el peor momento.
Causa raíz: Scrub es el mecanismo que encuentra errores latentes mientras aún tienes redundancia para repararlos.
Solución: Ejecuta scrubs con cadencia predecible. Si el impacto es inaceptable, ajusta el calendario, añade headroom de I/O o modifica el diseño del pool.
Mistake 4: Tratar errores de checksum como “solo ZFS siendo dramático”
Síntomas: Los contadores CKSUM suben en un dispositivo. El pool sigue ONLINE. La gente lo ignora.
Causa raíz: Los errores de checksum significan que los datos leídos de ese dispositivo no coincidieron con lo esperado. ZFS lo corrigió usando redundancia—esta vez.
Solución: Revisa cableado/HBA, luego SMART, y reemplaza el dispositivo si los errores persisten. Además ejecuta scrub para forzar verificación y curación.
Mistake 5: Optimizar velocidad de scan sacrificando aplicaciones (o al revés)
Síntomas: Limitas scrubs tanto que duran días, o los deslimitás tanto que la producción colapsa.
Causa raíz: Los scans son I/O de fondo que deben equilibrarse contra demandas de latencia en primer plano.
Solución: Elige una política explícita: ventanas horarias, límites y alertas si los scans superan un umbral de duración (señal de problema de hardware subyacente).
Mistake 6: Reemplazar el disco equivocado porque /dev/sdX cambió
Síntomas: Tras un reinicio, el nombre del disco fallado cambia. El técnico retira el sled equivocado. Ahora estás degradado por duplicado.
Causa raíz: Usar nodos de dispositivo efímeros en lugar de identificadores estables.
Solución: Usa rutas /dev/disk/by-id en ZFS y en documentación operativa. Verifica con zpool status -P antes de cualquier acción física.
Tres mini-historias corporativas (cómo falla esto)
Mini-historia #1: El incidente por una suposición equivocada
Una SaaS mediana ejecutaba ZFS con un par de HDDs en mirror por nodo. Nada sofisticado. Un disco se desconectó en un fin de semana tranquilo.
El ingeniero on-call vio “DEGRADED” y hizo lo que pensó era lo seguro y conservador: inició un scrub.
La suposición era simple: scrub equivale a “reparar”. Y ZFS sí repara durante scrub—cuando tiene redundancia. Pero el disco faltante seguía ausente.
Scrub recorrió el disco restante, verificó lo que pudo y forzó muchas lecturas. Mientras tanto, el pool no tenía redundancia.
El disco restante no aguantó ser la única fuente de verdad bajo carga sostenida. Aparecieron sectores latentes defectuosos.
Unos pocos bloques no se pudieron leer limpiamente. Sin pareja de mirror, ZFS no pudo curarlos. Ahora el pool tenía errores de datos reales, no solo “redundancia degradada”.
Reemplazaron el disco el lunes y resilvered. La redundancia volvió, pero los bloques dañados siguieron dañados—porque la única copia buena nunca existió.
El impacto no fue pérdida total, pero sí peor: un puñado de objetos corruptos en el blob store de la app, descubiertos por clientes en producción.
La corrección postmortem fue aburrida: tratar “degraded” como “minimizar estrés adicional”, priorizar restaurar redundancia (resilver) y ejecutar scrub después del resilver en una ventana.
Además: poner “scrub is not a rebuild” en el runbook con letras grandes.
Mini-historia #2: La optimización que salió mal
Una empresa financiera tenía pools RAIDZ2 para un data warehouse. Los scrubs eran dolorosos, así que un ingeniero decidió “optimizar” ejecutando scrubs constantemente a baja intensidad
y cancelándolos en horario laboral. La idea era siempre avanzar sin ser visible.
En la práctica, los scrubs nunca terminaban. Corrían unas horas, se cancelaban, reiniciaban más tarde, se cancelaban otra vez. Semanas pasaron sin un scrub completado.
Todos se sentían bien porque el historial de comandos mostraba “scrub started” con frecuencia. A la gerencia le gusta la actividad.
Luego falló un disco. Resilver arrancó, y fue más lento de lo esperado porque uno de los discos restantes tenía un montón creciente de sectores ilegibles.
Los sectores ilegibles habían estado presentes por un tiempo, pero el patrón de scrubs interminables nunca forzó un pase completo que hubiera detectado el problema temprano.
Resilver encontró esos sectores malos en el peor momento: con la redundancia reducida y alta carga.
El resilver se arrastró, mantuvo el pool en ventana de riesgo por más tiempo y el rendimiento del warehouse se hundió durante reportes pico.
La solución no fue “scrub menos”. Fue “scrub correctamente”: programa una ventana donde termine, alerta en la finalización y errores, y registra duraciones de referencia.
Su “optimización” fue actividad sin resultados, la versión corporativa de correr en el lugar.
Mini-historia #3: La práctica aburrida pero correcta que salvó el día
Una empresa de medios manejaba grandes pools ZFS con mirrors de SSDs para contenido caliente y RAIDZ para archivos templados.
Nada heroico, pero hacían tres cosas disciplinadas: scrubs mensuales con alertas de finalización, nombres by-id estables en todas partes,
y una regla estricta de investigar cualquier error de checksum en el plazo de un día.
Una mañana, las alertas mostraron un scrub completado que registró un pequeño número de errores de checksum en un SSD.
El pool siguió ONLINE. Sin impacto al cliente. Este es el momento exacto en que los equipos tienden a encogerse de hombros.
No se encogieron. Sacaron SMART, vieron CRC creciendo y encontraron un cable marginal en el backplane.
Arreglaron la ruta, limpiaron contadores de error reemplazando el cable y recolocando, y luego ejecutaron un scrub de seguimiento.
No hubo más errores. Problema resuelto tranquilamente.
Un mes después, un nodo distinto perdió un disco de verdad. El resilver completó rápido porque los dispositivos restantes estaban sanos
y el equipo ya tenía confianza en sus referencias de scan. Sin drama, sin “quizás está bien”, sin archivos corruptos sorpresa.
Las prácticas aburridas están subestimadas porque no producen adrenalina. Producen uptime.
Hechos interesantes y contexto histórico
- ZFS se construyó en torno a checksums end-to-end, lo que significa que el sistema de archivos, no el disco, decide si los datos son correctos.
- Scrub existe para atrapar errores latentes—la clase “bit rot” de problemas que RAID tradicional puede no detectar hasta que es demasiado tarde.
- Los primeros sistemas ZFS popularizaron los scrubs rutinarios como hábito operativo, similar a cómo las bases de datos popularizaron backups rutinarios y chequeos de consistencia.
- El comportamiento de resilver evolucionó con el tiempo; enfoques antiguos podían parecer “reconstruir todo el disco”, mientras que los más nuevos se centran en el espacio asignado y son más secuenciales cuando es posible.
- Resilver en RAIDZ lee inherentemente muchos discos para reconstruir el faltante. Los mirrors pueden ser más suaves: leer un lado, escribir el otro.
- Los nombres de dispositivo causaron problemas operativos; el cambio industrial hacia identificadores estables (
by-id, WWN) fue impulsado por incidentes reales de reemplazo de disco equivocado. - Los checksums no previenen corrupción; la detectan. La prevención viene de redundancia más acciones de reparación (scrub o lecturas normales que producen curación).
- Scrub no es verificación de espacio libre. Si quieres someter un disco nuevo a una prueba intensiva, haces burn-in y pruebas SMART, no solo un scrub de ZFS.
- Las cargas sensibles a latencia notan los scans primero; el dolor no es “ancho de banda”, es demora por colas. Por eso iostat
awaitimporta más que MB/s crudos.
Broma #2: Los scrubs son la visita al dentista del almacenamiento—si los saltas lo suficiente, tarde o temprano pagarás en endodoncias.
Listas de verificación / planes paso a paso
Plan A: Reemplazaste un disco y empezó el resilver
- Confirma el dispositivo objetivo:
zpool status -P. Asegúrate de que estás resilvering lo que crees que es. - Revisa el estado del pool: si está DEGRADED, trata esto como un incidente prioritario hasta que el resilver termine.
- Vigila nuevos errores: revisa contadores
READ/WRITE/CKSUMcada 10–30 minutos durante las primeras horas. - Revisa logs del kernel: si ves resets/timeouts, arregla la ruta ahora. Un enlace inestable puede alargar el resilver y provocar más fallos.
- Decide la política de contención: si es carga crítica, quizá reduzcas temporalmente la carga de la app para terminar el resilver más rápido.
- Tras la finalización: verifica ONLINE y 0 errores; luego programa un scrub pronto (no necesariamente inmediatamente) para validar el pool en general.
Plan B: Un scrub es lento y el negocio está gritando
- Mide impacto: revisa latencia de app y
awaitde disco. Si no lo cuantificas, negocias con sensaciones. - Comprueba si el scrub está encontrando reparaciones:
zpool status. Si está reparando, detenerlo puede postergar curación. Equilibra el riesgo. - Decide: cancelar o continuar: Si la producción está en riesgo y el pool es sano, cancela el scrub y reprograma. Si el pool muestra errores, inclínate a continuar en una ventana controlada.
- Arregla la causa raíz: scrubs lentos suelen señalar discos fallando, problemas de cableado o un diseño de pool sin headroom de IOPS.
- Establece duraciones de referencia: registra cuánto tardan los scrubs en hardware sano. Cuando se duplica, algo cambió.
Plan C: Ves errores de checksum pero todo “parece bien”
- Identifica el dispositivo: ¿qué disco acumula errores
CKSUM? - Revisa dmesg: busca errores I/O y resets.
- Revisa SMART: sectores pendientes y CRC indican si es medio o ruta.
- Ejecuta un scrub (en ventana segura): fuerza verificación y curación.
- Reemplaza o arregla la ruta: si los errores persisten, no negocies con un disco que miente. Reemplázalo.
Preguntas frecuentes
1) ¿Un scrub lee el espacio libre?
No. Scrub recorre bloques asignados (datos vivos y metadatos). Es verificación de integridad, no un escaneo de superficie de disco.
2) ¿Resilver verifica checksums como scrub?
Las operaciones de resilver implican leer bloques y escribir copias reconstruidas/correctas, y la verificación de checksum ocurre como parte de lecturas normales.
Pero resilver no es una auditoría completa de todo el pool; se centra en lo que el dispositivo objetivo necesita para volver correctamente.
3) ¿Debería ejecutar un scrub inmediatamente después del resilver?
Usualmente: pronto, sí. Inmediatamente: depende. Si el sistema está frágil o muy cargado, prográmalo para la próxima ventana segura.
La idea es validar el pool en general después de un evento disruptivo.
4) ¿Por qué “scanned” es mayor que “issued” en zpool status?
“Scanned” refleja hasta dónde ZFS ha recorrido el espacio que necesita considerar. “Issued” refleja las solicitudes de I/O realmente enviadas.
La brecha puede ampliarse por recorridos de metadatos, omisión de regiones no necesarias, contención o detalles de implementación.
5) ¿Es seguro cancelar un resilver?
“Seguro” es la pregunta equivocada. Cancelar un resilver te deja degraded por más tiempo. Eso aumenta el riesgo.
Cancelas solo si debes, y lo reinicias tan pronto como sea posible tras solucionar la razón (por ejemplo, un problema de ruta).
6) Scrub encontró errores pero sigue apareciendo “errors: No known data errors”. ¿Qué pasa?
ZFS puede corregir algunos errores usando redundancia. Si reparó todo con éxito, puede no quedar “known data errors”.
La presencia de errores de dispositivo CKSUM sigue importando: algo devolvió datos malos.
7) ¿Ejecutar scrubs reduce la vida útil de los SSD?
Scrub es mayormente lecturas; las escrituras ocurren al reparar. Las lecturas aún consumen recursos de controladora (indirectamente), pero la preocupación por write amplification suele ser moderada.
El problema más grande es el impacto en el rendimiento y asegurar que tus SSD estén sanos y bien refrigerados.
8) ¿Con qué frecuencia debo hacer scrub?
Práctica común: mensual en pools grandes, más frecuente en sistemas críticos, menos frecuente en archivos poco usados—si tienes buen monitoreo y conoces tu riesgo.
La respuesta correcta es: con la suficiente frecuencia para detectar errores latentes antes de que una segunda falla los vuelva irrecuperables.
9) ¿Por qué resilver tarda tanto en RAIDZ comparado con mirrors?
Resilver en RAIDZ requiere leer datos/paridad de múltiples discos para reconstruir lo que pertenece al disco faltante. Los mirrors pueden copiar desde un único miembro sano.
La topología dicta el fan-out de I/O y la penalización bajo contención.
10) Si mi pool está sano, ¿puedo ignorar errores de checksum ocasionales?
No. Ocasional puede significar “raro y transitorio”, pero también puede ser “advertencia temprana”. Investiga primero.
El costo de revisar logs y SMART es barato comparado con descubrir que era real durante un evento degraded.
Próximos pasos que puedes hacer esta semana
- Programa scrub en una cadencia que realmente complete (y alerta en finalización y errores). “Started” no es un estado útil.
- Establece duración de referencia de scrub en hardware sano. Cuando cambie materialmente, investiga antes de tener una falla.
- Estandariza identificadores de disco estables (
/dev/disk/by-id) en configuraciones de pool y runbooks. - Escribe un procedimiento de una página para pool degraded: prioriza resilver, minimiza churn, vigila errores en segundo dispositivo, evita reinicios riesgosos.
- Entrena al equipo en
zpool status: la línea scan, los contadores de error y qué promete y qué no promete “No known data errors”. - Decide tu política para el impacto de scans: cuándo cancelar un scrub, cuándo dejarlo correr y cómo manejar presión en horario laboral sin abandonar las comprobaciones de integridad.
Scrub y resilver son ambos operaciones de “scan”, por eso la gente las mezcla en conversación.
Pero en operaciones, los verbos importan. Uno prueba. El otro reconstruye. Si los tratas como intercambiables, ZFS no discutirá contigo—simplemente ejecutará fielmente tu error.