DIsaster REcovery PLan OSiux

index | about | archive | charlas | docs | links

dot | git | img | plt | tty | uml

direplos-deb-tty.png

Si algo malo puede pasar, pasará!

Ayer fue mi primer día de laburo del 2021 y arranqué mal, o mejor dicho cachaza arrancó mal, en realidad, arrancar, arrancaba, solo que se apagaba todo el tiempo, incluso escribí mi primer post del año sobre ansible luks format 1 al respecto comentando como rápidamente utilizando un rol de ansible pude cifrar el nuevo disco externo para hacer backup.

Noche de apagones

Estuve toda la noche (gran parte en realidad) reintentando una y otra vez hacer un backup de todos los datos, pero como la notebook se seguía apagando, la copia se interrumpía una y otra vez :( Al menos sirvió para verificar que utilizar cp -vr usa menos CPU que usar rsync -avP, eso me permitió avanzar, pero luego claro, tuve que caer en rsync porque obviamente es la mejor manera de continuar una copia parcial, la mejora ahí fue utilizar nice -n 19 rsync -avP e irse a dormir.

Mañana de mantenimiento

Era de esperar, desperté, verifiqué el estado del equipo y estaba apagado, asi que procedí a desarmarla y hacer una limpieza, quitando 4 años de polvo, pensando que iba a ayudar, al menos el cooler y las ventilaciones quedaron en mejores condiciones.

Arrancó bien, configuré cpu gobernor en powersave y maté todos los procesos que podrían consumir mucha CPU y me puse a trabajar.

Mediodía partido al medio

Lo peor, sucedió! Se apagó una vez más, pero esta vez, no volvió a encender ni un led, ni en el teclado, ni el botón de power :~(

Probé varios cargadores, probé esperar y cruzar los dedos, pero tampoco funcionó y mas allá del cariño que le tengo a una extensión de mis dedos y pensamientos, mucho más que una herramienta de trabajo y diversión, lo importante son esos datos que no llegué a terminar de copiar…

y ahora, de qué nos disfrazamos?

Luego de un minuto de silencio y reflexión, definí los pasos a seguir:

  1. terminar la copia de datos, extrayendo la unidad M2
  2. armar un entorno de trabajo en otra notebook
  3. elegir un nuevo modelo de notebook a comprar

Hay Backup?

Bueno, disco externo nuevo de 4TB ya tenía disponible, solo faltaba remover el M2, ponerlo en un adaptador USB, conectarlo a otro equipo y ponerse a copiar.

Gracias nuevamente a compañerxs de gcoop 2 en un par de horas ya contaba con el adaptador M2 y pude verificar que al menos las particiones se listaban correctamente.

(des)cifrado recursivo

Teniendo conectado la unidad M2 origen y el disco externo en una nueva notebook, solo restaba montar las particiones y ponerse a copiar, fácil si nunca cifrás las particiones :P

Resulta que el nuevo disco externo, lo cifré el día anterior usando luks, pero no tenía la menor idea de la passphrase, por suerte el cron que se ocupa de sincronizar mis repositorios importares cada 5min logró funcionar y bastaba instalar pass 3 en caipiroska para recuperarla, pero para montar la partición de root además necesitaba la gpg y el password-store de root que estaban dentro del disco externo, que estaba cifrado! XD

DIREPLOS

Cualquier equipo en cualquier momento puede morir repentinamente o si es móvil lo podes perder (yo me olvide ni notebook en un colectivo y tuve la suerte de recuperarla) o con mala suerte lo pueden robar o consumirse en un incendio, entonces la clave esta en poder recuperase rápidamente y para ello es necesario un plan de recuperación de desastres y lo básico es contar con las herramientas (sistema operativo, aplicaciones y utilitarios), la configuración especifica y lo irreemplazable, los datos.

Hace años, de alguna manera automaticé rústicamente la instalación de todos los paquetes que considero vitales para mi entorno en el repositorio direplos 4, si bien quedó desactualizado el script deb.sh y a medio «refactorizar» y sin publicar la versión ansible, pero con mínimos cambios pude ejecutar la instalación con el comando:

deb.sh -ut

De esta manera, pude contar con todos los comandos necesarios para trabajar, o casi :P

Algo no resuelto del todo es que, además de diferentes programas y utilitarios, necesito muchos archivos de configuración, gran parte de ellos están versionados y disponibles en un servidor remoto, pero la cuestión pasa por encontrar la secuencia correcta de deploy.

git-repos al rescate!

Por ser previsor, gran parte de lo que necesito, esta (o debería estar) en un repositorio git, ahora bien, como buen ñoño, tengo muchos repositorios propios y uso a diario muchos otros, de proyectos en los que trabajo o trabajé en algún momento, como así también todo lo que me resulta interesante de la comunidad del software libre y con el paso del tiempo la lista creció exponencialmente, entonces, era necesario administrarlos se alguna manera.

De cabezadura se me ocurrió solucionarlo con un desarrollo propio que simplifica la tarea de clonar y mantener sincronizados todos los repos, solo basta ejecutar:

git clone https://gitlab.com/osiux/git-bash-utils
cd git-bash-utils
git-repos -c

Esto lee el archivo .git-repos de mi home y se ocupa de clonar todos los repositorios. Me doy cuenta de una gran mejora es contar con mas e un archivo .git-repos en varios directorios.

sin mi entorno, no soy eficiente

Lo bueno de personalizar tu entorno al máximo es que sos extremadamente ágil en cada tarea, por mas simple que sea y yo tengo muchísimo tiempo invertido en optimizar mi entorno porque básicamente prácticamente todo lo hago dentro de una terminal.

Lo malo es que si no tenes tu entorno disponible, te volvés muy torpe y lento, por este motivo es vital contar con un procedimiento que permita levantar tu entorno rápidamente en cualquier equipo y con un mínimo esfuerzo, y con este incidente pude confirmar que mi entorno es reproducible y es muy poco lo que me olvide de «commitear», pero lo difícil y costoso fue no tener segmentado y priorizado, es decir, tener que esperar a que el 100% de tu entorno se despliegue por completo, es demasiado tiempo, asi que estoy aprovechando la oportunidad en definir el mínimo entorno necesario y en dejar un test que a diario regenere mi entorno a los efectos de encontrar el equilibrio entre un deploy rápido y un entorno mínimo que permita estar operativo ante un desastre o un simple cambio de equipo en un par de minutos en lugar de un par de horas.

Tal vez te interese…

ChangeLog

Notas al pie de página: