zpool scrub es mantenimiento preventivo. Poco glamuroso, muy necesario.
En un homelab con Proxmox es fácil obsesionarse con lo visible. VMs, contenedores, dashboards, túneles, automatizaciones, paneles que se actualizan solos. Todo eso mola más que revisar si ZFS ha leído el pool entero y ha comprobado que los datos siguen siendo los datos que deberían ser.
Pero el storage es donde se guardan las consecuencias de todas tus decisiones. Las buenas y las idiotas. Si una VM importante vive en ZFS, si tienes contenedores con datos reales, si usas snapshots o si confías en un pool para aguantar varios servicios, el scrub no es opcional. Es una de esas tareas aburridas que separan un homelab serio de una colección de máquinas esperando su próxima desgracia.
El comando manual es este.
| |
Y para revisar el estado.
| |
No tiene más misterio en la superficie. Lo interesante está en cuándo lanzarlo, cómo leerlo y qué no esperar de él.
la captura de este post#
La captura usa una salida saneada de zpool status después de un scrub terminado. He dejado nombres genéricos de pool y discos. Los tiempos y la estructura son realistas para un pool de Proxmox con mirrors NVMe. No aparecen IPs, dominios internos ni nombres privados.
Esta es la salida saneada que usé para generar la captura:
| |
Esta es la lectura que me gusta ver. Pool online, scrub terminado, repaired 0B, cero errores conocidos. Aburrido. Perfecto.
qué hace realmente un scrub#
Un scrub recorre los datos del pool y verifica checksums. ZFS guarda checksums de los bloques y usa esa información para detectar corrupción silenciosa. Si el pool tiene redundancia, por ejemplo mirrors o RAIDZ, puede reparar datos usando una copia válida.
Esto es una de las razones por las que uso ZFS con bastante cariño. No porque sea mágico. ZFS no te perdona backups malos, discos baratos ni decisiones tomadas con prisa. Pero sí tiene una cosa muy buena: no se limita a confiar en que el disco diga la verdad.
El scrub fuerza una lectura y comprobación. Si hay corrupción latente, prefiero enterarme un domingo a las cuatro de la mañana durante una tarea programada que el día que intento arrancar una VM y descubro que el dato roto era justo el que necesitaba.
No hace falta dramatizar. Tampoco hace falta ignorarlo.
scrub no es backup#
Esto merece sección propia porque es una confusión peligrosa.
Un scrub no es un backup. No guarda una copia externa. No te protege de borrar una VM. No te salva de ransomware. No arregla que hayas hecho rm donde no tocaba. No sustituye a Proxmox Backup Server, Restic, snapshots replicados ni a una copia fuera del equipo.
Un scrub comprueba y repara integridad dentro del pool si tiene con qué reparar. Punto.
Yo lo veo como revisión de salud del storage. Los backups son otra conversación. Relacionada, sí, pero distinta. Un servidor puede tener scrubs perfectos y aun así perder datos por una cagada humana. También puede tener backups y descubrir durante un scrub que un disco empieza a fallar.
Las dos cosas importan. Una no tapa la otra.
cuándo lo lanzo#
En Proxmox suelo preferir scrubs programados. No quiero acordarme manualmente de algo que sé que voy a olvidar cuando el día se tuerza.
En Debian y Proxmox puedes encontrarte timers de ZFS ya preparados según la instalación y los paquetes. Lo primero que miro es esto.
| |
También reviso unidades relacionadas.
| |
Si no hay timer claro, lo programo con cuidado. No lo lanzo a la misma hora que backups grandes, actualizaciones, verificaciones de PBS o trabajos pesados. Un scrub lee mucho. En NVMe suele ser llevadero, pero no deja de ser carga real sobre el pool.
Mi preferencia para un homelab normal es mensual. En pools muy activos o con discos que me preocupan, puedo hacerlo con más frecuencia. En pools enormes con discos mecánicos, hay que mirar ventana horaria y duración. No es lo mismo un pool NVMe de unos pocos teras que un NAS con discos grandes y lentos.
La regla sencilla: prográmalo cuando el homelab duerme, no cuando tú estás peleando con él.
cómo leo el resultado#
La línea importante es scan.
| |
Aquí miro tres cosas.
Primero, si el scrub terminó. Si aparece scrub in progress, espero o reviso progreso. No saco conclusiones a medias.
Segundo, si reparó algo.
| |
Cero bytes reparados es lo que quiero ver. Si repara datos, no entro en pánico automáticamente, pero tampoco lo ignoro. ZFS ha encontrado algo y lo ha corregido. Eso merece mirar discos, logs y frecuencia del problema.
Tercero, si hay errores.
| |
Cero errores conocidos, bien. Si aparecen errores, miro READ, WRITE y CKSUM por dispositivo. Ahí ya no estoy haciendo mantenimiento rutinario. Estoy diagnosticando.
READ, WRITE y CKSUM#
La tabla de zpool status enseña contadores por pool, vdev y disco.
| |
READ apunta a errores de lectura. WRITE a errores de escritura. CKSUM a errores de checksum. Cualquiera de los tres me interesa, pero los de checksum tienen una forma especial de ponerme serio.
Un contador aislado puede venir de un evento puntual, un corte, un cable, una controladora rara o un disco que empieza a enseñar la patita. Lo importante es no mirar solo una vez. Limpio mentalmente el contexto, reviso logs y observo si el contador crece.
Comandos que suelo cruzar.
| |
En NVMe también miro datos concretos del dispositivo.
| |
No publico salidas reales completas de esos comandos porque suelen tener identificadores, números de serie y detalles que no quiero enseñar. En casa no pasa nada hasta que pasa.
qué hago si el scrub repara datos#
Si veo algo como repaired 128K, no apago todo gritando. Pero tampoco lo dejo para mañana sin mirar.
Mi orden suele ser este.
- Revisar
zpool status -v. - Identificar si el error apunta a un disco concreto.
- Mirar logs recientes del sistema.
- Revisar SMART o NVMe health.
- Confirmar que los backups recientes existen.
- Ejecutar otro scrub si tiene sentido después de revisar la causa.
Si el mismo disco acumula errores, lo saco de la categoría “cosas a vigilar” y lo meto en “cosas que van a fastidiar el día”. En mirrors, cambiar un disco a tiempo es muchísimo menos divertido que presumir de uptime, pero también es bastante más inteligente.
Si el pool no tiene redundancia, la conversación cambia. ZFS puede detectar corrupción, pero no siempre podrá repararla. Esto es lo que mucha gente olvida cuando monta ZFS en un único disco y se siente invencible. Detectar que algo está roto no es lo mismo que tener una copia buena para arreglarlo.
scrub durante carga alta#
No me gusta lanzar scrubs mientras el pool ya está ocupado. En un laboratorio pequeño quizá no pasa nada. En uno con VMs de verdad, backups y servicios de casa, se nota.
Antes de lanzarlo manualmente miro actividad.
| |
Si veo backup en curso, migración o una VM escribiendo fuerte, espero. El scrub no es una emergencia salvo que esté investigando corrupción. Como mantenimiento, puede esperar a una ventana razonable.
También miro tareas de Proxmox.
| |
No quiero mezclar scrub con media docena de operaciones pesadas y luego quejarme de que el cluster va lento. Eso sería muy de humano. Lo he hecho. No aporta nada.
cómo pararlo si me equivoqué#
Si lancé un scrub en mal momento, se puede parar.
| |
No es algo que use mucho, pero está bien saberlo. Si el pool está sufriendo, si hay una tarea crítica o si me equivoqué de ventana, prefiero parar y reprogramar.
Después reviso estado.
| |
Y dejo constancia mental de que el scrub quedó interrumpido. Si lo paras siempre, en realidad no tienes mantenimiento. Tienes una intención decorativa.
snapshots y scrub no son lo mismo#
ZFS snapshots son fantásticos para volver atrás en cambios concretos. Los uso y me gustan. Pero no comprueban por sí mismos todo el pool como un scrub. Un snapshot conserva un estado. Un scrub verifica integridad.
Esto importa porque en Proxmox es fácil mezclar palabras de storage y pensar que todo está cubierto. Snapshot, backup, replication, scrub, mirror. Cada cosa resuelve un problema distinto.
Un snapshot te puede salvar de una actualización mala. Un backup te puede salvar de perder el nodo. Un mirror te puede salvar de un disco muerto. Un scrub te puede avisar de corrupción silenciosa. Ninguno de ellos te salva de entender mal el sistema.
mi frecuencia recomendada#
Para un homelab con Proxmox y ZFS, empezaría con scrub mensual. Si el pool tiene discos mecánicos grandes, lo pondría en una ventana tranquila y observaría cuánto tarda. Si son NVMe y el pool no es enorme, probablemente ni te enteres fuera de un pequeño aumento de actividad.
Si tienes datos muy importantes, no uses solo mi frecuencia. Mira tu volumen, tus discos, tus backups y tu tolerancia al riesgo. Un homelab no tiene SLA de banco, pero tampoco tiene por qué ser una ruleta.
En mi caso, lo que quiero es rutina. Que el sistema revise solo, que yo lea resultados cuando toca y que los errores no aparezcan por primera vez el día de la restauración.
señales que no ignoro#
Hay varias cosas que me hacen parar.
DEGRADEDo cualquier estado que no seaONLINE.- Errores
CKSUMque crecen. repaireddistinto de cero en scrubs repetidos.- Un disco concreto acumulando errores.
- Scrubs que tardan muchísimo más que antes sin explicación.
- Backups correctos en apariencia, pero pool con errores.
La última es especialmente puñetera. Un backup puede completarse mientras el storage te está enseñando avisos que nadie mira. Por eso me gusta revisar la salud del pool como parte separada de la rutina.
mi checklist corta#
Cuando reviso scrub en Proxmox, hago esto.
| |
Si el estado es limpio, el timer existe y el pool no muestra actividad rara, cierro. Si algo canta, bajo a logs y salud de discos.
No necesito convertirlo en ceremonia. Necesito que ocurra y que alguien mire el resultado.
cierre#
zpool scrub es aburrido hasta que deja de serlo. Esa es precisamente la razón para tenerlo controlado.
En Proxmox, donde una VM puede contener media vida digital y un contenedor puede parecer pequeño hasta que descubres que guarda datos importantes, no quiero esperar a que un disco falle de forma espectacular. Prefiero que ZFS lea, compruebe y me diga si algo empieza a torcerse.
No es backup. No es magia. No arregla una arquitectura mala. Pero como mantenimiento básico de ZFS, me parece de lo más sensato que puedes hacer por tu homelab.
Y además tiene una virtud rara: cuando todo va bien, el resultado es profundamente aburrido. En storage, aburrido suele ser buena noticia.