Mi historial de desastres

En casi 12 años de trabajar en IT en Uruguay me he enfrentado a situaciones de desastres informáticos. Datos perdidos, discos rotos, correos borrados y un montón de situaciones dignas de ser recordadas por dos razones:

1) Reirse

2) Aprender

Así que aquí va la lista casi cronológica de los desastres en los que me vi envuelto y cómo se sorteó el asunto. Ténganse en cuenta que la gran mayoría no fueron responsabilidad mía, pero si que yo era el que podía resolverlo… o el que tenía que resolverlo.

1) Un tipo llegó a MarketPlace con su Aptiva P-23 y nos solicitó que le arreglaramos un problema. No recuerdo si era virus o qué. Como era el procedimiento, tuvimos que formatear el disco y recuperar el software. Respaldamos los datos, recuperamos y volvimos a poner los datos.

El tipo no quedó contento porque le habíamos borrado los programas que tenía instalados. A lo cual le pedimos los discos y no los tenía… ¿Por qué? ¡Porque eran truchos!

Alegó mil razones pero había una realidad. Nosotros no podíamos ser cómplices de piratería. Armó tanto revuelo que el disco llegó a IBM, donde obviamente no pudieron hacer nada.

2) Con mi flamante Prodigia 166 MMX, instalar Windows 95 era cosa de casi todos los días. Recuerdo el febrero del ’98 en que con los problemas que acarreaba el nuevo FAT-32, terminé rompiendo las particiones y formateando el disco completo. Perdí todos los datos que tenía en mi PC.

3) Daniel me mandó a un banco con un script. Corría el año 1999 ó 2000. Fui, corrí el script en un servidor de base de datos con SQL 6.5 y me dió un error. Volví a correrlo y me dió otro error. Lo llamé para preguntarle que hacer.

“¿Cómo que tu script borra los datos de la base de datos de origen sin escribirlos en la de destino?” -le dije.

Moraleja: cuando muevas cosas de un lado al otro, cópialas, y luego de verificada la copia, la borras.

4) Un cliente compró un servidor en USA por e-bay y me dijo: “instalalo y ponele un Exchange”. Le dije: “necesitamos una unidad de cinta para hacer respaldos. Sale 986 dólares”.

El tipo me dijo que era mucha plata y que con el RAID 1 por hardware andaba bien.

A fines de Julio de 2001, el servidor en un corte de energía perdió uno de los discos, pero el RAID no funcionó. Con un esfuerzo titánico, pude recuperar parte de la base de Exchange de 600 Mb. Era cuando los discos tenían 2 a 4 GB de espacio y siempre estaban llenos.

Espero que hayan aprendido a gastar 1000 dólares en una unidad de cinta. Yo aprendí un montón sobre como está organizada la base de Exchange 2000.

5) Un mes antes, en la misma empresa un técnico de sonido necesitaba agregar una placa de red a un servidor Netfinity 9000. En vez de llamar a IBM o de dejarme hacerlo a mi, prefirió a las 8 de la noche hacerlo él mismo.

Entró al datacenter, intentó sacarle la tapa superior al servidor que se encontraba sobre una base de madera, y al no poder, tiró más fuerte. Terminó corriendo el servidor entero 10 centímetros para adelante lo cual dejó tirante los cables de corrientes de la fuente principal y redundante, de forma que se soltaron.

Se perdieron 2 discos de los 9.

Adiós RAID 5.

El técnico de IBM (casualmente Leonel), pudo recuperar el servidor porque en esa placa RAID de IBM tenía configurado un disco adicional para redundancia (Ahora no recuerdo el nombre de dicha tecnología, pero creo que es Hot Spare o algo así).

Lección aprendida: no dejes que nadie toque tus servidores, por más prepotente que sea.

Lección aprendida 2: las fuentes redundantes de IBM no sirven de nada si los cables se sueltan con facilidad en un mismo movimiento horizontal.

6) En una empresa, el dueño tenía una PC en su casa… prendida hacía 4 años! La máquina tenía virus y me la mandó para que se lo sacara y le reinstalara el software.

El asistente del director fue hasta la casa, la apagó, la metió en la camioneta, me la llevó y cuando la prendí, el disco estaba hecho crema.

¿La razón? Los discos IDE no soportan ese uso tan intensivo. Pero nadie se da cuenta que eso es así y que la durabilidad está dada por las condiciones ambientales y otras cosas más.

Intenté hacer algo con el disco, pero de Arnaldo Castro nos ofrecieron su servicio de reparación certificado por Ontrack. U$S 25 para el ingreso a servicio técnico. Al otro día me llaman de AC y me dicen que el disco no pudieron recuperarle nada y que tenían que mandarlo a Ontrack en EEUU. Que eso podía salir algunos miles de dólares, dependiendo de la cantidad de información que se recuperase. Creo que era un Wester Digital de 8 GB.

Les dije que no, llamé a Diego y le dije: Tengo un disco para recuperar. ¿Podés?

Al otro día vuelve Diego con un disco nuevo y el disco viejo. 100% de efectividad por (creo) U$S 200 y un disco nuevo.

¿Herramienta utilizada?: OnTrack Easy Recovery Professional y el congelador de la heladera.

Nunca entendí por qué AC no lo recuperó con la misma herramienta que usó Diego ;-)

7) Misma empresa anterior, 2004. Problemas de espacio en disco. El servidor de correo no tenía más espacio físico para agregarle discos, nadie se decidía a comprar un nuevo servidor y el espacio empezó a desaparecer exponencialmente. Exchange 2000 otra vez.

Se necesitaba urgentemente más espacio para realizar la defragmentación de la base de Exchange y como no entraban más discos en el servidor, vacié la partición D y me dispuse a agrandar la partición.

El disco estaba en modo dinámico y la herramienta de reparticionamiento terminó perdiendo todas las particiones. No había RAID ni nada. Si había backup.

¿Solución? Disco de 120 Gb y otra vez Easy Recovery Professional. Esta vez lo hice yo porque eran las 11 de la mañana. A las 15:00 hs estaba el servidor de correo nuevamente funcionando.

El costo en tiempo fueron 5 horas sin correo y el nombre de los contactos en las carpetas públicas. Pobre la recepcionista que tuvo que ponerle nuevamente el nombre a cada uno de los contactos compartidos. Del disco pude recuperar la base de datos priv.ebd, pero no la pub.ebd, así que esa la recuperé desde las cintas.

Moraleja: cuanto menos espacio quede, más rápido desaparecerá.

Lección aprendida: mover todo a un servidor espejo y trabajar en él.

8) Me llama Héctor urgente que un servidor NT4 viejísimo no levantaba. Era un Alpha de Digital! Había costado U$S 16.000 en 1996 y aun en 2004 estaba funcionando.

Llegé un poco tarde, cuando el técnico de “la competencia” ya estaba trabajando, así que me quedé hablando con Héctor y tomando café hasta que el técnico se rindió y se fué.

El mensaje de error era el clásico de “no se encuentra ntoskrnl.ddl o ntdll”. Le pedí a Hector una PC con Windows 200o y el CD de NT4. Formatié un disquette, le copié los archivos que necesita un NT para Alpha para bootear y armé a mano el boot.ini.

Problema resuelto. Hasta el día de la migración, el servidor siguió booteando desde disquette.

Nota: ahora dudo de si ese era el Alpha… pero le da más gustito a la historia :-)

9) Daniel hizo una actualización a una aplicación de gestión. Un error en un script SQL hizo que se borraran datos. Cómo no había realizado respaldo previo al script según solicitaba el PR241921, tuvo que recurrir al backup más reciente.

Un problema de espacio en el servidor de bases de datos de nuestro proveedor de servicios de infraestructura, donde se alojaba la base de datos, hizo que solo se pudiera recuperar una versión de más de una semana atrás, y no la del día anterior.

No pude hacer nada. Sólo pedirle disculpas a los involucrados y postergar indefinidamente una acción de calidad que para mi no tenía sentido. Seguramente porque no logré entender para qué sirve ingresar una acción de calidad cuando un problema se sucede por un error humano que podría conocerse como “simple olvido”.

10) Era unverano muy caluroso. El servidor de archivos comenzaba a fallar porque la temperatura del Data Center, sin aire acondicionado, rondaba los 30 grados. El aire sobre las placas madre seguramente estaba por encima de los 50 y los procesadores rondaban los 80 grados.

Una falla generalizada de servicios obligó a reiniciar el servidor. Nunca más levantó.

Comenzamos por sacarlo del rack y llevarlo a otro lado. Lo abrimos y limpiamos con pincel y aspiradora. Sacamos todos los discos del RAID y los volvimos a colocar uno a uno, luego de limpiarlos cuidadosamente.

Los discos del RAID fallaban aleatoriamente. Entre reinicio y reinicio no lográbamos hacer que prendieran todos juntos.

Por fin llegó el técnico del proveedor de infraestructura y se llevó el servidor. Tardaron más de una semana en devolverlo. Los datos eran recuperables, pero vaya a saber por qué, demoraban y demoraban y demoraban.

No quise usar el recurso del backup, porque de los 2 tipos de datos que se guardaban en ese servidor, uno era un repositorio de código fuente con el cual se podría sobrevivir por cortos períodos de tiempo y el otro eran datos históricos que rara vez se utilizaban.

La unidad de cinta estaba en el servidor roto, y eso nos devolvía a que nuestro proveedor realizara la recuperación de las cintas. Elegí que terminara de recuperar el sistema de archivos vivo que sería lo más eficiente.

Una vez recuperados los datos desde el RAID y copiados en un disco SATA, armé el nuevo servidor de archivos virtualizado.

Si no fuera por la situación de desastre, la virtualziación del servicio de Sitema de Archivos corporativo se hubiera visto demorada durante meses debido a que “no se podía” prescindir de él.

Lección confirmada: la calidad ambiental del data center es vital, así como la limpieza interna de los servidores.

Lección aprendida: no hay mejor momento que un desastre como para reorganizar algo que parece imposible de reorganizar.

Conclusión

Estas son solo algunas historias de desastres. Debo tener más de desastres menores que no recuerdo. Pero sin duda que con el tiempo me he vuelto un experto en resolver desastres. Y com o decía ayer: ojalá los que toman las decisiones financieras en las empresas entiendan la importancia de tener un buen sistema de respaldos.