La llamada suele llegar cuando el panel de control está en verde y los datos han desaparecido. El arreglo está “saludable”. La base de datos está “en ejecución”.
Y, sin embargo, el director financiero mira un informe vacío, el equipo de producto mira un bucket vacío, y tú miras la frase que desearías haber tatuado en la orden de compra: RAID no es respaldo.
RAID es excelente en una cosa: mantener un sistema en línea ante ciertos tipos de fallo de disco. No está diseñado para protegerte contra
borrados, corrupción, ransomware, incendios, errores humanos, firmware roto, o la extraña y atemporal inclinación humana de ejecutar rm -rf
en la ventana equivocada.
Qué hace realmente RAID (y lo que nunca prometió)
RAID es un esquema de redundancia para la disponibilidad del almacenamiento. Eso es todo. Es una forma de seguir atendiendo lecturas y escrituras cuando un disco
(o a veces dos) deja de cooperar. RAID trata sobre continuidad del servicio, no continuidad de la verdad.
En términos de producción: RAID te compra tiempo. Reduce la probabilidad de que un fallo de disco único se convierta en una incidencia. Puede mejorar
el rendimiento según el nivel y la carga de trabajo. Puede simplificar la gestión de capacidad. Pero no crea una copia separada, independiente y versionada
de tus datos. Y la independencia es la palabra que mantiene tu trabajo.
Disponibilidad vs durabilidad vs recuperabilidad
La gente mezcla estas en un mismo cubo etiquetado “seguridad de datos”. No son lo mismo:
- Disponibilidad: ¿puede el sistema seguir funcionando ahora mismo? RAID ayuda aquí.
- Durabilidad: ¿permanecerán los bits correctos con el tiempo? RAID a veces ayuda, a veces engaña.
- Recuperabilidad: ¿puedes restaurar un estado conocido y bueno después de un incidente? Eso es respaldo, snapshots, replicación y proceso.
RAID puede seguir sirviendo datos corrompidos. RAID puede reflejar fielmente tu borrado accidental. RAID puede replicar con entusiasmo extremo los bloques cifrados por ransomware.
RAID es un empleado leal. Leal no significa inteligente.
Qué significa “respaldo” en un sistema que puedes defender
Un respaldo es una copia separada de los datos que es:
- Independiente del dominio de fallo primario (discos distintos, host distinto, idealmente cuenta/credenciales distintas).
- Versionada para que puedas retroceder a antes de que ocurriera lo malo.
- Restaurable dentro de un tiempo que puedas tolerar (RTO) y hasta un punto en el tiempo aceptable (RPO).
- Probada, porque “tenemos backups” no es un hecho hasta que has restaurado desde ellos.
Snapshots y replicación son excelentes herramientas. No son automáticamente respaldos. Se convierten en respaldos cuando son independientes, están protegidos
contra los mismos errores administrativos y puedes restaurarlos bajo presión.
Broma #1: RAID es el cinturón de seguridad. El respaldo es la ambulancia. Si confías en el cinturón para realizar cirugía, vas a tener un día largo.
Por qué RAID falla como respaldo: los modos de fallo que importan
La razón por la que se repite “RAID no es respaldo” es que los modos de fallo no son intuitivos. El fallo de disco es solo un tipo de pérdida de datos.
Los sistemas modernos pierden datos por software, humanos y atacantes más a menudo que por un disco soltando su cereza SMART.
1) Borrado y sobrescritura son instantáneamente redundantes
Borra un directorio. RAID refleja el borrado. Sobrescribe una tabla. RAID distribuye esa nueva verdad por todo el conjunto. No hay “deshacer” porque el trabajo de RAID
es mantener las copias consistentes, no históricas.
2) Corrupción silenciosa, bit rot y la trampa de “todo parece bien”
Discos, controladoras, cables y firmware pueden devolver datos erróneos sin lanzar un error. Sistemas de archivos con checksums (como ZFS, btrfs) pueden
detectar corrupción y, con redundancia, a menudo autocurarse. RAID tradicional bajo un sistema de archivos que no suma checksums a nivel de bloque
puede devolver bloques corruptos y llamarlo éxito.
Incluso con checksums de extremo a extremo, aún puedes corromper datos a un nivel superior: escrituras de aplicación erróneas, compactación defectuosa, migraciones medio aplicadas.
RAID preservará la corrupción perfectamente.
3) Al ransomware no le importa tu paridad
El ransomware cifra lo que puede acceder. Si puede acceder a tu sistema de archivos montado, puede cifrar tus datos en RAID1, RAID10, RAID6,
espejos ZFS, o lo que sea. La redundancia no detiene el cifrado. Solo asegura que el cifrado esté altamente disponible.
4) Fallos de controladora y firmware se llevan el arreglo con ellos
El hardware RAID añade un dominio de fallo: la controladora, su módulo de caché, su firmware, su batería/supercap y su formato de metadatos.
Si la controladora muere, puede que necesites un modelo idéntico de controladora y el mismo nivel de firmware para ensamblar el arreglo limpiamente.
El RAID por software también tiene dominios de fallo (kernel, md metadata, herramientas en espacio de usuario), pero tienden a ser más transparentes y portables.
Transparente no significa seguro. Solo significa que puedes ver el cuchillo antes de pisarlo.
5) Las reconstrucciones son estresantes y empeoran a medida que los discos crecen
La reconstrucción es donde las matemáticas se encuentran con la física. Durante la reconstrucción, cada disco restante se lee intensamente, a menudo cerca del ancho de banda completo, durante horas o días.
Esa es una tormenta perfecta para sacar a la luz errores latentes en los discos restantes. Si pierdes otro disco en un RAID5 durante la reconstrucción, pierdes el arreglo.
RAID6 te da más margen, pero la reconstrucción sigue aumentando el riesgo y degradando el rendimiento.
6) Error humano: el modo de fallo más común y menos respetado
Un ingeniero cansado reemplaza el disco equivocado, saca la bandeja equivocada o ejecuta el comando correcto en el host equivocado. RAID no protege contra
humanos. Los amplifica. Un clic equivocado se replica a línea de velocidad.
7) Desastres en sitio y radio de impacto
RAID es local. El fuego también es local. También lo son el robo, los eventos de energía y “ups borramos toda la cuenta en la nube”. Una verdadera estrategia de backup asume
que perderás un dominio de fallo entero: un host, un rack, una región o una cuenta.
Datos interesantes y un poco de historia (la útil)
Algunos hechos concretos hacen que este tema cale porque muestran cómo RAID terminó siendo tratado como un hechizo mágico.
Aquí hay nueve, todas relevantes, ninguna romántica.
- RAID fue nombrado y popularizado en un artículo de UC Berkeley de 1987 que planteaba “redundant arrays of inexpensive disks” como alternativa a discos grandes y caros.
- El marketing temprano de RAID insistía en “tolerancia a fallos”, y mucha gente silenciosamente lo tradujo a “protección de datos,” que no es el mismo contrato.
- Los niveles de RAID nunca fueron un estándar único oficial. Los proveedores implementaron “RAID5” con comportamientos y políticas de caché diferentes, y luego discutían sobre semántica en tu ventana de incidencia.
- Las controladoras RAID de hardware históricamente usaban formatos de metadatos propietarios en disco, por eso el fallo de la controladora puede convertirse en arqueología.
- El auge de discos multi-terabyte hizo que las reconstrucciones de RAID5 fueran dramáticamente más arriesgadas porque el tiempo de reconstrucción creció y la probabilidad de encontrar un sector ilegible durante la reconstrucción aumentó.
- Las tasas URE (unrecoverable read error) se discutieron mucho en los 2000s como una razón práctica para preferir doble paridad en arreglos grandes, especialmente bajo carga de reconstrucción intensa.
- ZFS (lanzado por primera vez a mediados de los 2000s) introdujo checksums de extremo a extremo en operaciones mainstream y convirtió “bit rot” en una frase comprensible para la dirección porque finalmente podía detectarse.
- Las snapshots se volvieron comunes en el almacenamiento empresarial en los 1990s pero a menudo se almacenaban en el mismo arreglo—rollback rápido, no recuperación ante desastres.
- El ransomware cambió la conversación de “cinta vs disco” a “inmutabilidad vs credenciales”, porque los atacantes aprendieron a borrar backups primero.
Tres mini-historias corporativas desde las trincheras
Mini-historia 1: El incidente causado por una suposición equivocada
Una compañía SaaS mediana ejecutaba su clúster PostgreSQL principal en un par de servidores de gama alta con hardware RAID10. El pitch del proveedor sonaba
reconfortante: discos redundantes, caché de escritura con batería, repuestos calientes. El equipo oyó “sin pérdida de datos” y mentalmente archivó los backups como “agradables de tener”.
Una tarde, un desarrollador ejecutó un script de limpieza contra producción. Se suponía que debía apuntar a un esquema de staging; apuntó al en vivo.
En segundos, se borraron millones de filas. La base de datos siguió atendiendo tráfico, y los gráficos de monitorización parecían bien—las consultas eran más rápidas, de hecho,
porque había menos datos.
Intentaron recuperar usando la “snapshot” de la controladora RAID, que no era una snapshot en el sentido del sistema de archivos. Era un perfil de configuración
para el comportamiento de caché. El proveedor de almacenamiento, para su crédito, no se rió. Simplemente hizo la pregunta que acaba carreras:
“¿Cuáles son sus últimos backups conocidos buenos?”
No había ninguno. Había un volcado lógico nocturno configurado meses atrás, pero escribía al mismo volumen RAID, y el script de limpieza borró también el directorio del volcado.
La compañía reconstruyó a partir de logs de aplicación y flujos de eventos de terceros. Recuperaron la mayoría, pero no todo, y pasaron semanas arreglando daños referenciales sutiles.
La suposición equivocada no fue “RAID es seguro.” Fue “la disponibilidad implica recuperabilidad.” Tenían alta disponibilidad y poca verdad.
Mini-historia 2: La optimización que se volvió en su contra
Una plataforma de medios estaba obsesionada con el rendimiento. Movieron los metadatos de su almacenamiento de objetos desde una configuración conservadora a un ancho RAID5
para exprimir más capacidad usable y mejor rendimiento de escritura en papel. También activaron un caching agresivo en la controladora para mejorar las tasas de ingestión.
En operación normal, se veía bien. Las profundidades de cola eran bajas. La latencia bajó. La dirección obtuvo su diapositiva de “eficiencia de almacenamiento” para el informe trimestral.
Todos durmieron mejor durante aproximadamente un mes.
Entonces un único disco empezó a lanzar errores de lectura intermitentes. El arreglo lo marcó como “falla predictiva” pero lo mantuvo en línea. Se inició una reconstrucción
a un repuesto caliente durante horas pico porque el sistema era “redundante”. Esa reconstrucción saturó los discos restantes. La latencia se disparó, los timeouts subieron,
y los reintentos de la aplicación crearon un bucle de realimentación.
A mitad de la reconstrucción, otro disco encontró un sector ilegible. RAID5 no puede manejar eso durante la reconstrucción. La controladora declaró que el disco virtual falló.
El resultado no fue solo tiempo de inactividad. Fue corrupción parcial de metadatos que hizo la recuperación más lenta y desagradable que un crash limpio.
La optimización no fue malvada; fue sin límites. Optimizaron por capacidad y rendimiento de benchmark, y pagaron por ello con riesgo de reconstrucción y un mayor radio de impacto.
Reemplazaron el diseño por doble paridad, movieron las ventanas de reconstrucción fuera de pico y—lo más importante—construyeron una canalización de backups fuera del arreglo
para que la próxima falla fuera aburrida.
Mini-historia 3: La práctica aburrida pero correcta que salvó el día
Una firma de servicios financieros operaba un servicio de archivos usado por equipos internos. El almacenamiento era un conjunto espejo ZFS: simple, conservador, poco emocionante.
La parte emocionante fue su higiene de backups: snapshots nocturnas, replicación fuera de sitio a un dominio administrativo distinto y pruebas de restauración mensuales.
Todos se quejaban de las pruebas de restauración porque “eran pérdida de tiempo”. El gerente de SRE las hizo no opcionales de todos modos.
El portátil de un contratista fue comprometido. El atacante obtuvo acceso VPN y luego una credencial privilegiada que podía escribir en el recurso compartido de archivos.
Durante la noche, ransomware empezó a cifrar directorios de usuarios. Como el share estaba en línea y era escribible, el cifrado se propagó rápido.
ZFS hizo exactamente lo que se le pidió: almacenó los nuevos bloques cifrados con integridad. El espejo RAID aseguró que el cifrado fuera durable.
A la mañana siguiente, los usuarios encontraron sus archivos renombrados e ilegibles. El espejo estaba “saludable”. El negocio no lo estaba.
La firma desconectó el recurso compartido de red, rotó credenciales y verificó el objetivo de backup inmutable. Los backups estaban almacenados en un entorno separado
con permisos restringidos de eliminación y bloqueos de retención. El atacante no pudo tocarlos.
La restauración no fue mágica; fue practicada. Restauraron primero los directorios más críticos según una lista de prioridad preacordada, luego el resto
durante el día siguiente. El postmortem fue aburrido en el mejor sentido. La moraleja también fue aburrida: procesos rutinarios vencen a la redundancia sofisticada.
Guía de diagnóstico rápido: encuentra el cuello de botella y el radio de impacto
Cuando algo anda mal con el almacenamiento, los equipos pierden tiempo discutiendo si es “los discos” o “la red” o “la base de datos”.
El enfoque correcto es establecer: (1) qué cambió, (2) qué está lento, (3) qué es inseguro, y (4) en qué aún puedes confiar.
Primero: deja de empeorarlo
- Si sospechas corrupción o ransomware, congela las escrituras donde puedas: remonta en solo lectura, detén servicios, revoca credenciales.
- Si un arreglo está degradado y reconstruyendo, considera reducir la carga para evitar una segunda falla durante la reconstrucción.
- Inicia un registro de incidente: comandos ejecutados, marcas temporales, cambios realizados. La memoria no es evidencia.
Segundo: identifica si esto es rendimiento, integridad o disponibilidad
- Rendimiento: alta latencia, timeouts, profundidad de colas, iowait. Los datos pueden seguir siendo correctos.
- Integridad: errores de checksum, corrupción a nivel de aplicación, cambios inesperados en archivos. El rendimiento puede verse bien.
- Disponibilidad: dispositivos faltantes, arreglos degradados/fallidos, sistemas de archivos que no montan. El sistema está gritando.
Tercero: localiza el dominio de fallo rápidamente
- Host: logs del kernel, errores de disco, estado de la controladora.
- Pila de almacenamiento: RAID/mdadm/ZFS, salud del sistema de archivos, estado de scrub.
- Ruta IO: multipath, HBA, expander SAS, NICs, switches si es almacenamiento en red.
- Aplicación: planes de consulta, contención de locks, tormentas de reintentos.
- Postura de backup/recuperación: ¿tienes un punto de restauración limpio y alcanzable?
Cuarto: decide el objetivo
En una caída, debes elegir un objetivo para liderar:
- Mantenerlo en ejecución (disponibilidad): estabilizar, aceptar modo degradado.
- Proteger los datos (integridad): congelar escrituras, tomar copias forenses, restaurar desde un conocido bueno.
- Recuperar el servicio (recuperabilidad): conmutar, reconstruir en otro lugar, restaurar backups.
Estos objetivos entran en conflicto. Fingir que no es cómo terminas con un sistema funcionando que sirve datos incorrectos.
Tareas prácticas con comandos: qué ejecutar, qué significa, qué decidir
A continuación hay tareas prácticas que puedes ejecutar en sistemas Linux para entender tu postura de redundancia y tu real recuperabilidad.
Cada tarea incluye: comando, salida de ejemplo, qué significa y la decisión que tomas a partir de ello.
Tarea 1: Comprueba los dispositivos de bloque actuales y membresía RAID
cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,MODEL,SERIAL
NAME SIZE TYPE FSTYPE MOUNTPOINT MODEL SERIAL
sda 3.6T disk HGST_HUS726T4TAL K8H1ABCD
├─sda1 512M part vfat /boot/efi
└─sda2 3.6T part
sdb 3.6T disk HGST_HUS726T4TAL K8H1EFGH
└─sdb1 3.6T part
md0 3.6T raid1 ext4 /data
Qué significa: Tienes un dispositivo RAID1 de software md0 montado en /data, construido a partir de particiones.
Decisión: Si pensabas que tenías “backups”, no es así. Esto es solo redundancia. Confirma que la ubicación del backup está separada.
Tarea 2: Inspecciona salud de mdadm y estado de reconstrucción
cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb1[1] sda2[0]
3906886464 blocks super 1.2 [2/2] [UU]
unused devices: <none>
Qué significa: [UU] indica que ambos miembros están arriba. Durante la reconstrucción verías [U_] y una línea de progreso.
Decisión: Si está degradado, reduce la carga y planifica el reemplazo de disco. Además: toma un snapshot de backup ahora si no tienes uno fuera del host.
Tarea 3: Obtén información detallada de mdadm, incluyendo contadores de eventos
cr0x@server:~$ sudo mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Mon Oct 2 11:22:09 2023
Raid Level : raid1
Array Size : 3906886464 (3726.02 GiB 4000.79 GB)
Used Dev Size : 3906886464 (3726.02 GiB 4000.79 GB)
Raid Devices : 2
Total Devices : 2
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Name : server:0
UUID : 1a2b3c4d:5e6f:7890:abcd:ef0123456789
Events : 12891
Number Major Minor RaidDevice State
0 8 2 0 active sync /dev/sda2
1 8 17 1 active sync /dev/sdb1
Qué significa: “clean” es bueno, pero no dice nada sobre si los archivos son correctos, consistentes o restaurables.
Decisión: Usa esto para confirmar topología e identificar qué disco físico corresponde a qué miembro antes de tocar el hardware.
Tarea 4: Revisa logs del kernel para errores de IO y resets
cr0x@server:~$ sudo journalctl -k -S "1 hour ago" | egrep -i "ata|sas|scsi|i/o error|reset|timeout" | tail -n 8
Jan 22 10:11:41 server kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Jan 22 10:11:41 server kernel: ata3.00: failed command: READ DMA EXT
Jan 22 10:11:41 server kernel: blk_update_request: I/O error, dev sdb, sector 9175040 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jan 22 10:11:42 server kernel: ata3: hard resetting link
Jan 22 10:11:47 server kernel: ata3: link is slow to respond, please be patient
Jan 22 10:11:52 server kernel: ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Qué significa: Resets de enlace y errores de IO son señales tempranas. Podría ser disco, cable, backplane o controladora.
Decisión: Trátalo como “integridad en riesgo”. Inicia un backup fresco si es posible; planifica mantenimiento y aislamiento de hardware.
Tarea 5: Consulta SMART y contadores clave
cr0x@server:~$ sudo smartctl -a /dev/sdb | egrep -i "SMART overall|Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|Power_On_Hours"
SMART overall-health self-assessment test result: PASSED
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 12
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 2
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 2
9 Power_On_Hours 0x0032 089 089 000 Old_age Always - 41231
Qué significa: “PASSED” no es tranquilidad. Sectores pendientes/offline-uncorrectable importan más. Este disco está deteriorándose.
Decisión: Reemplaza proactivamente. Si estás en RAID5/6, el riesgo de reconstrucción aumenta; programa la reconstrucción con carga reducida y backups verificados.
Tarea 6: Para hardware RAID, revisa estado de controladora/disco virtual (ejemplo storcli)
cr0x@server:~$ sudo storcli /c0/vall show
Controller = 0
Status = Success
Description = Show Virtual Drives
DG/VD TYPE State Access Consist Cache Cac sCC Size Name
0/0 RAID5 dgrd RW No RWBD - OFF 10.913 TB data_vd0
Qué significa: El disco virtual está dgrd (degradado). “Consist No” sugiere que se necesita una verificación de consistencia.
Decisión: Pausa escrituras no esenciales, identifica discos fallados/predictivos y asegúrate de tener un backup restaurable antes de reconstruir.
Tarea 7: Confirma la política de caché de escritura y el estado de batería/supercap
cr0x@server:~$ sudo storcli /c0 show battery
Controller = 0
Status = Success
Description = Battery Status
BatteryType = iBBU
Status = Failed
Replacement required = Yes
Qué significa: Si la protección de caché falla, las controladoras a menudo desactivan la caché write-back o arriesgan perder escrituras reconocidas si hay corte de energía.
Decisión: Espera cambios de rendimiento y posible riesgo de integridad si la política está mal configurada. Reemplaza la batería/supercap y revisa el modo de caché.
Tarea 8: Mide si estás limitado por CPU o por IO (iostat)
cr0x@server:~$ iostat -xz 1 3
Linux 6.1.0 (server) 01/22/2026 _x86_64_ (16 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
12.34 0.00 5.12 31.45 0.00 51.09
Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s w_await aqu-sz %util
md0 85.0 5420.0 0.0 0.0 18.20 63.76 40.0 3120.0 44.10 2.90 98.7
Qué significa: Alto %iowait y %util cercano a 100% indican cuello de botella en IO. La latencia de escritura es alta.
Decisión: Limita trabajos pesados, revisa si hay reconstrucción/scrub, y considera mover carga caliente fuera del arreglo mientras estabilizas.
Tarea 9: Encuentra qué procesos están golpeando el IO (iotop)
cr0x@server:~$ sudo iotop -oPa -n 5
Total DISK READ: 55.43 M/s | Total DISK WRITE: 12.10 M/s
PID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
18422 be/4 postgres 40.22 M/s 8.10 M/s 0.00 % 92.00 % postgres: checkpointer
27109 be/4 root 12.11 M/s 0.00 B/s 0.00 % 15.00 % rsync -aH --delete /data/ /mnt/backup/
Qué significa: Tu trabajo de backup y mantenimiento de base de datos están compitiendo. No es una fábula moral; es física.
Decisión: Reprograma backups/ventanas de mantenimiento o aplica limitación de velocidad para que los backups no causen incidentes (o al revés).
Tarea 10: Revisa errores del sistema de archivos rápidamente (ejemplo ext4)
cr0x@server:~$ sudo dmesg | egrep -i "EXT4-fs error|I/O error|Buffer I/O error" | tail -n 6
[915230.112233] EXT4-fs error (device md0): ext4_find_entry:1531: inode #524301: comm nginx: reading directory lblock 0
[915230.112240] Buffer I/O error on device md0, logical block 12345678
Qué significa: El sistema de archivos está viendo errores de lectura. RAID puede estar enmascarando algunos fallos, pero no todos.
Decisión: Detén servicios si es posible, captura logs, y planifica un fsck controlado (o una restauración) en lugar de dejar que la corrupción se propague.
Tarea 11: Verifica salud del pool ZFS y contadores de error
cr0x@server:~$ sudo zpool status -v
pool: tank
state: DEGRADED
status: One or more devices has experienced an unrecoverable error.
action: Replace the faulted device, or use 'zpool clear' to mark the device repaired.
scan: scrub repaired 0B in 00:42:18 with 0 errors on Sun Jan 18 02:15:01 2026
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
sdc FAULTED 0 0 8 too many errors
sdd ONLINE 0 0 0
errors: Permanent errors have been detected in the following files:
tank/data/app.db
Qué significa: ZFS detectó errores de checksum y puede decirte qué archivo está afectado. Esta es la diferencia entre “creer” y “saber”.
Decisión: Trata los archivos nombrados como sospechosos. Restaura los datos afectados desde backup o replicación a nivel de aplicación; reemplaza el disco fallado.
Tarea 12: Comprueba snapshots ZFS y si los estás confundiendo con backups
cr0x@server:~$ sudo zfs list -t snapshot -o name,creation -s creation | tail -n 5
tank/data@hourly-2026-01-22-0600 Thu Jan 22 06:00 2026
tank/data@hourly-2026-01-22-0700 Thu Jan 22 07:00 2026
tank/data@hourly-2026-01-22-0800 Thu Jan 22 08:00 2026
tank/data@hourly-2026-01-22-0900 Thu Jan 22 09:00 2026
tank/data@hourly-2026-01-22-1000 Thu Jan 22 10:00 2026
Qué significa: Bien. Pero si estas snapshots viven en el mismo pool, no sobrevivirán a la pérdida del pool, compromiso de cuenta o fallo del sitio.
Decisión: Replica snapshots a un destino independiente con credenciales diferentes y protecciones de eliminación.
Tarea 13: Confirma que existen los backups y son recientes (ejemplo restic)
cr0x@server:~$ restic -r /mnt/backup/restic-repo snapshots --last
repository 9b2f1c12 opened (version 2, compression level auto)
ID Time Host Tags Paths
a1b2c3d4 2026-01-22 09:00:14 server /data
Qué significa: Tienes una snapshot de backup de hoy. Eso es un comienzo.
Decisión: Valida la capacidad de restauración, no solo la existencia. Si las snapshots dejan de actualizarse, trátalo como incidente.
Tarea 14: Haz una restauración de prueba de un solo archivo para demostrar recuperabilidad
cr0x@server:~$ mkdir -p /tmp/restore-test && restic -r /mnt/backup/restic-repo restore latest --target /tmp/restore-test --include /data/important/report.csv
repository 9b2f1c12 opened (version 2, compression level auto)
restoring <Snapshot a1b2c3d4 of [/data] at 2026-01-22 09:00:14 by cr0x@server> to /tmp/restore-test
Summary: Restored 1 files/dirs (42.133 KiB) in 0:00
Qué significa: Este es el momento en que “tenemos backups” se convierte en un hecho. Restauraste exitosamente un archivo real.
Decisión: Haz de esto un ejercicio programado con selección aleatoria de archivos y resultados documentados.
Tarea 15: Comprueba si tu destino de “backup” es realmente independiente
cr0x@server:~$ mount | egrep "/data|/mnt/backup"
/dev/md0 on /data type ext4 (rw,relatime)
server:/export/backup on /mnt/backup type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2)
Qué significa: Los backups van a NFS. La independencia depende de dónde viva ese NFS y quién pueda eliminarlo.
Decisión: Si NFS está en el mismo servidor, mismo rack o con el mismo conjunto de credenciales administrativas, no es lo bastante independiente. Soluciona eso.
Tarea 16: Verifica retención e inmutabilidad en el nivel de sistema de archivos (chattr)
cr0x@server:~$ sudo lsattr -d /mnt/backup
-------------e---- /mnt/backup
Qué significa: No hay flags de inmutabilidad aquí. Puede estar bien, pero entonces la inmutabilidad debe venir del sistema de backup o del objetivo de almacenamiento.
Decisión: Si el ransomware está en tu modelo de amenaza (lo está), implementa bloqueos de retención/inmutabilidad fuera del alcance administrativo primario.
Tarea 17: Comprueba si estás a un typo de borrar los backups (permisos)
cr0x@server:~$ namei -l /mnt/backup/restic-repo | tail -n 4
drwxr-xr-x root root /mnt
drwxr-xr-x root root /mnt/backup
drwxrwxrwx root root /mnt/backup/restic-repo
Qué significa: Repositorio de backup escribible por todos. Eso no es un backup; es un proyecto de arte comunitario.
Decisión: Restringe permisos, separa credenciales de backup y considera objetivos solo-apendibles o inmutables.
Tarea 18: Detecta una reconstrucción o scrub que esté matando el rendimiento silenciosamente
cr0x@server:~$ sudo zpool iostat -v 1 3
capacity operations bandwidth
pool alloc free read write read write
-------------------------- ----- ----- ----- ----- ----- -----
tank 2.10T 1.40T 820 210 92.1M 18.2M
mirror-0 2.10T 1.40T 820 210 92.1M 18.2M
sdc - - 420 105 46.0M 9.1M
sdd - - 400 105 46.1M 9.1M
-------------------------- ----- ----- ----- ----- ----- -----
Qué significa: Lecturas sostenidas altas pueden indicar scrub/resilver o un cambio de carga. Necesitas correlacionar con estado del pool y trabajos cron.
Decisión: Si esto coincide con dolor de usuarios, reprograma scrubs, ajusta prioridad de resilver o añade capacidad/margen de rendimiento.
Broma #2: Una reconstrucción RAID es el equivalente en almacenamiento de “solo un cambio rápido en producción.” Nunca es rápido, y definitivamente cambia las cosas.
Errores comunes: síntomas → causa raíz → solución
Esta sección es intencionalmente específica. El consejo genérico no sobrevive a un incidente; solo termina citado en el postmortem.
1) “El arreglo está saludable, pero los archivos están corruptos”
- Síntomas: Errores de aplicación al leer archivos específicos; desajustes de checksum a nivel de app; usuarios ven medios dañados; RAID muestra óptimo.
- Causa raíz: Corrupción silenciosa en disco/controladora/cable, o la aplicación escribió malos datos. La paridad/espejado de RAID lo preservó.
- Solución: Usa un sistema de archivos con checksums (ZFS) o checksums en la aplicación; ejecuta scrubs; restaura objetos corruptos desde backups independientes; reemplaza hardware defectuoso.
2) “No podemos reconstruir: segundo disco falló durante la reconstrucción”
- Síntomas: Disco virtual RAID5 falla a mitad de reconstrucción; aparecen UREs; múltiples discos muestran errores de medios.
- Causa raíz: Paridad simple más discos grandes más carga de lectura intensa durante reconstrucción; margen insuficiente para errores de sector latentes.
- Solución: Prefiere RAID6/RAIDZ2 o espejos para arreglos grandes; mantén repuestos calientes; ejecuta lecturas de patrulla/scrubs; reemplaza discos proactivamente; asegúrate de tener backups restaurables antes de reconstruir.
3) “Los backups existen pero las restauraciones son demasiado lentas para cumplir el RTO”
- Síntomas: El job de backup reporta éxito; la restauración tarda días; el negocio necesita horas.
- Causa raíz: No se ingenió el RTO; ancho de banda al target de backup insuficiente; demasiados datos, poca priorización; no hay plan de restauración por niveles.
- Solución: Define RTO/RPO por dataset; implementa recuperación local rápida (snapshots) más backups fuera de sitio; pre-posiciona datasets críticos; practica restauraciones parciales.
4) “Las snapshots nos salvaron… hasta que el pool murió”
- Síntomas: Horario de snapshots confiable; luego pérdida catastrófica del pool; snapshots desaparecen con él.
- Causa raíz: Snapshots almacenadas en el mismo dominio de fallo que los datos primarios.
- Solución: Replica snapshots a un sistema/cuenta diferente; añade inmutabilidad; trata “mismo host” como “mismo radio de impacto.”
5) “Ransomware cifró producción y backups”
- Síntomas: Repositorio de backup borrado/cifrado; retención purgada; credenciales usadas legítimamente.
- Causa raíz: Sistema de backup escribible/borrable con las mismas credenciales comprometidas en producción; sin inmutabilidad/air gap.
- Solución: Separa credenciales y activa MFA; roles de backup solo-escribir; bloqueo de objetos inmutables o destinos append-only; copia offline para el peor caso; monitoriza eventos de eliminación.
6) “El rendimiento colapsó después de reemplazar un disco”
- Síntomas: Picos de latencia después del reemplazo; sistemas hacen timeouts; nada más cambió.
- Causa raíz: Rebuild/resilver saturando IO; controladora limitando; modo degradado en arreglos de paridad.
- Solución: Agenda ventanas de reconstrucción; limita la velocidad de rebuild; mueve cargas; añade discos/SSDs; mantén margen extra; no reconstruyas en pico a menos que disfrutes del caos.
7) “La controladora murió y no podemos importar el arreglo”
- Síntomas: Los discos aparecen pero los metadatos del arreglo no se reconocen; la herramienta del proveedor no ve el disco virtual.
- Causa raíz: Metadatos de hardware RAID ligados a familia/firmware de la controladora; fallo del módulo de caché; confusión por configuración extranjera.
- Solución: Estandariza controladoras y mantén repuestos; exporta configuraciones de controladora; prefiere almacenamiento definido por software para portabilidad; y lo más importante, ten backups que no requieran que la controladora exista.
Listas de verificación / plan paso a paso: construye backups que sobrevivan a la realidad
Aquí está el plan que funciona cuando estás cansado, con poco personal y aún se espera que aciertes.
Es opinado porque la producción es opinada.
Paso 1: Clasifica los datos por consecuencia para el negocio
- Tier 0: autenticación/identidad, facturación, datos de clientes, base de datos central.
- Tier 1: herramientas internas, analítica, logs necesarios para seguridad/forense.
- Tier 2: caches, artefactos de build, datasets reproducibles.
Si todo es “crítico”, nada lo es. Define RPO y RTO por tier. Escríbelo donde finanzas puedan verlo.
Paso 2: Elige la regla base y luego supérala
La regla clásica es 3-2-1: tres copias de los datos, en dos medios/tipos diferentes, con una copia fuera de sitio. Es un punto de partida, no una medalla.
Para ransomware, “fuera de sitio” también debe significar “no eliminable con las mismas credenciales”.
Paso 3: Separa los dominios de fallo a propósito
- Hardware distinto: no “un directorio distinto”.
- Límite administrativo distinto: cuentas/roles separadas; producción no debe tener permiso de borrar en backups.
- Geografía distinta: al menos una copia fuera del sitio/rack/región que puedas perder.
Paso 4: Usa snapshots para velocidad, backups para supervivencia
Las snapshots locales son para recuperaciones rápidas de “ups”: borrados accidentales, despliegues malos, rollback rápido. Mantenlas frecuentes y con retención corta.
Los backups son para cuando la máquina, el arreglo o la cuenta han desaparecido.
Paso 5: Encripta y autentica la canalización de backup
- Encripta en reposo y en tránsito (y maneja las claves como si importaran, porque importan).
- Usa credenciales dedicadas de backup con permisos mínimos.
- Prefiere rutas solo-escritura desde producción hacia backup cuando sea posible.
Paso 6: Haz de la retención una política, no una vibra
- Corto: horario/diario para rollback rápido.
- Medio: semanal/mensual para necesidades legales/empresariales.
- Largo: trimestral/anual si es requerido, almacenado barato e inmutable.
Paso 7: Prueba restauraciones como si importara
El backup más caro es el que nunca restauras hasta el día que lo necesitas. Las pruebas de restauración deben programarse, registrarse y tener dueño.
Rota responsabilidades para que el conocimiento no viva en la cabeza de una sola persona.
Paso 8: Monitoriza las cosas correctas
- Frescura del backup: hora de la última snapshot exitosa por dataset.
- Integridad del backup: verificación periódica o restauración de prueba.
- Eventos de eliminación: alertas por eliminaciones inusuales de backups.
- Salud del almacenamiento: SMART, estado RAID, errores ZFS, resultados de scrub.
Paso 9: Ejecuta un tabletop para los escenarios feos
Practica:
- Borrado accidental (restaurar un directorio).
- Ransomware (asume que el atacante tiene admin de producción).
- Fallo de controladora (asume que el arreglo primario es irrecuperable).
- Pérdida del sitio (asume que todo el rack/región se perdió).
Paso 10: Decide para qué sirve el RAID (y deja de pedirle que sea un respaldo)
Usa RAID/espejos/codificación por borrado para cumplir objetivos de disponibilidad y rendimiento. Usa backups para cumplir objetivos de recuperabilidad.
Si la elección de RAID está impulsada por “no necesitamos backups,” estás haciendo arquitectura con pensamiento deseoso.
Una cita para tener sobre tu monitor
Parafraseando la idea: La esperanza no es una estrategia.
— General Jim Mattis (citada a menudo en círculos de ingeniería y operaciones)
Si estás construyendo almacenamiento sobre esperanza, no estás construyendo almacenamiento. Estás construyendo un informe de incidente futuro con mucho tiempo de preparación.
FAQ
1) Si tengo RAID1, ¿todavía necesito backups?
Sí. RAID1 protege contra la falla de un disco. No protege contra borrado, corrupción, ransomware, bugs de controladora o pérdida del sitio.
RAID1 hace que el sistema siga en funcionamiento mientras ocurre lo equivocado.
2) ¿Las snapshots son un backup?
No automáticamente. Las snapshots son referencias en un punto en el tiempo, usualmente almacenadas en el mismo sistema. Se vuelven “parecidas a backups” solo cuando se replican
a un destino independiente con una retención que no puedas eliminar casualmente.
3) ¿Es RAID6 “suficientemente seguro” para saltarse los backups?
No. RAID6 reduce la posibilidad de pérdida del arreglo por fallos de discos durante la reconstrucción. No hace nada por fallos lógicos (borrar, sobrescribir),
malware o eventos catastróficos. Los backups existen porque el fallo de disco no es la única amenaza.
4) ¿Y el almacenamiento en la nube con redundancia: cuenta como respaldo?
La redundancia del proveedor cloud suele tratar la durabilidad de los objetos almacenados, no tu capacidad de recuperarte de tus propios errores.
Si borras o sobrescribes, la cloud lo hará de forma fiable. Aún necesitas versionado, bloqueos de retención y copias independientes.
5) ¿Cuál es el plan mínimo viable de backups para una empresa pequeña?
Empieza con: backups diarios a un destino independiente, al menos 30 días de retención y una copia fuera de sitio. Añade retención semanal/mensual según sea necesario.
Luego programa pruebas de restauración. Si solo haces una cosa “avanzada”, haz las pruebas de restauración.
6) ¿Con qué frecuencia deberíamos probar restauraciones?
Para sistemas críticos, mensualmente es una línea base razonable, con restauraciones parciales más frecuentes (semanal es excelente).
Después de cambios grandes—nuevo almacenamiento, nuevas claves de cifrado, nueva herramienta de backup—prueba inmediatamente.
7) ¿Cuál es la diferencia entre replicación y backup?
La replicación copia datos a otro lugar, a menudo en casi tiempo real. Eso es excelente para alta disponibilidad y bajo RPO, pero puede replicar cambios malos instantáneamente.
Los backups son versionados y retenidos para que puedas volver a antes del fallo. Muchos entornos usan ambos.
8) ¿Cómo protejo los backups del ransomware?
Separa credenciales y restringe la eliminación. Usa inmutabilidad/bloqueos de retención en el objetivo de backup. Mantén al menos una copia offline o en un dominio administrativo separado.
Monitoriza borrados sospechosos y deshabilita el acceso al repositorio de backup desde hosts de uso general.
9) ¿ZFS elimina la necesidad de backups?
ZFS mejora la integridad con checksums y autocuración (con redundancia), y las snapshots son excelentes para rollback rápido.
Pero ZFS no te impide borrar datos, cifrarlos o perder todo el pool. Aún necesitas backups independientes.
10) ¿Qué RPO/RTO deberíamos elegir?
Elige en función del dolor del negocio, no de lo que el equipo de almacenamiento desea que sea verdad. Para datos Tier 0, RPO de minutos/horas y RTO de horas podrían ser necesarios.
Para tiers inferiores, días pueden ser aceptables. La clave es que los números deben estar diseñados e probados, no declarados.
Próximos pasos que puedes hacer esta semana
RAID es una herramienta para mantenerse en línea ante ciertos fallos de hardware. No es una máquina del tiempo. No es un testigo de tribunal. No le importa
si los datos son correctos; le importa si los bits son consistentes entre discos.
Si gestionas sistemas de producción, haz estos pasos esta semana:
- Inventaría tu almacenamiento: nivel RAID, tipo de controladora, edades de discos y comportamiento de reconstrucción.
- Escribe RPO/RTO para tus tres datasets principales. Si no puedes, no tienes un plan de backups—tienes un plan de esperanza.
- Verifica independencia: confirma que los backups viven fuera del dominio de fallo primario y fuera de credenciales que se borran fácilmente.
- Ejecuta una prueba de restauración: un archivo, un directorio y (si te atreves) una restauración de base de datos a un entorno de prueba.
- Configura alertas para frescura de backups y anomalías de eliminación, no solo para salud de discos.
Luego, y solo entonces, disfruta tu RAID. Es útil cuando lo tratas con honestidad: como redundancia, no como salvación.