Recuperación de datos en SAN para empresas en Panamá

¿Qué es la recuperación de datos de una SAN?

Una SAN (red de área de almacenamiento) es la columna vertebral de almacenamiento de muchos centros de datos: concentra los discos en cabinas y los entrega como volúmenes lógicos a los servidores que los necesitan. Cuando algo falla en ese entramado, no cae un disco, cae el almacenamiento del que dependen decenas de servicios a la vez. Recuperar una SAN es devolver el acceso a esos volúmenes y a los datos que contienen, sorteando las varias capas de abstracción que separan al usuario de los bits en el disco.

La buena noticia, igual que en virtualización, es que la mayoría de los incidentes son lógicos —no hardware muerto, sino estructuras o configuración rotas— y, sobre discos sanos, muy recuperables. La mala es que las SAN son entornos a medida y apilados, donde una acción apresurada se propaga a muchas máquinas. Por eso el diagnóstico ordenado importa aún más que en un disco suelto.

SAN no es NAS: bloque contra archivo

La primera distinción que ordena todo lo demás es esta: una SAN trabaja a nivel de bloque y un NAS a nivel de archivo. Un NAS comparte carpetas por la red con protocolos de archivo; una SAN entrega volúmenes en crudo —LUNs— que el servidor ve como si fueran discos locales, y encima de ellos pone su propio sistema de archivos, su datastore de virtualización o su base de datos. Esa diferencia cambia la recuperación: en un NAS se trabaja sobre un sistema de archivos; en una SAN, primero hay que reconstruir el bloque y el LUN, y solo después aparece el sistema de archivos del huésped. Es una capa más de profundidad, y exige herramientas y criterio distintos de los de la recuperación de NAS.

El LUN: una capa lógica sobre el RAID

El concepto central de una SAN es el LUN, y entenderlo explica casi todos los casos. Un LUN no es un disco físico: es una construcción lógica que la controladora presenta sobre un volumen RAID o un pool de almacenamiento. Cuando se borra un LUN desde la consola de gestión, el sistema borra su tabla de asignación y sus metadatos, pero los bloques de datos en los discos no se ponen a cero: quedan huérfanos, marcados como reutilizables, no destruidos. De ahí que un LUN borrado por error sea, en arreglos de disco, muy recuperable si nadie escribió encima todavía. La recuperación consiste en reconstruir el RAID que está debajo y, sobre él, rehacer el mapeo del LUN para volver a encontrar los datos; es la recuperación de RAID más una capa adicional de traducción.

¿Por qué muchos «fallos de SAN» no son discos muertos?

Porque la SAN es, ante todo, una red, y las redes fallan por configuración tanto como por hardware. El caso más ilustrativo es el «Dark LUN»: el volumen está perfectamente sano, pero un cambio de zoning —el mecanismo que decide qué servidor puede ver qué almacenamiento— deja al host sin verlo, y parece una pérdida de datos cuando en realidad es una pérdida de acceso. Algo parecido ocurre con un multipathing mal resuelto, con un script de orquestación mal tecleado que propaga un cambio a decenas de switches en segundos, o con una controladora que entra en failover repetido y deja sus metadatos inconsistentes. El error humano, de hecho, es la causa más común de fallo en almacenamiento empresarial. Distinguir un problema de configuración de uno de datos cambia por completo la solución, y por eso el diagnóstico empieza por descartar la capa lógica antes de sospechar de los discos.

Síntomas de que una SAN va camino al fallo

Una SAN rara vez cae de golpe sin avisar; suele dar señales que conviene no ignorar, porque atenderlas a tiempo evita el incidente grande. Entre las más habituales:

• Pérdida de acceso a volúmenes o LUNs, o cambios de capacidad disponible que nadie explica.
• Rebuilds de RAID repetidos o que no llegan a terminar.
• Resets o failover frecuentes de una controladora.
• Errores CRC y caídas de enlace recurrentes entre la cabina y los servidores.
• Snapshots, backups o replicación que fallan sin causa aparente.
• Varios discos en estado de fallo predictivo, o hot spares que se activan una y otra vez.

Cuando aparecen varias de estas señales juntas, lo prudente es no esperar al fallo total: un diagnóstico temprano, con la cabina aún en pie, suele permitir recuperar sin parar la operación y con muchas menos pérdidas.

Fibre Channel, iSCSI y la fragilidad del fabric

La «red» de una SAN es tan crítica como sus discos, y falla con su propia lógica. El fabric conecta los servidores con la cabina mediante adaptadores (HBA), switches y transceptores, por Fibre Channel o iSCSI, y cada uno de esos eslabones puede romper el acceso sin que un solo bit de datos se pierda. Con enlaces de 100 o 200 Gb, el propio cable de fibra es sensible: una micro-curvatura —un pliegue diminuto— provoca suficiente pérdida de luz para disparar miles de errores CRC, y los transceptores, sometidos a mucho calor, también fallan. El resultado se parece a una pérdida de datos —un LUN que desaparece, un servidor que no monta su almacenamiento—, pero la causa está en la conectividad, no en el dato. Por eso, ante una SAN caída, parte del diagnóstico es del lado del fabric: confirmar si el problema es de acceso o de datos antes de decidir cómo recuperar.

LUN borrado: thin, thick y el reloj del all-flash

No todos los LUN borrados se recuperan con la misma facilidad, y la diferencia está en cómo se aprovisionaron. Un LUN thick-provisioned reservó su espacio completo y contiguo al crearse, así que tras borrarlo sus bloques son predecibles y difíciles de pisar de inmediato: buenas probabilidades. Un LUN thin-provisioned, en cambio, asignaba bloques bajo demanda y, al borrarlo, los devuelve al pool de inmediato, donde cualquier escritura de otro LUN puede reclamarlos; recuperarlo exige reconstruir el bitmap de aprovisionamiento a partir de metadatos residuales. Y hay un caso con cronómetro: en cabinas all-flash con reclamación de espacio (UNMAP/TRIM), la controladora puede ordenar a los SSD borrar físicamente los bloques liberados poco después de eliminar el LUN. En esos sistemas, apagar la cabina de inmediato no es una recomendación más: es lo que separa un caso recuperable de uno perdido.

¿Se puede recuperar un LUN borrado o formateado?

Sí, y con buenas probabilidades, si se actúa con cabeza. La consigna es la de siempre, intensificada por la escala: sacar el almacenamiento de línea cuanto antes para que ninguna escritura nueva ocupe los bloques que se quieren rescatar, y no reinicializar ni reformatear el LUN «para volver a empezar», porque eso borra justo el mapa de metadatos que permite reconstruirlo. A partir de ahí, la recuperación es metódica: imagen de todos los discos, reconstrucción del arreglo y del mapeo del LUN, y extracción en solo lectura. Lo que no conviene es experimentar sobre la cabina de producción; cada intento a ciegas en un entorno de alta densidad puede convertir un problema acotado en una pérdida de petabytes.

Cabinas propietarias: Nimble, 3PAR y compañía

Las SAN empresariales rara vez son genéricas. Cabinas como HPE Nimble (con su algoritmo Triple+ RAID), Dell, NetApp, 3PAR, IBM Storwize o Hitachi, y sistemas como BeyondRAID, guardan su geometría y sus metadatos en formatos propietarios, y añaden capas de deduplicación, thin provisioning y snapshots entre los discos y el dato del usuario. Eso hace que las herramientas genéricas de recuperación se queden cortas: no saben leer esas estructuras. La recuperación pasa por imaginar todos los discos y luego interpretar el formato propietario concreto —la tabla de asignación de paquetes, los descriptores de volumen virtual— para reconstruir cómo se distribuyen los datos por la cabina. Es trabajo de ingeniería específico por arquitectura, no de apretar un botón.

Cuando un rebuild colapsa el arreglo

Hay un escenario clásico que sigue causando estragos. Cuando un disco de un grupo RAID falla, la cabina inicia un rebuild para reconstruir la redundancia sobre un disco de repuesto. El problema es el tamaño: con discos de varios terabytes, ese rebuild tarda horas o días y somete a los demás discos a un estrés de lectura intenso. Si en esa ventana un segundo disco —a menudo del mismo lote de fabricación, y por tanto con una edad y un desgaste parecidos— también cae, el grupo RAID colapsa más allá de su tolerancia a fallos, y lo que era un disco averiado se convierte en una pérdida total que exige reconstrucción profesional. Por eso, ante un rebuild largo en una cabina con discos viejos, la decisión más segura no siempre es dejar que termine: a veces conviene imaginar todos los discos antes, para tener una copia íntegra por si el rebuild precipita el segundo fallo. Esa previsión es justo lo que distingue una recuperación con red de seguridad de una apuesta a que el arreglo aguante.

Las SAN serias mitigan este riesgo con niveles de doble paridad o multinivel —RAID 6, 50 o 60—, que toleran más de un fallo simultáneo; pero ni eso es infinito, y un mantenimiento que ignora un disco en fallo predictivo va agotando el margen sin que nadie lo note. La lección operativa es doble. Por un lado, vigilar el estado de cada disco y no postergar el reemplazo de los que dan señales, porque cada disco degradado que sigue en producción acerca el día del colapso. Por otro, entender que la redundancia de la cabina protege de fallos de hardware, pero no de un borrado lógico ni de un error de configuración, que se propagan por encima de la paridad y dejan intacto el problema. Cuando el margen se agota, la reconstrucción profesional sobre imágenes es lo que recupera el grupo entero sin arriesgar lo que todavía queda sano.

Nuestro proceso de recuperación de SAN

El método respeta la regla de oro del laboratorio, llevada a la escala de una cabina: nunca se toca el original, se reconstruye todo de forma virtual sobre imágenes, y se va de la capa física a la lógica en orden.

1. Sacar el almacenamiento de línea

Detenemos la actividad y, en cabinas all-flash, apagamos de inmediato para que la reclamación de espacio no borre los bloques liberados.

2. Imagen de todos los discos

Clonamos sector a sector cada disco del grupo —incluidos los hot spares— con bloqueo de escritura, sin tocar las unidades originales.

3. Reconstruir el arreglo

Reconstruimos virtualmente el RAID y el pool: orden de discos, parámetros, stripe, paridad y ajustes de la controladora.

4. Reconstruir el mapeo del LUN

Rehacemos los metadatos y el mapeo del LUN para volver a localizar los datos dentro del pool reconstruido.

5. Montar y extraer

Montamos el LUN en solo lectura y extraemos los archivos, datastores VMFS o bases de datos, con verificación de integridad.

# ¿Discos o capa lógica?
Discos (16): SANOS                    # no era el hardware
Zoning del fabric: LUN 7 NO presentado al host   # "Dark LUN"
Controladora: failover repetido, metadatos del pool inconsistentes
LUN 7 (thin): tabla de asignación BORRADA -> bloques en el pool

# Plan, en este orden:
  1) Sacar de línea / apagar la cabina YA (all-flash: UNMAP corre)
  2) Imagen sector a sector de los 16 discos (solo lectura)
  3) Reconstruir RAID + pool + mapeo del LUN (orden, stripe, paridad)
  4) Montar LUN 7 en solo lectura -> extraer datastores / BD

Ese registro resume el criterio: primero se separa lo lógico de lo físico, se actúa contra el reloj en all-flash, y se reconstruye de abajo hacia arriba sin escribir nunca sobre los discos originales.

¿Qué no debes hacer con una SAN caída?

En un entorno donde una acción afecta a muchas máquinas, los errores se multiplican. Conviene evitar:

• No reinicialices ni reformatees el LUN ni recrees el volumen: borra el mapa que permite recuperarlo.
• No reconstruyas el RAID group a ciegas ni dejes que la cabina haga un rebuild antes de imaginar los discos.
• No sigas escribiendo en el pool afectado; en all-flash, apaga cuanto antes por la reclamación de espacio.
• No improvises con scripts sobre el fabric: un cambio mal tecleado se propaga a muchos switches en segundos.
• No descartes la configuración: antes de culpar a los discos, revisa zoning y multipathing.

SAN, RAID, servidor y máquinas virtuales: dónde encaja cada uno

Como estas recuperaciones se solapan, vale la pena situarlas. La diferencia está en qué capa es el protagonista del incidente:

En la práctica, un mismo incidente puede tocar varias capas —una SAN que sirve un datastore VMFS con máquinas dentro—, y por eso el diagnóstico empieza por ubicar dónde nació el problema y trabaja desde ahí hacia arriba.

¿Cuánto cuesta y cuánto tarda recuperar una SAN?

Depende del número de discos, del nivel RAID, de si la cabina es propietaria y de si el fallo es lógico o hay daño físico. Un LUN borrado sobre discos sanos puede resolverse relativamente rápido; una cabina propietaria con varios discos caídos y metadatos a reconstruir lleva más. Por eso primero diagnosticamos —con imágenes, sin tocar el original— y entonces fijamos por escrito el alcance y el precio antes de empezar. Para una caída que detiene la operación, la línea de emergencia 24/7 arranca de inmediato. No damos cifras «desde» sin evaluar, porque en almacenamiento empresarial el caso cambia por completo según la arquitectura y la causa.

La forma de no repetirlo: respaldo y réplica

Toda recuperación de SAN termina en la misma conversación de continuidad: una cabina, por redundante que sea, no es un respaldo. Los snapshots y la replicación dentro de la propia SAN protegen de muchos fallos, pero no del borrado lógico que se replica al instante ni de un ransomware que cifra el pool entero. La defensa real combina copias fuera de la cabina y de la red, idealmente inmutables, y pruebas de restauración que confirmen el RPO y el RTO que el negocio necesita. Por eso ligamos esta recuperación con el respaldo de NAS, RAID y SAN y, cuando el fallo es lógico y la cabina responde, con la recuperación remota que evita enviar el equipo.

Preguntas frecuentes