GitLab.com melts down after wrong directory deleted, backups fail

Hace años que no se imparte en LSI el tema relacionado con "backups", RAIDs, LVM, etc., por solape con otra asignatura. Recuerdo que siempre incidía en que hacer "backups" es fundamental, aunque probarlos puede serlo mucho más.

También se contaba algún acontecimiento pseudo-traumático en nuestra universidad con "backups" muy virgueros pero que al ser necesarios, no hacían lo que se suponía tenían que hacer.

Hoy mi colega Alejo me remite noticia relacionada, en este caso en GitLab.com.

En otras ocasiones también hemos hablado de los rm -rf

Sistemas de respaldo en una pequeña empresa

Alejo me remite una notica de unos de los múltiples temas que se tocan en PSI, el del apasionante mundo de los sistemas de respaldo, cariñosamente conocidos como entornos de "backups". Hace tiempo estuvimos mirando conjuntamente algunas plataformas de "backups" para entornos de la pequeña empresa. Entrada disponible aquí.

Por cierto, entras las múltiples modificaciones de las prácticas de este curso 2010-2011, una de ellas está relacionada con esta noticia. En concreto, en la práctica tres, entre otras muchas cosas, habrá que configurar el entorno backuppc.

Backups, siempre con nosotros o, descanse en paz

Todo un placer que, después de 6 meses de finalizar la asignatura del curso académico 2008-2009 en Protección y Seguridad de la Información, siga recibiendo emails de mis antiguos alumnos. En unos casos para señalarme noticias relevantes en el ámbito de la seguridad, como por ejemplo que "El algoritmo de cifrado de los móviles 3G también ha caído" y, en otros, para hacer consultas en distintos campos. Esta entrada reponde a la última de ellas, sobre uno de nuestros temas clásicos e inseparables, los “backups”.

En el de referencia, entre otras cosas me comenta literalmente, “la he cagado con el backup de mis archivos”. Antes de nada puntualizar que todos la “cagamos” alguna vez. Después de una de estas, unos aprenden, y otros vuelven a reincidir. Pero normalmente, una “cagada” así, no se suele olvidar, especialmente cuando la pérdida de los datos supone un considerable problema. Todos cometemos errores, de los cuales debemos sacar conclusiones y aprender. En la parte final del email me pide consejo sobre la ubicación para sus “backups”. Como todo en nuestra profesión, los consejos o decisiones son subjetivas, y dependientes de una gran cantidad y variedad de parámetros.

Sobre backups, pensando en los posibles datos-información manejada por un alumno, existen muchas posibilidades.

1) Tal y como apunta por email, “el uso de grabadoras de DVD, etc., son un coñazo y suponen un cierto gasto económico en dispositivos”. Por otra parte, los DVDs regrabables son reutilizables un cierto número de veces, y también suponen un cierto gasto económico. Además, la velocidad no ayuda a verlo como un dispositivo atractivo para estas tareas. Pensando en dispositivos de "backup" para un alumno, de LTOs, etc., ni hablaremos.

Uno de las muchas habilidades que siempre he tratado de transmitir en clase es el uso del factor económico en toda toma de decisión en conjunción estricta a los criterios técnicos. Muchas veces cuando la decisión "toca" al bolsillo de uno mismo es el primer parámetro que se nos viene a la cabeza. El día de mañana, cuando estés integrado en una empresa, o en la administración, y tengas que tomar decisiones, razona de la misma forma. Es una de las muchas cosas que he tratado de transmitir en clase, y este ejemplo lo ilustra perfectamente.

2) Utilizar los equipos de la FI para hacer "backup". Problemática.: La asignación de cuotas de disco por parte de la FI hace que no se disponga de espacio para dicha tarea. Tal vez no estaría mal que desde la delegación de alumnos se le plantease al vicedecano de recursos informáticos la posibilidad de un servicio al alumno de este tipo en la FI, o directamente a los Servicios Informáticos de la UDC, aunque desde un punto de vista económico, posiblemente sea más acertado el utilizar los muchos servicios gratuitos disponibles en la red.

3) Utilizar un disco duro externo, por ejemplo en USB. Este es uno de los dispositivos que utilizo yo para hacer "backups" de mi equipo de trabajo personal. En la actualidad, un DD tiene un coste muy pequeño, y constituyen una muy buena opción, rápida y versátil. Puedes encontrar DD USB2 de 320GB entre 40 € y 50 €. Pero como siempre, estamos ante un gasto, y puede que no te lo puedas permitir. Señalar que puede ser una buena opción, tanto para “backups”, como para otras muchas tareas de almacenamiento. En mi caso, reinstalar mi equipo de trabajo, con todas las aplicaciones, datos, máquinas virtuales, etc., etc., me supone entre 2 y 3 días de trabajo. Lo que suelo hacer, después de tener todo preparado y configurado, es crear una imagen completa de mi disco duro contra el USB. En caso de cargarme el equipo, restauro toda la imagen y fin del problema. Eso no quita que pueda utilizar otros niveles de “backups” de ciertos directorios, “snapshots” de algunas máquinas virtuales, etc.

4) En el caso de buscar una solución totalmente gratuita, el uso de servicios gratuitos de almacenamiento constituyen la alternativa. Normalmente "alumno=no sobran los euros", por lo tanto es necesario buscar soluciones que no supongan un coste económico. En la red existen muchas posibilidades, obviamente no las he probado todas al no tener necesidades de espacio de almacenamiento. Señalar que en algunas ocasiones utilizo el servicio gratuito Skydrive, con el uso de una cuenta Windows live, que proporciona 25 GB de almacenamiento, y creo están plateando subir a 50GB. En el caso de ser suficientes es una de las alternativas. Tienes otras posibilidades como Megaupload (200GB), almacenamiento en la nube de FileBox (488 GB), Taringa (30 GB), Adrive (50 GB), etc. Muchos de estos servicios te proporcionan almacenamiento "free" durante un cierto tiempo. Por ejemplo FileBox durante 1 año, Megaupload durante 2 años, etc. Haz la selección atendiendo al espacio que necesitas, el tiempo de almacenamiento "free", las velocidad de transferencia de los archivos a almacenar desde la ubicación habitual de trabajo, el nivel de seguridad o información en la red al respecto. Recuerda que siempre podrás cifrar tus datos antes de hacer el "backup", aunque no necesites un nivel de seguridad similar al de las bases de datos de los bancos. Cifrar los “backup” es un mecanismo más que suficiente para securizar la información de las prácticas, etc.

Y en caso de duda, date de alta en los dos servicios que resulten ganadores. Con el tiempo verás cual te proporciona un mejor servicio.

Cualquier otra cosa, estoy a vuestra disposición,

Bitácora de PSI.: Vida salvaje (la redundancia)

Seguridad y redundancia, dos términos íntimamente ligados. Al igual que la "hydra" de la fotografía, la redundancia a distintos niveles nos podrá proporcionar, entre otros, sistemas tolerantes a fallos, alta disponibilidad, computación distribuida y balanceo de carga. En este punto deberemos tener presente la organización "hardware" de nuestros sistemas que, en muchas ocasiones, pasará por la instalación de "clusters" y "blades" (los tipos de enlaces de ambos son autoexplicativos, y recuerda que en algunas ocasiones puede ser aconsejable "casarte" con alguna empresa y cubrirte la espalda con algún tipo de soporte). Tampoco debemos olvidarnos del mundo de la computación GRID. Además, la virtualización y paravirtualización de nuestros sistemas proporciona, entreo otras muchas ventajas, una gran flexibilidad, sin entrar en los posibles problemas de seguridad añadidos a este tipo de aproximaciones y a sus hypervisores.

Todo en la naturaleza utiliza la redundancia como mecanismo de protección-supervivencia. Muchas especies tienen docenas, cientos o incluso miles de crías. Como es lógico, este parámetro está relacionado con su índice de supervivencia. En resumen, se busca perpetuar la especie garantizando la supervivencia de un determinado número de individuos, al igual que nosotros buscamos garantizar la supervivencia de nuestros sistemas y servicios. Si tomamos un único individuo, la redundancia está presente en nuestro sistema de visión y auditivo, más que nada para poder disfrutar del estéreo de los sentidos, dos pulmones, dos riñones, ..., y un corazón (en este último caso más bien por un problema de consumo, de energía). Siempre hay elementos que saldría demasiado caro redundarlos.

La genética y la evolución siempre está presente en nuestros sistemas. La capacidad de adaptarnos a situaciones cambiantes es un cualidad muy deseable. Si estás interesado en estos temas te recomiendo alguno de los proyectos fin de carrera que propuse y dirigí cuando era joven, y que sobre los distintos subsistemas gestionados por nuestros sistemas operativos, se desarrolló todo un conjunto de algoritmos genéticos para proporcionar un sistema automático de ajustre de nuestros sistemas, facilitando su adaptación a distintos entornos, tanto "hard" como de aplicativo. Un ejemplar de cada uno de ellos está disponible en la biblioteca de la FI de la UDC. La monitorización y ajuste de nuestros sistemas es una tarea compleja. Por lo tanto, todo sistema automático que mejore el rendimientos de nuestos operativos, constituira un primer paso para hacer a nuestros sistemas operativos un poco más listos.

Si pensamos en nuestra infraestructura, encontramos redundancia a todos los niveles.

- Tal vez nuestras redes de comunicaciones constituyen el elemento más importante a la hora de pensar en redundancia. Si las redes fallan, todo falla. Debemos tener en cuenta tanto líneas redundantes como activos redundantes. Los caminos que nos unen son múltiples, variados y multitecnología. Hay bits que vuelan, otros navegan y, los que más me gustan a mí, hacen espeleología. Y recuerda, tal y como hemos visto en aventuras anteriores, que existen otros muchos mundos, otras muchas redes.: de suministro eléctrico, de alimentación ininterrumpida, de agua, de gases, de puesta a tierra, etc.

- CPDs redundantes o, como mínimo, la parte más importante, el almacenamiento. Un servidor se puede sustituir (es cuestión de €s), la pérdida total de los datos y de todo soporte disponible puede no serlo. ¿Qué hubiese pasado si nuestra empresa y todos sus sistemas hubiese estado en las torres gemelas o en la torre windsor? (bueno, sin contar con disponer de "backups" de todo en la caja innifuga de la windsor). Además, este nivel de redundancia nos permitirá jugar con distintos esquemas de alta disponibilidad y balanceo de carga, etc., sobre infraestructura en distintos edificios. Recuerda que muchas de estas tareas podrás delegarlas en equipamiento "hardware" especializada, como puedan ser los balanceadores de carga, aceleradores SSL, etc. Aunque en clase referencié algunos de estos dispositivos, no los incluyo aquí por no hacer publicidad. Si algún proveedor de este tipo de sistemas llega a esta entrada y está interesado en presentar alguno de sus "cacharros" a un grupo de unos 60 futuros profesionales, que no dude en contactar. Por favor, abstenerse comerciales.

Observación para los alumnos.: Es habitual encontrar comerciales que siempre tienen una respuesta afirmativa a cualquier cuestión técnica del tipo si se puede hacer tal o cual cosa que, a posteriori, se vuelve prácticamente inviable. Cuando te entrevistes con comerciales, procura documentarte bien sobre el tema a tratar y, de ser posible, ponle algún examen sobre cuestiones que tengas claras y sean poco viables para ver su grado de fiabilidad. Y recuerda que no encontrarás un buen comercial que antes no haya sido buen técnico. Esto mismo se puede aplicar a los directivos y gestores de personal. Vivimos en un mundo en el que con cierta frecuencia se trata de "vender la moto", aunque "menos mal que nos queda Portugal".

- Backups redundantes. Son demasiadas las veces que asistimos a situaciones en las que en el momento de necesitar un "backup", no está en las condiciones que debería, o con la política adecuada a nuestras necesidades. Una buena política de "backups" nos dejará dormir más tranquilos por la noche. Tampoco es aceptable entrar en un CPD y encontrar DLTs de "backup" zapateados por las mesas.

Sobre "backups", haciendo memoria de los tiempos en los que ejercía la segunda profesión más antigua del mundo, al inicio de los noventa utilizaba el tar sobre cintas de 150 Mb. Todo estaba planificado y organizado pero, la primera vez que necesité recuperar algo, mi dispositivo me recibió con un checksum error. Que hijo de puta, con perdón, pensé yo. En esas fechas descubrí que habría ciertas tareas que se debían hacer en single user, o buscar una utilidad un poco más evolucionada e inteligente que un simple tar. Pero bueno, con un poco de imaginación al final se pudo hacer la recuperación. Pasaron unos años y las unidades de cinta de 4mm. llegaron a poblar nuestras mesas (ellas nunca lo harían, no las dejes abandonados encima de la mesa). Ahora pensábamos en Gb, en lugar de Mb., y la compresión de la información entró en nuestras vidas. Era habitual encontrar "backups" sobre cpio, dump-restore, afio, etc. También empezamos a exportar disco en red y a hacer "backups" a disco, mucho más rápido. Finalmente, antes de dejar de ejercer esta gratificante profesión, se instaló un sistema de "backup" en red, un IBM server con el software de "backup" TSM, Tivoli para los amigos, con un primer nivel de "backup" a disco, en el que predominaba como mecanismo de seguridad el RAID5, y un segundo nivel de transferencia a un dispositivo de LTOs. Sin duda alguna las posibilidades de planificación de "backups" en este tipo de sistemas permiten una flexibilidad más que suficiente para atender las peculiaridades de todo tipo de entornos, sistemas y usuarios.

- No quiero dejar fuera de esta sección otro elemento importante a redundar, al menos parcialmente, se trata del personal. Es habitual encontrarnos profesionales que utilizan todo tipo de estrategias para garantizar, muchas veces en un proceso oscurantista, que todo está bajo su único control. No es un delito, pero toda organización deberá tratar de redundar, en la medida de lo posible, total o parcialmente según sea el entorno de trabajo, las atribuciones más críticas del personal técnico. Como decía y dice Rosendo, "esto es la fauna, chaval". Pero también puedes encontrarte el típico centro con buenos profesionales, que planifican todo el trabajo, las migraciones, etc., etc. En estos casos los servicios proporcionados y el trabajo desarrollado pueden llegar a pasar desapercibido para los usuarios y, o, directivos. En algunas situaciones se puede llegar a pensar que sobra personal o que parte del mismo se puede derivar a otras tareas. En el lado opuesto esta el entorno de trabajo que no planifica o hace mal los desarrollos. Se puede llegar a dar la situación que cada cierto tiempo el usuario se percata de problemas en el servicio, así como los directivos, y de la gran labor que desarrolla ese personal técnico y la enorme necesidad de contratar nuevo personal para que todo funcione bien. En estos casos siempre suele aparecer el "técnico" salvador que, después de generar grandes problemas, los soluciona para aplauso de todos los que asisten al circo. Obviamente, contratar nuevo personal no suele solucionar el problema. Pero bueno, siempre queda la opción de coger a los mejores técnicos y aplicar la redundancia por medio de la clonación. Esto último no es posible, pero identificar el trabajo bien hecho debe ser una de las principales tareas de cualquier directivo. Obviamente, será difícil, por no decir imposible, que un directivo pueda llegar a desarrollar bien su trabajo, si antes no ha sido un buen técnico, o al menos aceptable. Como consejo, no tengas prisa por llegar a la cima de la montaña, disfruta de la ascensión. Y recuerda que la cima no es el paraíso.

Finalizamos la clase con un clásico de la redundancia en almacenamiento, los sisetmas RAID (Redundant Array of Inexpensive Disks). En este punto se incluyen conceptos como "hot swap", cabinas de disco, SCSI (Small Computer System Interface), SATA, "Fibre Channel", SAN (Storage Area Networks), "fabric director", etc.

Se analizan los niveles RAID básicos.:

- Lineal (muy bonito en la teoría, pero no sirve para nada)

- 0 "stipping" (utiliza n discos con almacenamiento en paralelo sobre los mismos). Un fichero se almacena en varios discos duros. Este nivel busca un incremento en el rendimiento de la I-O a disco, sin aportar redundancia-seguridad en el almacenamiento. Habitual encontrarlo en sistemas de edición de vídeo (el "rendering" suele comer todo rendimiento a disco que le podamos proporcionar), cálculo científico intensivo (modelos climáticos, biología molecular, etc.) y, en general, en todo entorno que mueva grandes cantidades de datos con nuestros discos. A nivel operativo, señalar que podemos hacer RAIDs de particiones o particiones de RAIDs. Es habitual que, con el tiempo, se tengan que adquirir nuevos discos duros y, por lo tanto, convivan distintos tipos de discos. Una buena organización mejorará los rendimientos o, al menos, no los empeorará. ¿qué pasaría si en un RAID 0 o 1 algunos discos duros fuesen más lentos que otros?

- 1 (mirror). En este nivel existe una redundancia total del almacenamiento, garantizando la disponibilidad del sistema ante casques de dispositivos. Obviamente, todo tiene un coste, y este caso requerirá una doble inversión. Recuerda que si únicamente dispones de una controladora de discos, podrás estar protegido ante la "muerte" de discos, pero no de controladora. Redundar las controladoras y organizar los discos adecuadamente te proporcionará otro nivel de seguridad.

En este punto, antes de continuar con los RAID, se analiza el proceso de "bautizo" de un disco duro. Un disco duro no se puede montar según te llega de fábrica, hay que bautizarlo (particionarlo y generar el sistema de ficheros). Aunque los discos duros virtuales de nuestro laboratorio no se puedan tocar, al ser ficheros, requieren seguir el mismo proceso. No puedo tratar de montar un disco duro que no ha sido particionado, ni generado su sistema de ficheros. El fdisk y el mkfs te podrán solucionar dicha tarea. El fichero /etc/fstab será el encargado de definir la información de montado. En clase se analiza el formato del /etc/fstab y las opciones que podemos encontrarnos. No incluyo en esta entrada nada al respecto, al estar ampliamente publicado en diversas fuentes. También analizamos el conjunto de ficheros y directorios que nos podemos encontrar en el, como dice la literatura, "pseudo" sistema de ficheros /proc.

Concluimos la clase con una cuestión, ¿qué sistemas de ficheros utilizaremos?. La respuesta no es cualquiera, o el reiserfs o ext3 que es el que suelo encontrarme. Si dentro del comando fdisk selecionas la opción l verás varias decenas de sistemas de ficheros distintos. Entonces, para que tantos?. Pues bien, los sistemas de ficheros son como el vino, los hay buenos y malos, unos aconsejables para ciertas comidas y otros para otras. A nadie se le ocurre tratar de meter un fichero de 4 GB en un disco FAT. Por lo tanto, deberemos tener en cuenta factores como los discos duros y buses disponibles, tamaño de los ficheros y directorios, números de lecturas y escrituras, patrón de los accesos a disco y carga de trabajo, algoritmos o planificadores disponibles, gestión de bloqueos, estrategias de reconstrucción ante "casques", etc. Dejamos el tema aquí exponiendo dos posibles configuraciones de un mismo servicio, el de correo electrónico que, según utilicemos "mbox format" o "maildir format" las implicaciones en cuanto al sistema de ficheros serán radicalmente opuestas.

Para terminar, hablando de rendimimiento y seguridad en el almacenamiento, un curioso video de rendimiento con SSDs (fuente Tomás, gracias). Además, no debemos olvidarnos que el cifrado de los sistemas de ficheros tienen su implicación en el rendimiento.

rdiff backup

En la práctica tres algunos apartados están relacionados con nuestro siempre inseparable proceso de backup. En http://debaday.debian.net/2008/10/26/rdiff-backup-easy-incremental-backups-from-the-command-line/ tienes una entrada que trata las aventuras y desventuras de una sencilla utilidad, el rdiff.

Un mal profesional puede hacer una copia de grandes volúmenes de información entre discos utilizando un simple cp. Claramente a ese profesional se le debería enviar a un curso básico de administración de sistemas. Existe toda una serie de comandos *diff que falicitar enormemente esta tarea y, o, la sincronización de dispositivos, entro otras muchas opciones disponibles, como por ejemplo rsync.