Btrfs scrub es una de las funciones de mantenimiento más importantes y más malentendidas de Btrfs. No es fsck en el sentido tradicional. Es una pasada de validación online que lee datos y metadata del filesystem, verifica checksums, superblocks, metadata block headers y errores de lectura del disco, e intenta reparar daños cuando existe una réplica buena conocida.
Si usas Btrfs en un NAS, servidor doméstico, disco de backup o array multidispositivo, scrub debería formar parte del mantenimiento periódico. Su valor no es “ejecutarlo después del desastre”, sino detectar corrupción silenciosa temprano, mientras los discos aún se pueden leer y todavía existen réplicas buenas.
Qué comprueba scrub
Según la documentación oficial de Btrfs, scrub recorre datos y metadata del filesystem y comprueba principalmente:
- Errores de checksum en bloques de datos.
- Errores básicos de super block.
- Errores básicos de metadata block header.
- Errores de lectura de disco.
En filesystems que usan perfiles de block group replicados, como RAID1, scrub sobre un montaje read-write puede reparar automáticamente algunos daños. La reparación no es recuperación mágica. Btrfs copia datos buenos verificados desde otra réplica.
Este punto es clave: la reparación de scrub depende de que exista una copia buena conocida. En un disco único con una sola copia de los datos, scrub puede detectar errores de checksum, pero normalmente no puede restaurar el contenido original por sí mismo.
Comandos comunes
Iniciar scrub sobre un punto de montaje:
|
|
Ejecutarlo en foreground, útil para observar manualmente:
|
|
Ver estado:
|
|
Cancelar un scrub en ejecución:
|
|
Reanudar un scrub interrumpido:
|
|
Si especificas una ruta montada de Btrfs, Btrfs hace scrub de todos los dispositivos del filesystem en paralelo. Si especificas un dispositivo, solo se hace scrub de ese dispositivo. Pero si la réplica del dispositivo indicado no puede leerse o verificarse, Btrfs intenta leer una copia buena desde otro dispositivo.
Scrub no es fsck
Este es el error más común. Scrub no es btrfs check ni un comprobador tradicional de filesystem.
Scrub puede:
- Usar checksums para detectar corrupción de datos o metadata.
- Reparar automáticamente cuando existe otra réplica fiable.
- Detectar errores de lectura de disco y algunos errores estructurales básicos.
Scrub no puede:
- Reconstruir datos cuando no existe una réplica buena.
- Sustituir una comprobación offline del filesystem.
- Reparar toda corrupción compleja de estructuras de árbol.
- Garantizar que el contenido a nivel de aplicación sea correcto.
Si las estructuras del filesystem están gravemente dañadas, pueden necesitarse herramientas como btrfs check bajo guía experta. No trates scrub como un comando universal de reparación.
Riesgos de archivos NOCOW
La documentación de Btrfs advierte de un punto importante: al establecer el atributo NOCOW con chattr +C, la implementación actual también activa implícitamente NODATASUM. Eso significa que los datos del archivo no tienen checksum.
Scrub aún puede validar y reparar la metadata de esos archivos, pero no puede validar el contenido de sus datos. Esto es especialmente arriesgado en configuraciones con varias réplicas: si una copia de un archivo NOCOW se daña, Btrfs no tiene checksum de datos para saber qué réplica es buena, así que puede devolver contenido dañado a user space.
Algunas aplicaciones usan +C por defecto por rendimiento. systemd journal y algunos escenarios de libvirt storage pool son ejemplos conocidos. Para imágenes de VM, bases de datos y directorios de logs puede tener sentido por rendimiento, pero significa que no puedes esperar que scrub proteja sus datos igual que protege archivos COW normales.
Read-only scrub todavía puede escribir
Otro punto contraintuitivo: ejecutar read-only scrub en un filesystem montado read-write puede causar algunas escrituras.
La documentación oficial explica que se debe a una limitación de diseño para evitar carreras entre marcar block groups como read-only y escribir de vuelta block group items. En otras palabras, si quieres que scrub no escriba nada, debes ejecutar read-only scrub sobre un filesystem montado read-only. Añadir una opción de read-only scrub sobre un montaje read-write no basta.
Para usuarios normales, esto significa:
- El scrub online rutinario puede ejecutarse sobre un montaje read-write.
- Para forense, análisis de fallos o comprobaciones muy conservadoras, confirma antes el estado del montaje.
- No interpretes read-only scrub como cero escrituras absolutas.
Interrupción y reanudación
En kernels recientes, scrub puede ser interrumpido por eventos como suspend, hibernate, filesystem freezing, cgroup freezing y pending signals. Tras una interrupción, el scrub en ejecución se cancela, pero puede reanudarse con btrfs scrub resume.
El estado de scrub se registra en:
|
|
Los nombres suelen parecerse a:
|
|
El archivo de estado se actualiza periódicamente. Un scrub reanudado continúa desde la última posición guardada, no desde el principio.
Cada cuánto ejecutarlo
La recomendación oficial es una vez al mes. En la práctica, ajusta según la importancia de los datos y el estado de los discos.
Calendarios comunes:
- NAS doméstico: una vez al mes.
- Discos de backup: tras sesiones largas conectados o una vez al mes.
- Arrays multidispositivo importantes: una vez al mes, o más a menudo si hace falta.
- Migración a disco nuevo o sospecha de fallo: ejecutar justo después de migrar.
Scrub puede usar alrededor del 80% del ancho de banda del dispositivo en un filesystem inactivo, así que no conviene ejecutarlo en horas pico. En arrays HDD, la latencia puede subir notablemente durante scrub. En SSD también añade read amplification y presión de fondo.
Limitar ancho de banda de scrub
Antes se usaba ionice para reducir el impacto de scrub sobre I/O foreground. La documentación oficial advierte que no todos los I/O schedulers lo soportan igual. CFQ ya no está disponible de forma general. BFQ soporta el comportamiento de prioridad relacionado, pero conviene entenderlo antes de usarlo. Para schedulers comunes como mq-deadline, suele ser mejor usar cgroup2 I/O controller o límites específicos de Btrfs.
Ejemplo con systemd para limitar ancho de banda de lectura:
|
|
Desde Linux 5.14, Btrfs puede establecer límites de scrub por dispositivo mediante sysfs:
|
|
Mostrar límites actuales:
|
|
Esta configuración no es persistente y desaparece al desmontar el filesystem. Sustituye FSID y DEVID por los valores reales de tu sistema. Puedes empezar comprobando:
|
|
Flujo práctico de mantenimiento
Un flujo razonable de mantenimiento Btrfs puede ser:
|
|
Si scrub informa corrected errors, Btrfs reparó datos desde una réplica buena, pero no debes ignorarlo. Sigue revisando SMART, cables, alimentación, controladores y Btrfs device stats.
Si scrub informa uncorrectable errors, Btrfs no encontró una copia buena. Haz backup cuanto antes de lo que aún pueda leerse, identifica archivos o dispositivos afectados, y reemplaza hardware o restaura desde backup según corresponda.
Resumen
Btrfs scrub tiene un papel claro: verificación online de datos y reparación desde réplicas. No es fsck y no es backup.
Funciona mejor en filesystems Btrfs con checksums y réplicas redundantes, donde puede encontrar corrupción silenciosa de forma periódica y restaurar desde copias buenas. No puede proteger datos de archivos NOCOW sin checksum, ni recuperar contenido dañado si no hay una réplica buena.
Si guardas datos importantes en Btrfs, ejecuta scrub mensualmente y úsalo junto con SMART, device stats, backups y alertas. La seguridad de datos fiable viene de checksums, redundancia, monitorización y backups trabajando juntos, no de un solo comando.
Referencias: