CompExcell

Introducción a la recuperación de información

Posibilidades de recuperación en Novell Netware

La recuperación de información es el trabajo que consiste en leer y copiar a un medio seguro información que se hizo inaccesible al usuario por medios convencionales. Esto puede ser por desperfectos en el funcionamiento del medio de almacenamiento o por problemas en el sistema de archivos o ambos.

Ante todo, la tarea de recuperación de información radica en poder leer el medio, que puede tratarse de un disco rígido u otra forma de almacenamiento tales como cintas, DATs, diskettes, discos ópticos, etc. En general esta es la tarea más compleja: poder hacer lo que se llama una recuperación ASCII o bit a bit de la información original. En discos que han dejado de ser reconocidos por sus controladoras o por los motherboards, hay que aplicar un entendimiento profundo de las tecnologías de almacenamiento para efectuar una reparación temporaria de la unidad que contenía la información. Decimos temporaria debido a que realizar una reparación permanente es algo más difícil y costoso y lo que se busca en la tarea de recuperación de información no es dejar operativo un disco sino lograr al menos una lectura buena de los datos de un medio que luego será dado de baja.

Las fallas en discos pueden deberse a una multitud de causas: fallos inherentes en los componentes electrónicos o bien introducidos por descargas electrostáticas externas, etc. o bien fallas electromecánicas por stress mecánico de las piezas, heterogeneidades en los medios, stiction (static friction), etc. etc.

En algunas ocasiones los usuarios tienen su medio de almacenamiento en perfecto estado de funcionamiento de hardware pero no pueden acceder a la información porque faltan o son inconsistentes las estructuras administrativas del sistema operativo que permiten ubicar físicamente los archivos en diferentes zonas del disco. En estos casos lo que hay que hacer es ante todo un relevamiento, de qué impide al sistema operativo, tener acceso al sistema de archivos. Se realiza una comprobación de qué estructuras sufrieron daños, cuáles están presentes y son confiables y cuáles pueden necesitar ser reescritas o reprogramadas.

Hay que destacar que muchas veces cuando se realiza una reparación temporaria de un disco, luego no se obtiene un file system «limpio», sino también hay que reinterpretarlo, sobre todo cuando hay daños en los medios y quedan zonas sin poder recuperarse.

La recuperabilidad de los sistemas Novell Netware

Por lo dicho más arriba, queda claro que para encarar esta tarea, entre otras cosas, hay que tener capacidad de efectuar intervenciones de tipo electrónicas y electromecánicas en las unidades de almacenamiento. Esto es igual para cualquier sistema operativo. Se trata de una etapa sintáctica, en donde lo que cuenta es el ordenamiento (taxos=orden, en griego) de los componentes mínimos (sectores, clusters, bloques, etc.) sin hacer interpretación de ningún tipo. En esta etapa no importa si un string determinado es un directorio, parte de un archivo o cualquier otra estructura.

Llamamos parte semántica a la segunda instancia, en que se interpreta qué es cada cosa de acuerdo a un tipo de file system de un sistema operativo concreto.

En el caso de Novell Netware los file systems se dividen en dos grandes grupos: los sistemas hasta la versión 2.2 y los sistemas desde la versión 3.11 hasta las actuales 4.x. Estos dos tipos de sistemas son totalmente diferentes y nadie podría confundirlos observando un disco a bajo nivel (con un editor de sectores físicos o con debug) una instalación digamos 2.12 con una 3.12. Debido a que quedan pocas instalaciones con Novell 2.x no nos extenderemos aquí en descripciones técnicas pero digamos que se trata de un sistema bastante confiable por un lado y poco eficiente por otro si lo comparamos con las versiones 3.x y 4.x Generalmente los problemas con estos sistemas se deben a degradaciones de archivos de arranque, que una vez repuestos o bypasseados permiten acceder a la estructura de archivos. Inclusive con daños en directorios es un sistema que suele tener buenas tasas de recuperación.

Con respecto a los sistemas 3.x y 4.x podemos decir que se trata del mismo sistema con sutiles diferencias. Si uno ve a bajo nivel un disco formateado en versión 3.x y otro en 4.x encontrará diferencias bastantes evidentes. Tenemos que pensar que entre la liberación de uno y otro sistema pasaron varios años y con ellos hubo un gran crecimiento en el promedio de capacidad de los discos de los servers. Las diferencias se verán en que las instalaciones típicas de una versión 3.11 o 3.12 tienen un tamaño de bloque de 4 KB, en tanto que para la versión 4.x el default para volúmenes de más de 500 MB es de 64 KB (esto es modificable en la instalación con las correspondientes consecuencias en performance y desperdicio). Esto, como el lector estará imaginando, va a implicar que vamos a encontrar FATs estructuralmente similares pero de tamaños totalmente disímiles. (Algo análogo ocurriría si se comparase un disco formateado con el file system FAT16 que usa DOS, Windows 3.X y 95 con el de FAT32 que usa Windows 95 release 2 y Windows 98).

Si mucha gente se estaba lamentando del problema del desperdicio que traía el sistema de FAT 16 con tamaños de clusters de 32KB para una partición de entre 1 y 2 GB, ahora ¿qué tendríamos que decir de un tamaño de bloque de 64KB? Pero los diseñadores del sistema operativo Netware 4 implementaron una solución de compromiso entre desperdicio y performance: por un lado favorecieron un tamaño de bloque grande, pero por otro incorporaron una estructura adicional en donde se registra dónde se ubican segmentos de información que no llegan a ocupar un bloque entero. La presencia de esta estructura llamada subasignación de bloque es la opción por defecto pero se puede desactivar durante la instalación. Si se desinstala tendremos mayor seguridad y performance pero mayor desperdicio. Los problemas que acosan a los diseñadores de file systems son siempre los mismos: desperdicio, performance, seguridad, recuperabilidad. Los veteranos en Unix recordarán que la versión Berkeley implementaba ya una reubicación de bloques parcialmente ocupados muy parecida conceptualmente a la de Netware 4.x.

La estructura de subasignación de bloque es muy importante, al punto que su ausencia torna casi irrecuperable un volumen Netware (por más que tengamos buenas copias de FATs y directorios) debido a que allí estará la clave para recuperar cualquier archivo de menos de 64 KB y los fragmentos finales de los archivos que excedan múltiplo de 64 KB. (Esto mismo vale si se tomó tamaño de bloque 32 o 16 KB). Las unidades en esta estructura son de 512 B.

La regla general para cualquier sistema operativo con respecto al tema de seguridad es que en cuantas menos estructuras administrativas críticas existan, mejor, o en otras palabras: en cuantas menos cosas haya que se puedan romper en un file system, más segura estará la información. Esta prestación no existe en NetWare 3, de modo que estadísticamente hay más chances de recuperar más cantidad de archivos buenos en una instalación 3.x que en una 4.x

Cada volumen tiene sus propias copias de FATs, DETs, subasignación, etc. De modo que los daños en un volumen no deben alterar la información de otros volúmenes. Estadísticamente se comprueba que el volumen que más sufre daños es el primero, el SYS. Por lo tanto es recomendable generar otros volúmenes para datos de modo que en caso de que el primer volumen tenga desperfectos nos queden copias limpias de directorios, Fats, etc. del volumen más importante.

Asimismo, si debe agregar capacidad a un volumen tenga en cuenta que si agrega un disco al mismo volumen, la información de ambos discos va a depender de un solo juego de directorios y no podrá levantar información si falta (o se rompe) alguno de los discos que integraban este volumen. En estos casos la tarea de recuperación consiste, en primera instancia en obtener una copia completa, bit a bit del disco que tuvo desperfectos y rearmar la instalación como estaba originalmente. En caso que la recuperación bit a bit no sea completa, o que luego de ella encontremos errores lógicos habrá que trabajar con las estructuras de ambos discos. Generalmente estos problemas se encaran generando un disco único auxiliar con partes que se levantan de uno y otro disco.

No podemos extendernos en esta ocasión sobre los RAIDs pero la forma de encarar estas instalaciones es similar. A partir de la información que proporciona el usuario, a veces incompleta o dudosa, y de la información que se levanta a bajo nivel de los discos, se determina qué tipo de RAID era, el tamaño del stripe y otras variables necesarias para iniciar el rearmado de los archivos. Hay muchas tareas de ingeniería reversa que se aplican pero esto tiene que ver no sólo con el conocimiento de las tecnologías sino también con mucha experiencia, intuición y experimentación. A veces instalar un RAID similar al que estamos intentando reconstruir puede permitir comprobar empíricamente si el camino tomado es el correcto.

Por último recordemos que desde la versión 4.x, se instala también por default la opción de cargar automáticamente el Vrepair.nlm en caso de que en el arranque se hallen inconsistencias. El Vrepair es un utilitario cuyo objetivo principal es lograr un volumen que se pueda montar, más allá de que en el camino se pueda perder información o se puedan actualizar erróneamente FATs dejando archivos sin referencia. Aconsejamos desactivar esta opción para que sea el administrador quien decida si corresponde correr Vrepair o no y cuándo. La opción más conservadora sería nunca correr este NLM a menos que no haya información importante sin respaldo o sea realmente la últimaalternativa.