La pérdida de datos en una empresa no siempre se produce cuando un servidor deja de funcionar. Un sistema RAID puede seguir operativo aunque uno de sus discos haya fallado. Un disco duro puede mostrar síntomas de deterioro mientras permite acceder a parte de la información. Y una máquina virtual puede continuar funcionando durante meses con snapshots antiguas que comprometen su recuperación ante un incidente.
En estas situaciones, que el sistema siga funcionando no significa que los datos estén a salvo.
Un fallo físico en un disco, una reconstrucción RAID realizada sin comprobar el estado de las demás unidades, una copia de seguridad que no puede restaurarse o una cadena de snapshots dañada pueden terminar convirtiendo una incidencia de almacenamiento en un problema de pérdida de información.
Cuando esto ocurre, recuperar los datos puede exigir algo más que sustituir un componente o volver a poner en marcha el servidor. Puede ser necesario intervenir sobre los discos, reconstruir la estructura RAID o recuperar la información de sistemas de virtualización.
Por eso, prevenir la pérdida de datos requiere conocer los riesgos que afectan a los dispositivos de almacenamiento y saber cómo actuar ante los primeros síntomas de fallo.
A continuación, repasamos siete aspectos que pueden ayudar a proteger la información y reducir las posibilidades de necesitar una recuperación de datos.
1. No confiar toda la protección de los datos al RAID
Un sistema RAID permite combinar varios discos para mejorar el rendimiento, la disponibilidad o la tolerancia a determinados fallos, dependiendo del nivel utilizado.
Sin embargo, RAID no equivale a una copia de seguridad. Ni la sustituye.
Un RAID 5, por ejemplo, puede continuar funcionando cuando falla uno de sus discos. Pero esa tolerancia tiene un límite: si se produce un segundo fallo antes de recuperar la redundancia, el volumen queda inaccesible. Puedes consultar la documentación de Seagate sobre el funcionamiento y los estados de los arrays RAID.
Además, la redundancia no protege frente a otros incidentes, como borrados accidentales, corrupción de archivos, ransomware o errores humanos que se replican en el propio almacenamiento.
Por eso, el RAID debe formar parte de una estrategia de protección más amplia, no sustituirla.
2. Supervisar el estado de los discos y las alertas de la controladora
La monitorización del almacenamiento permite detectar señales que pueden anticipar un problema.
Es importante revisar periódicamente:
- El estado de cada disco y las alertas de la controladora RAID.
- Los errores de lectura y escritura.
- Los sectores pendientes o reasignados, cuando la tecnología del disco proporciona esa información.
- Los registros de eventos del servidor.
- Los cambios anormales en el rendimiento.
- La temperatura de funcionamiento de las unidades.
Las herramientas SMART pueden aportar información útil sobre el estado de los discos, pero no garantizan que un dispositivo vaya a funcionar correctamente ni permiten descartar todos los fallos físicos.
Una alerta debe investigarse, no limitarse a comprobar si el servidor continúa funcionando.
3. No ignorar la lentitud o los errores de rendimiento
Un servidor que empieza a responder con lentitud, presenta bloqueos o registra errores de entrada y salida puede estar mostrando síntomas de un problema de almacenamiento.
En un sistema RAID, estos síntomas merecen especial atención, especialmente si coinciden con alertas de discos o cambios en el estado del array.
Ante una degradación anormal, no conviene asumir que se trata de un problema de rendimiento sin importancia. Tampoco es recomendable iniciar automáticamente un proceso de reconstrucción (rebuild) sin conocer el estado de los discos supervivientes.
Un rebuild implica una carga de lectura y escritura sobre el conjunto de discos. Si alguno de los miembros restantes presenta problemas físicos, esa operación puede complicar la situación. Muchas pérdidas de datos se producen en el proceso de rebuild por el fallo de otra de las unidades.
Si el RAID presenta síntomas anormales y existe la sospecha de un fallo físico, lo prudente es detener las operaciones y solicitar un diagnóstico especializado antes de intervenir. La actuación concreta dependerá del estado del sistema y de la información disponible.
4. Mantener una política de copias de seguridad y comprobar las restauraciones
Disponer de copias de seguridad no es suficiente si no se comprueba que pueden restaurarse.
Una estrategia de backup debe definir, entre otros aspectos:
- Qué sistemas y datos se copian.
- Con qué frecuencia se realizan las copias.
- Cuánto tiempo se conservan.
- Dónde se almacenan.
- Quién puede acceder a ellas.
- Cuánto tiempo se tardaría en recuperar el servicio.
También es importante mantener copias separadas de la infraestructura principal y protegerlas frente a borrados, errores de configuración y ataques que puedan afectar al entorno de producción.
Las pruebas de restauración permiten comprobar que los archivos están disponibles y que las aplicaciones pueden volver a funcionar. Una copia que nunca se ha restaurado sigue siendo una recuperación pendiente de validar.
5. Controlar las snapshots en los entornos virtualizados
Las snapshots de máquinas virtuales son útiles para conservar temporalmente un estado y facilitar determinadas operaciones, como una actualización o un cambio de configuración.
Pero no deben utilizarse como sustituto de las copias de seguridad.
En VMware vSphere, una snapshot registra los cambios realizados sobre el disco virtual desde el momento en que se crea. Si permanece activa durante mucho tiempo, los archivos delta pueden crecer y afectar al rendimiento y a las operaciones de consolidación.
Broadcom recomienda no mantener una snapshot individual durante más de 72 horas y eliminarla una vez que ha cumplido su función, siguiendo el procedimiento adecuado. Puedes consultar también su documentación sobre el funcionamiento de las snapshots en VMware vSphere.
Por tanto, conviene revisar periódicamente:
- Las snapshots existentes en cada máquina virtual.
- Su antigüedad y tamaño.
- Las cadenas de snapshots y sus dependencias.
- Las alertas de consolidación pendiente.
- La correcta eliminación de las snapshots creadas por el software de backup.
Una snapshot olvidada durante meses puede convertirse en un riesgo para la disponibilidad y la recuperación de una máquina virtual.
6. Vigilar la temperatura, la ventilación y la alimentación eléctrica
Las condiciones físicas del entorno también influyen en la fiabilidad del almacenamiento.
Una temperatura de funcionamiento fuera de las especificaciones del fabricante, una ventilación insuficiente o la acumulación de polvo pueden afectar a los componentes del servidor. La fiabilidad de las unidades y sus condiciones de funcionamiento deben valorarse siempre teniendo en cuenta las especificaciones del fabricante. Seagate ofrece información técnica sobre fiabilidad de los discos duros y factores relacionados con su funcionamiento.
Por eso, es recomendable:
- Comprobar que el sistema de refrigeración funciona correctamente.
- Mantener despejadas las entradas y salidas de aire.
- Supervisar las temperaturas de discos y componentes.
- Revisar los avisos térmicos del servidor.
- Mantener el entorno dentro de los rangos especificados por los fabricantes.
La alimentación eléctrica también merece atención. Los cortes de suministro y las fluctuaciones pueden provocar apagados inesperados, interrumpir operaciones de escritura y dejar sistemas en estados inconsistentes.
Un SAI correctamente dimensionado y configurado, junto con un procedimiento de apagado controlado, ayuda a reducir este riesgo. No elimina todos los posibles fallos, pero añade una capa de protección importante.
7. Definir un procedimiento de actuación ante un fallo
Cuando aparece una alerta de disco, un RAID se degrada o un servidor empieza a presentar errores, las decisiones que se toman durante los primeros minutos pueden influir en las posibilidades de recuperación.
Es importante que el equipo IT tenga definido un procedimiento que contemple:
- Cómo identificar y registrar los síntomas.
- Qué información consultar antes de intervenir.
- Cuándo detener el sistema.
- Qué operaciones deben evitarse si existe sospecha de fallo físico.
- A quién escalar el incidente.
- Cómo preservar los discos y los datos originales.
No todos los fallos requieren la misma respuesta. Sustituir un disco y reconstruir un RAID puede ser el procedimiento adecuado cuando el resto de unidades está en buen estado. Pero si existen indicios de que otros discos también están deteriorados, iniciar el rebuild sin un diagnóstico previo puede aumentar el riesgo.
En estos casos, conviene valorar la intervención de un laboratorio especializado antes de realizar operaciones que modifiquen el estado del almacenamiento.
La prevención empieza antes del fallo
Un RAID, un sistema de backup y una plataforma de virtualización cumplen funciones diferentes. Ninguno de ellos, por separado, garantiza que una empresa pueda recuperar toda su información después de un incidente.
La protección real depende de cómo se combinan: discos supervisados, copias independientes y verificadas, snapshots controladas, condiciones ambientales adecuadas y procedimientos de actuación bien definidos.
El caso de las seis máquinas virtuales recuperadas por SERMAN tras el fallo de un RAID 5 muestra por qué es necesario revisar tanto la capa física del almacenamiento como la estructura lógica de los datos. La recuperación no terminó al reconstruir el RAID: también fue necesario recuperar la coherencia de las snapshots y reconstruir las cadenas de discos virtuales.
Cuando la información de una empresa está comprometida, seguir trabajando sobre un sistema inestable o realizar pruebas sin un diagnóstico previo puede reducir las posibilidades de recuperación.
Si tu servidor o sistema RAID presenta errores, lentitud anormal o ha dejado de ser accesible, evita realizar nuevas intervenciones sin conocer el estado de los discos. En SERMAN analizamos sistemas RAID, servidores y entornos de almacenamiento para determinar las posibilidades de recuperación de datos.
Consulta nuestro servicio de recuperación de datos en sistemas RAID.