Cómo cargarse unos años-persona de trabajo en décimas de segundo
Hola
Hace unos días me llegó un testimonio de uno de vosotros, que supongo prefiere permanecer en el anonimato y que no tiene desperdicio. Al margen de demostrar una templanza y recursos envidiables para resolver finalmente la situación de forma satisfactoria, me viene al pelo para recordar tres viejas buenas prácticas que deberían ser elevadas a la categoría de dogma:
1.- NO uses Snapshots en producción. Una Snapshot NO es un método apropiado de backup
2.- NO uses discos de crecimiento dinámico ni diferenciales para cosas importantes.
3.- NO desprecies el engorroso trabajo de hacer backups. NUNCA realices operaciones de mantenimiento en una infraestructura en producción sin asegurarte de que TODO lo que importa tiene una copia de seguridad UTILIZABLE.
Os recomiendo su lectura, que además transmite muy bien la tensión del momento:
David,
Ayer me pasó algo que tengo que contarte. No sé si tendrás tiempo con tanto tour, pero para cuando tengas un rato...
El caso es que quería actualizar nuestro servidor de Hyper-V y pasarlo de WS 2008 a R2. En él reside una granja de servidores para un proyecto (8 máquinas) más otras tres de infraestructura interna (el CSS de los ISA, TFS para el código de los desarrolladores y el SQL 2008 donde reside este código). Además quería aprovechar para aplicar el SP1 al SQL 2008. Total, que planeo todo el proceso y echo a tó qusqui de la oficina a las seis. Empiezo a apagar máquinas y me asalta una duda: ¿y si me cargo la granja de servidores con el upgrade? Pues nada, pincho un disco USB y exporto ahí todas las máquinas.
En estas que me doy cuenta que al SQL le quedan sólo 1,5 GB libres en disco y aprovecho, mientras se exportan las máquinas, para hacerle un expand. Hyper-V manager, edit disk, lo selecciono, veo que es dinàmico (¿qué raro, yo nunca uso discos dinámicos en producción...?), lo paso de 16 a 20 GB y justo cuando está hecho... HOSTIA, SI TIENE UN SNAPSHOT!!! Pruebo a arrancar la máquina y... NO ARRANCA!!! Sudor frío, improperios varios... pánico. ME HE CARGADO EL TRABAJO DE UN EQUIPO DE UNAS 10 PERSONAS ENTRE 6 Y 12 MESES! Sobra decir que no tenía copias de seguridad (esto tiene disculpa, pero es muy larga de explicar y no viene al caso), excepto la copia local del código que pueda haber en las máquinas de la granja. Pero... ¿y si esa copia local no es buena? ¿Y si no se puede recuperar? Tengo que arreglar esto antes de mañana a las 08:00.
Después de un momento de duda, recordé que los AVHD de los snapshots no son más que discos diferenciales con la extensión cambiada. Lo que debía estar pasando era que el AVHD sabía que el disco padre que veía era distinto del que tenía que ver y, claro, no podía arrancar. ¿Pero qué era lo que le hacía saber que no era “su” disco? ¿La fecha? ¿El tamaño? ¿Alguna firma o ID?
Me bajé las especificaciones del formato VHD (gloriosos estándares), creé algunos VHD de prueba con los mismos tamaños y, con la ayuda de algunos editores hexadecimales, pude comprobar que cambiaban muy pocos bytes de la cabecera (más algunos en el interior, pero invocaría a los dioses para que no fueran importantes, que fueran de relleno). Lo que cambiaba era sólo el tamaño actual del disco (00 00 00 04 00 00 00 00 para 16 GB, 00 00 00 05 00 00 00 00 para 20 GB) mientras que el tamaño original permanecía intacto, la geometría del disco era siempre la misma para el mismo tamaño de disco y luego habría que calcular el checksum (grandiosa calculadora en modo programador de WS 2008). Logro editar todo esto, lo copio al final del fichero (la cabecera de los VHD se repite al final) y guardo copia de todo por si tengo que volver a empezar. Más tarde caí en la cuenta que la cabecera debía ser muy parecida entre el VHD padre y el AVHD (cambiaría sólo el tipo de disco, dinámico en el primero y diferencial en el segundo), así que aproveché para comparar y... sí, estaba en lo correcto, coincidían.
Moment of truth. Le doy al botón de arrancar la máquina... y la muy bonita va y lo hace!!! Lágrimas, confort... la autoestima vuelve a sus niveles de siempre.
Luego aproveché para eliminar el snapshot del SQL y del TFS, pasar los discos a tamaño fijo (si ése hubiera sido el caso no habría tenido el problema, puesto que la expansión de uno físico se hace en otro disco, no en el mismo como es el caso de los dinámicos), aplicar SP1 y updates, actualizar BIOS, firmwares y drivers del host... Lo que no pude hacer fue el upgrade a la R2 del host, porque te avisa que hay una incompatibilidad con los saved state entre las versiones 1 y 2 de Hyper-V, cosa que provoca incompatibilidades entre snapshots online y podría volver a perder el trabajo, esta vez por perder las máquinas. Aunque hubieran sido recuperables (tenía los backups), preferí no sudar más coger el coche e irme para casa.
Y todo este rollo te lo cuento por si crees útil usarlo en tu blog, porque si alguien más se encuentra en esta situación (a) sepa que no ha lugar decir “esto sólo me puede pasar a mí, mira que soy burro” y (b) tenga una solución a mano.
En fin, suerte con el tour y, de paso, gracias por el blog y por esos posts de cómo montar escenarios para probar tecnologías, que son algo muy difícil de encontrar.
Saludos.
Saludos