Una historia de backups, vacas sucias y Mr. Robot

Hace un rato, cuando he ido a abrir una de las aplicaciones de mi servidor me he dado cuenta que no funcionaba. La verdad es que no la uso demasiado a menudo pero ese 502 sonaba a muy raro porque nunca antes había fallado.

Estas cosas pasan, me dije, así que sin pensar mucho más he abierto el log de errores y lo he encontrado lleno de proyecto/src/gunicorn.sock failed (2: No such file or directory) while connecting to upstream, hmm, pero sin haber tocado nada entiendo yo que las rutas no se cambian solas ¿no?, bueno, comprobemos... wt*, ¡¡proyecto/src/ no existe!!, no hay nada, directorio en blanco, vacío... ¿cómo puede ser posible?.

Tranquilo, piensa en frío, tú haces copias de seguridad así que no hay problema. Ponte la capucha Mr Robot e intenta pasar un buen rato con todo ésto.

Tienes razón, va, abriendo logs, el error ha aparecido el viernes 21 a eso de las 17:30 de la tarde. Haz memoria pero creo que ese viernes por la tarde... justo ese viernes y a esas horas... ¿no estabas probando los PoC de dirtyc0w en esa máquina?. Ni con la capucha, pulsaciones subiendo... a ver, relaja, reinstalación, restore de la última copia y lección aprendida ¿no?.

Ya pero... ¿uno de los PoC pudo haber borrado datos?, ¿cómo es posible que nadie haya dicho nada?, demasiado raro. Espera, recuerdo que instantes después de haberlo ejecutado la máquina se quedó frita y tuve que reiniciar, ¿qué dice el log del sistema?...

Oct 21 17:31:08 me kernel: EXT4-fs (sda1): INFO: recovery required on readonly filesystem
Oct 21 17:31:08 me kernel: EXT4-fs (sda1): write access will be enabled during recovery
Oct 21 17:31:08 me kernel: EXT4-fs (sda1): orphan cleanup on readonly fs
Oct 21 17:31:08 me kernel: EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 938198
Oct 21 17:31:08 me kernel: EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 938126
Oct 21 17:31:08 me kernel: EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 921486
Oct 21 17:31:08 me kernel: EXT4-fs (sda1): ext4_orphan_cleanup: deleting unreferenced inode 921485

Va Mr Robot, deja de hacer el estúpido, quítate la capucha y pásale un chequeo al disco más de vez en cuando, ¡y ojo con los enlaces simbólicos!... No veas la mañanita que me estás dando con estas tonterías. Restaura el último backup y deja las gilipolleces para otro día.

Bueno, qué digo último... ¡el del 21!. Dime que guardas varias incrementales anda. ¡Espera!, justo estos días has estado jugando con las copias que lo he visto... madre mía... ¿por qué no te quitas la capucha?, ¡dí algo!, ¿¡por qué te vas!?.

# duply backup fetch proyecto/src/ /ruta/absoluta/al/proyecto/src/ 10D

¿Qué ritmo te marca la pulserita pija esa que te has comprado?, ¿a cuánto te bombea el corazón mientras duply no acaba?. Menos mal que te había dado por jugar con él en su día. Esta vez te ha salvado el culo, admítelo. Nunca está de más tener otra copia a mayores, te lo dije.

Y así es como, en una fría mañana de octubre, he aprendido varias lecciones:

  • No borrar incrementales a no ser por falta de espacio.
  • El tiempo perdido en mejorar la política de copias de seguridad es la mejor inversión, ever.
  • Duply funciona cojonudamente, no quiero lanzar piedras contra el tejado de rdiff ni mucho menos -de otras peores me ha sacado-, pero duply hace magia blanca sin pedir permiso (comprimido, control de solapamiento, ejecución secuencial sólo en caso de no-fallo...).
  • La capacidad de almacenamiento está demasiado barata como para racanear con ella.
  • Me encanta el modo capucha.
sysadmin

About the author

Óscar
has doubledaddy super powers, father of Hugo and Nico, husband of Marta, *nix user, Djangonaut and open source passionate.
blog comments powered by Disqus