Bacula Vol III

Hoy toca entrar en harina, pelear en la trinchera, bregar con los leones etc… o sea, q hoy toca sesión de tecleo.

Vamos a instalar Bacula para poder empezar a trabajar y hacer unas copias de seguridad frescas. Por desgracia la instalación de Bacula me va a obligar a dedicarle un articulo entero, y es que es absurdo el tiempo que se pierde en el mundo Linux instalando mierdas, pero es lo que hay. Es claro que se ha avanzado muchísimo desde los tiempos del "configure make" con estas virguerías de repositorios y gestores de paquetes, pero aun asi entre pitos y flautas se te va un tiempo majo, máxime si no hay paquetillo en el repositorio de rigor (si que lo hay para RHEL pero paso) y tampoco es que el manual sea claro, apuntando a hipervínculos que no existen y cosas de esas del software free.

Requisitos

Podéis elegir la distro que mas os convenga, pero todo lo relativo a la instalación será referido al sistema que pongo a continuación:

• Centos 5.3 32 bits (sin entorno grafico instalado)
• Mysql (instalado desde yum)
• Bacula (instalado desde fuentes sin soporte para herramientas graficas)

Sin mas. Para manejar el sistema se tirara de bconsole (herramienta de texto) aunque se instalara un front-end grafico vía web bastante aparente a priori aunque a la larga inútil total me parece a mi.

Instalación Bacula

Primero Mysql y el gcc:

yum install mysql mysql-devel mysql-server gcc-c++

Si arrancáis el MySQL con el típico /etc/init.d/mysql start se rellenaran las tablas internas necesarias.

Ahora vamos con la compilación de Bacula. Por desgracia no hay paquetes yum pregenerados (si que los hay para RedHat, que viene a ser lo mismo, pero como tampoco es que sea muy compleja su instalación desde fuentes asi lo haremos, por si las moscas).

Tenéis el tar.gz en http://www.bacula.org/en/?page=downloads

En un primer momento descargamos bacula-3.x.y.tar.gz y lo dejamos en root.

wget https://sourceforge.net/projects/bacula/files/bacula/3.0.3/bacula-3.0.3.tar.gz/download

Descomprimimos

gunzip  bacula-3.x.y.tar.gz

tar xvf  bacula-3.x.y.tar

y a compilar. Las opciones que he elegido yo son:

CFLAGS="-g -Wall"  ./configure –sbindir=/usr/local/bacula/bin

–sysconfdir=/usr/local/bacula/etc

–with-pid-dir=/usr/local/bacula/run

–with-subsys-dir=/usr/local/bacula/bin/working

–with-mysql

–with-working-dir=/usr/local/bacula/bin/working

–enable-smartalloc

–enable-batch-insert

–enable-conio

Hacemos el make y lo instalamos

make install

y si queremos que se nos añadan los links en los directorios de runlevel para su arranque automático no hay mas que hacer

make install-autostart

Con esto ya tenemos lo mínimo. El ./configure elegido yo lo suelo guardar en un fichero llamado config.sh al que doy permisos de ejecución por si en un futuro tengo que cambiar alguna configuración. Si queréis recompilar, primero hacer un

make distclean

y luego darle otra vez al ./configure de rigor.

Las opciones de configuración son variadas, a continuación os resumo las mas típicas:

• xxxdir=<path>: estas son las típicas para indicar donde se dejan las cosas. En el ejemplo todo se va a dejar en /usr/local/bacula y luego cada cosa un poco en su sitio. Ojo que el directorio /usr/local/bacula/run no se crea automáticamente, y en el es donde deja el sistema el fichero con el pid del proceso de modo que al arrancar si no se encuentra dicho directorio falla pero no se muestra en pantalla el fallo (sale un OK en verde mas falso que Judas), asi q ojo al dato con esto.
• enable-smartalloc: es un parámetro q recomiendan poner siempre: detecta leaks de memoria y otras historias internas del programa.
• Fruslerías graficas: enable-bat, with-qtw, enable-gnome, enable-bwx-console, enable-tray-monitor etc… para enganchar con las X. Pasando de esto.
• enable-batch-insert: si la base de datos utiliza una librería threads-safe entonces bacula hará inserts por lotes, lo que le supone un ahorro de tiempo muy considerable. Con SQLite2 esto no fona y en según que SOs puede petar, asi que al loro. En pleno siglo XXI y que todavía anden con mierdas de estas…
• enable-static-<modulo>: cada modulo se pueden compilar de forma estática para no depender de las librerías instaladas y su posterior cambio. Ya sabéis: estático: mas gordo y rápido, dinámico: mas ligero pero algo mas lento. A los efectos no se nota asi que pasando de estático.
• enable-client-only: si solo queréis compilar el fd, que es lo suyo en las máquinas de las que se va a hacer el backup.
• enable-build-<modulo>: si queréis compilar ciertos módulos (el director solo, el sd etc) para poder desperdigar bien el Bacula en diversas maquinas.
• with-<database>: elegir la bd soportada que mas os guste
• –enable-conio/readline. Esto sirve para soportar buffer en la consola y asi teclear menos. Se requieren ncurses para ello asi que hay que instalarlas  si vuestro sistema no lo hace por defecto.
• with-<modulo>-password: si no se indica se elige una pass aleatoria para cada modulo que se incluye en los ficheros de configuración automáticamente.
• with-<modulo>-user: usuario bajo el que se ejecuta el modulo. Yo lo dejo por defecto, q es root.
• with-<modulo>-group: grupo bajo el que se ejecuta el modulo. Yo lo dejo por defecto, q es root.
• with-db-name/user: ya sabes, usuario y nombre de la bd. Por defecto bacula.

Una vez hecho esto hay que crear la base de datos de Bacula. Esto se hace con

/usr/local/apache/etc/create_mysql_database

Y hasta aqui llega la instalación de Bacula como tal. Par arrancarlo, y siempre tomando como referencia los paths que he puesto en el configure habrá que hacer:

/usr/local/bacula/etc/bacula start

y con esto se nos levantan los 3 demonios: fd, sd y director.

Web

Ahora vamos con el modulito que nos va a permitir acceder al mondongo vía web. Para ello hay que instalar un apache  con las extensiones de php pertinentes:

yum install httpd php php-gettext  php-pear-DB.noarch php-gd.i386

Con esto liquidado nos bajamos el paquete de nombre bacula-gui.tar.gz

wget https://sourceforge.net/projects/bacula/files/bacula/3.0.3/bacula-gui-3.0.3.tar.gz/download

le hacemos la jugada típica

gunzip bacula-gui.tar.gz

tar xvf bacula-gui.tar

Esto nos deja con una carpeta llena de ficheros y mas carpetas. Tenemos que copiar todo el contenido de la carpeta "bacula-web" al root de la web, en mi caso /var/www/html.

Una vez copiado el tema tenéis un fichero a toquetear llamado configs/bacula.conf. Es bastante auto descriptivo y tiene las típicas chorradillas de configuración (donde esta el mysql, como se llama la base de datos llevara el catalog etc).

Arrancamos el apache con /etc/init.d/httpd start y hacemos una petición a la pagina test.php por ver si todo ha ido como debe o algo se nos ha escapado. Esta pagina además nos indica si satisfacemos las dependencias (GD, Gettext y Pear DB) y nos hace un text grafico vía GD: el front-end solo usa gráficos PNG asi que si no se ven los correspondientes a los formatos BMP, JPEG y GIF no debe de preocuparnos en principio.

Y hasta aqui esta jornada de instalaciones y mariconeo de pantalla varios. Ya la próxima sesión por fin podremos configurar el Bacula para que nos haga unas copias de seguridad fenomenales.

Bacula Vol II

Lo visto en el anterior episodio puede sonar bastante razonable, si bien muchos se preguntaran el porqué de Volúmenes y Pools y no simplemente decir “graba aqui” y listo el bote.

Bien, imaginad por un momento un administrador de copias que opera en una gran empresa de recauchutados llamada con toda lógica “recauchutados Martínez”. El chavalote, diligentemente, esta atento al sistema de copias para meter una cinta nueva cada vez que se éste lo pida. Por su parte el sistema de copias opera correctamente, recibe ficheros de docenas de servidores y todas las noches inicia una copia del tipo que fuere.

Por muy grande que sea la empresa el jefe de turno cortara tarde o temprano la compra de cintas y exigirá su reutilización: no es de recibo usar una cinta nueva cada vez que la anterior se llena y asi ad eternum, sino seria necesario un numero infinito de cintas ya que no sabemos a priori cuando el accionariado decidirá que el negocio de los recauchutados ya no es rentable y que hay q cerrar la persiana, con el consiguiente despido del proletariado y por tanto del administrador de copias, que dejaría de hacerlas consecuentemente.

En este sentido lo que se le puede ocurrir hasta al mas tonto del pueblo es reusar sin mas las cintas: pongamos que 1 día de copias me lleva 1 cinta y que copio todos los días: pues ya esta: 7 cintas por semana y cada lunes las reuso. Este esquema asi enunciado es una mierda, porque no decirlo, en principio porque en el momento en que machaques la cinta del lunes ya no podrás recuperar los datos del lunes pasado pero claro, quizá solo te exijan retener los datos de hace 4 días, de modo que con este esquema lo estas reteniendo 6 días asi que vas de coña y directo al aumento de sueldo. El problema esta en que Bacula no sabe lo que esta sucediendo entre bambalinas. Para él los datos del lunes pasado no se han machacado, están en una cinta porque en el Catalog le consta que la semana pasada se hizo un Job que involucro a un numero de FileSets y FDs y ahí están todos los atributos de los ficheros que se salvaron… en una cinta que el administrador acaba de sobrescribir cojonudamente y con alevosía. Pero no solo eso, sino que en este plan el Catalog va a crecer indefinidamente: que pasara dentro de 10 años? pues que el Catalog, ajeno a esta artimaña del administrador se piensa que todos los trabajos de copia que hizo en los últimos lustros son recuperables porque la información de cada fichero que se salvo sigue en el Catalog. MySQL puede manejar bases de datos muy gordas pero es estúpido retener metadatos de ficheros que ya no existen en nuestras cintas.

Como se come todo este mogollón? precisamente: definiendo volúmenes y pools y haciéndonos amiguitos de las palabras “Prune” y “Recycle”. Oig chico que bien. Pues vamos allá.

 

Pool y Volúmenes

El administrador de copias ya no va a programar las copias para ser salvadas en el dispositivo “cinta” sino en un Pool. Ese Pool queda referido al dispositivo cinta efectivamente, pero además se enumeran las cintas que se tienen a disposición. Asi un Pool esta formado por Volúmenes (7 cintas por ejemplo) y cada Volumen puede contener un numero indeterminado de Jobs.

Cuantos Jobs por Volumen? o mejor: que tamaño tiene un Volumen? esto se deja a discreción del administrador. Puedes definir un Pool de Volúmenes con un tamaño fijo concreto, o puedes decidir que prefieres que crezcan lo necesario par albergar 3 Jobs por ejemplo (esto con cintas no está muy allá porque las cintas no se estiran y se encogen como las tripas de Jorge, es mas bien para Volúmenes de tipo fichero).

Si utilizas cintas lo normal es indicar el tamaño y listo. Asi, si un Job no entra en una cinta usara mas de 1. No tiene mas dilema.

Cada Volumen de un Pool tiene asociado 1 estado, entre los cuales los mas interesantes son, a saber:

• Append: queda espacio para añadir datos asi que cuando Bacula tenga que iniciar un Job lo usara para añadir datos hasta que se llene.
• Full: lleno, no cabe mas, no se usa, esta petao.
• Purged: Es un volumen lleno pero marcado para su borrado y reciclado. El porque y el cuando todavía no nos interesan, pero cuando Bacula lo necesite lo va a reutilizar, con lo que machacara todos los datox. Ojo: Purged es un volumen candidato a ser borrado, no quiere decir que ya este borrado. Solo se borra cuando Bacula necesite un Volumen y no tenga otro disponible.

Prune y Recycle

Recycle es un verbo que se pronuncia algo asi como “risaiquel” y queda muy bien delante del jefe te lo digo yo. Cuando un Volumen esta marcado como Purged y Bacula necesita uno nuevo para grabar datos lo Recicla: lo borra y lo inicializa para meter mas metralla. En ese momento pasa una cosa muy curiosa, y es que se lanza un Prune (del ingles “tu Pruuun” pon los morritos como si fueras a silbar). Y que es un Prune? pues es un Podado. Es un verbo referido al Catalog y consiste en borrar todas las referencias que haya del Volumen recientemente reciclado. Para que vamos a tener información de Jobs y de FileSets en el Catalog cuando esos ficheros ya han sido machacados y borrados de las cintas? para nada, asi que hacemos un Prune de la base de datos por un lado y un Reciclado del Volumen. Nótese que lo juno va con lo jotro, si no es asi mala papeleta payo.

Ahh pero no escaparse tan pronto mis jóvenes pezqueñines… como se relaciona Purged con Pruned? – me estas tomando el pelo? – No!!!. Ojo al dato que cuando un Volumen se marca como Purged todavía tiene los datos pero Bacula lanza un Prune de todos los Jobs que contenga el Volumen! esta es guapa y yo se que te iba a gustar, por eso te lo he dicho. Y esto que implicaciones tiene? de ello hablaremos a la vuelta de la esquina.

Cuando y como? – Retención!

Lo se, antes hemos estado muy alegres con el asunto ese de los Volúmenes se marcan como purgados pero sin definir cuando. Seria todo un tema que el Bacula te marcaras los Volúmenes como Purged cuando se le saliera de los cojones, seria un tema digno de ser mencionado en tu carta de recomendación cuando Catástrofe extienda sus negros pedúnculos hacia el servidor donde están los datox de la empresa, cargándose el disco duro con su gélido aliento y al echar mano a la copia descubrieras con horror y terror que el Bacula te marco como Purged el Volumen y te lo ha reutilizado con la copia de algo pongamos inocuo y carente de interés para la empresa como puedan ser una sarta de fotos de tías en pelotas del Ernesto Martínez, que por si no lo has notado el apellido le convierte en el vago tocahuevos del hijo del jefe.

En realidad hay muchas maneras de indicar cuando reciclar un Volumen pero todas ellas involucran al termino “retención”. La retención le indica al Bacula cuanto tiempo tiene que mantener los datos. Que datos? todos, a fe mía, ya que puedes definir retenciones relativas tanto al Catalog como a los Volúmenes.

Por ejemplo, podrías decir que quieres conservar cada Volumen por 7 días. Una vez llenos los Volúmenes y al termino de los cuales será marcado como Purged. Este enfoque sin embargo es un poco primitivo si te fijas: a fin de cuentas tu no sabes exactamente que tienes en un Volumen no? quiero decir, q en ese Volumen puedes tener 2 Jobs incompletos (la parte final de uno y el inicio del siguiente). Esto es muy posible si defines los Volúmenes por tamaño fijo aunque puedes definirlos por número de Jobs con lo que no tendrías el problema expuesto. Cual es la estrategia a priori mas inteligente? no aplicar retenciones en Volúmenes sino en Jobs. Como es esto? puedes decir que quieres retener los Jobs por 7 días, eso se traducirá en retener los Volúmenes que impliquen esos Jobs durante 7 días. Tu no sabes que Volúmenes son ni quieras saberlo, eso ya te lo indica el Bacula.

Y por fin… con ustedes el Catalogo

Cerramos la función con una mención al Catalogo, rescatando un fleco que habíamos dejado mas arriba. Hasta ahora las menciones al Catalogo han sido un poco enigmáticas aunque no tiene mucha historia: el Catalogo como ya hemos dicho es una base de datos relacional que contiene todos los Jobs, FileSets y demás información de los backups realizados.

Porque es tan cañero el Catalog? bueno, es que se almacena gran cantidad de información. Date cuenta, por cada Job se almacena el tamaño, la fecha de inicio, de fin, los FileSets, los FD, el scheduler… y no solo eso, sino que se almacena toda la información de cada fichero guardado: fechas, permisos, tamaños, nombre y extensión si la hubiere… todo todito menos los datos en si mismos, que van en el Volumen.

Para que se usa todo este mondongo? bueno, podemos localizar un fichero concreto de un Job concreto y relacionarlo con el Volumen donde se almaceno para recuperarlo. Es asi de potente la cosa: puedes tener cientos de cintas, miles de Jobs que puedes recuperar 1 fichero de forma unívoca.

Retomando el tema de marcar como Purged un Volumen y aplicar el Prune correspondiente al Catalog: los datos todavía los tienes en el Volumen pero la información de los Jobs que en el residen no. Este es uno de los casos en los que el administrador de copias empieza a sudar tinta si se ve en la tesitura de tener que recuperar datos de un Volumen del cual ya no tiene referencia en el Catalog. Hay herramientas que permiten reconstruir un Catalog a partir de un Volumen (lo contrario seria talmente imposible) pero son temas ya demasiado procelosos para ser tratados en esta serie de panfletillos. Sencillamente saber que existe la posibilidad aunque tediosa (se parece al encaje de bolillos). Mas adelante veremos que herramientas son, pero de pasada.

Yo creo que si hasta aqui esta todo entendido, la practica va a ser una pollada, porque no decirlo. Pero eso vendrá en la próxima entrega.

Bacula Vol I

Hoy toca iniciar otra serie de entradas de “divulgación informática” (sin olvidar otras pendientes o en curso, q todo llegará a su debido momento), algo asi como una “Introducción a la gestión de copias de seguridad con fundamento”. La idea es no solo montar un Bacula sino refrescar un poco los típicos conceptos del mundillo de las copias de seguridad para tenerlos bien amarrados y asi poder saltar a otras soluciones con facilidad.

Qué es Bacula y cuándo utilizarlo

Bacula es un software libre que realiza copias de seguridad a nivel de fichero. Punto. Ni es un sistema para hacer imágenes completas ni está´orientado específicamente a restaurar sistemas totalmente descojonados, aunque puede ayudar claro está.

La diferencia fundamental entre el típico scripiti que todos nos hemos currado en bash en algún momento, tirando de herramientas como cp o dd o tar para hacer copias de ficheros, rotarlos y moverlos a otras máquinas, y Bacula son 2 fundamentalmente:

• Bacula mantiene un Catálogo en base de datos donde se registran todas las operaciones realizadas.
• A grandes rasgos Bacula implementa 2 módulos independientes: el Director o programa que gestiona las copias de seguridad, y los agentes, instalados en cada máquina a hacer backup.

Como se verá a lo largo de estos articulillos este esquema está muy simplificado ya que en realidad el sistema permite desgranar sus diversas funciones en otros tantos procesos independientes, de forma que retengamos el máximo control a la hora de hacer el deploy de las diferentes piezas para poder así disponer de un sistema bien balanceado. Si embargo a los efectos puede que sea complicar innecesariamente la solución ya que la mayor parte de la gente solo va a tener 1 servidor de copias y luego n agentes desperdigados por la red, tal y como se muestra en la figura. En este caso concreto la máquina que alberga al Director tendrá también el Catalogo y los sistemas de almacenamiento (típicamente cintas o disco duro) directamente conectados; por la otra parte habrá agentes, uno en cada servidor que vayamos a copiar.

Sobre las plataformas soportadas solo decir que el agente funciona tanto en el mundo Windows como Linux o Mac pero el Director solo rula Linux que yo sepa. No voy a tratar temas concretos de Sistemas Operativos en esta serie de artículos asi que mas o menos y con las salvedades típicas en este mundillo (Unidades, ACLs etc) , todo lo que se diga es “SO independendent”.

Tampoco se verán temas específicos de cintas: se trata de visualizar un poco el tema de forma general concretando para un caso particular y dando las herramientas necesarias para poder retorcer la configuración a nuestro gusto, ampliando la lectura de lo aqui expuesto, y no de resolver “porque mi distro no me detecta la cinta de marca tal”.

Procesos

Vamos a poner nombre y función a los procesos que intervienen en este tinglado aunque por la figura de arriba bien se pueden intuir cuales van a ser:

• Director: es la madre del cordero. Podemos pensar en el Director como en un director de orquesta y en un router de datos: dice cuando hacer las cosas, obtiene los resultados y los manda a los procesos necesarios.
• File Daemon (FD): Es el Agente de la figura: un proceso que corre en el servidor del que vamos a hacer la copia. Recibe ordenes del Director, inicia las copias y se las pasa a éste.
• Console: no esta representado en la figura, es un proceso que se conecta al Director para administrar el servicio. Hay varios tipos de consola soportados pero aqui se usara el principal, la consola de línea de comandos, que es la mas completa de todas las opciones.
• Storage Daemon (sd): Es el proceso que maneja los medios de almacenamiento. Normalmente van a estar conectados al Director pero podría ser que tuviéramos un servidor externo conectado a una cabina de discos, o de cintas. Este proceso recibe los datos y los vuelca en los medios definidos.
• Catalog: es un proceso que interactúa con la base de datos que contiene el catalogo. Típicamente también va en la maquina que alberga el proceso Director pero puede ir en una independiente. El Catalogo será explicado mas adelante, pero para ir afinando diré que es una base de datos donde quedan grabados todos los procesos de copia y la información de todos los ficheros que lo componen, con su fecha y hora, tamaño de cada fichero y de la copia completa, lugar donde se restauran, lugar donde se almacenan físicamente etc. Es una especie de índice de todo lo que va ocurriendo. Ojo que no contiene los datos, los ficheros en si mismos. La consola entonces es, en esencia, un traductor o front-end de la base de datos formado en base a comandos más o menos amigables, generando las sentencias Select necesarias sobre esa base de datos y recabando y formateando los resultados. El catalogo en si mismo puede estar almacenado en MySQL, SQLite o PostGreSQL. Aqui se usara MySQL aunque para volúmenes muy bajos de datos quizá valga con SQLite.
• Monitor: tampoco queda reflejado en la figura anterior y de hecho este modulo no lo vamos a tocar. Solo funciona en GTK+ asi que lo suyo seria instalar unas X en el Director (cosa que no haremos) para poder ejecutar ese programa, que nos reporta de forma grafica el estado de las copias y el de cada uno de los procesos aqui descritos.

En resumen: tenemos un Director que pide datos a los FD y los manda al SD que los graba en el medio de almacenamiento definido. A su vez el Director envía datos de carácter informativo (algo asi como MetaDatos) al Catalog que los escribe en el motor de base de datos de nuestra elección. Y de regalo tenemos una consola que se conecta al Director para ver el estado de las copias, listar su contenido etc.

Conceptos y términos

A continuación indico los conceptos fundamentales sobre los que descansa todo el entramado. Esto no solo hay que tenerlo claro sino que hay que manejarlo con soltura. Primero lo suelto a zorrombollón y luego desgrano un poco.

“Una copia de seguridad esta formada por una serie de Jobs de varias Clases y Tipos, que involucran diferentes FileSets obtenidos de uno o mas FDs, grabados en uno o mas Pools de Volúmenes ejecutados según se defina en un Schedule.”

El Job o Trabajo define practicamente todo lo necesario para empezar a funcionar en Bacula:

1. El “Qué” se copia: Se copia el resultado de aplicar un FileSet (definiciones de grupos de ficheros, con inclusiones y exclusiones de directorios, tipos de archivos por extensión etc)
2. El “De Donde” se copia: Los datos se obtienen de aplicar un FileSet a uno o varios FDs (File Daemon, los agentes instalados en los servidores a copiar)
3. El “Cuando”: el Scheduler indica que días, a que horas y con que periodicidad se lanzan los Jobs.
4. La Clase del trabajo: restauración, backup o verificación.
5. El Tipo: Completa, incremental, diferencial.
6. El “Hacia Donde se copia”: donde se dejan las copias. En primera instancia se envían al SD (Storage Daemon) pero además se indica la agrupación de medios de almacenamiento (Pool formado por Volúmenes) donde se dejaran los datos: típicamente un grupo de 7 cintas para hacer el rotado diario, un grupo de 4 cintas para el semanal etc…

En resumen: tenemos una copia de seguridad formada por el  Job “copia webs” de clase “backup” y de tipo “Full” (copia completa), que se conecta al FD “servidor Web” con un FileSet que incluye  el directorio local al servidor web “/var/html/” del que sacara todos los ficheros a copiar, dejando los datos en el Pool “Webs” formado por 7 Volúmenes (cintas) llamadas “Copia-x“, donde x será la fecha de la copia, que el Scheduler lanzará a la 1 de la mañana todos los días.

Un diagrama complementario podría ser el siguiente:

Vemos al Director recibiendo los ficheros a hacer backup desde los File Daemon (lo que se copia de cada File Daemon se define en un FileSet o set de ficheros), enviando la información del Job al Catalogo (que puede ser un servidor externo con MySQL o el mismo Director), recibiendo instrucciones del cuando hacer la copia por parte del Scheduler y enviando los ficheros al Storage Daemon que en este caso tiene una única unidad de cinta conectada y el Pool “1” definido, que consta de 2 Volúmenes, de tipo cinta, que el administrador del sistema cambiara cuando el Bacula se lo pida.

Prácticamente esto es todo lo necesario para empezar a trabajar con Bacula; no obstante en la próxima entrega ampliaremos un poco mas algunos de los conceptos vistos, ya que hay cosas como los Pools, los Volúmenes y su reciclado o el mismo Catalogo que merecen ser bien tratados.

Tantos tontos y tan pocas balas…

Hace tiempo que quería poner esta pataleta por escrito y hoy es un día mejor que cualquier otro porque he sido testigo de una forma de incompetencia estado casi solido, por parte de algunos compañeros de profesión.

“Incompetencia” es una palabra sobrevalorada y sobredimensionada ante todo: en realidad lo único que quiere decir es “falta de competencia” y asi la utilizo yo aqui a pesar del titulo de esta entrada (que lo uso unicamente porque siempre me hizo gracia esa frase y no porque este llamando gilipollas a media empresa). A fin de cuentas la falta de competencia es algo que se puede suplir con estudio si hay capacidad de autocritica y voluntad.

Tejidos los prolegómenos vamos a lo que vamos, aunque sobre faltas de competencia volveremos graciosamente casi al final, si las cosas en esta entrada siguen su cauce y todo sale como esta previsto.

Que ha pasado? o mejor, que esta pasando? pues facil amiguitos, en la mía empresa donde trabajo para no llegar a final de mes como informatico mileurista de pacotilla (esto es un pleonasmo en realidad) estamos como locos implantando una metodología para el desarrollo de software. Hay que decir que mi empresa es grande de cojones, tiene presencia en varios países y lleva a cabo multitud de desarrollos mas o menos afortunados (mas menos que mas, a fe mía); lo que quiero decir con esto es que no somos 4 y el del tambor dedicados a reparar impresoras. Que sucedía hasta ahora? en esencia: no había una metodología clara de desarrollo ni de gestión. Ese cumulo de procesos que suele caer en el saco que llaman “Ingeniería de Software” no existía como tal, de ahí que conceptos como “análisis de requisitos”, “diseño técnico”, “pruebas de regresión” y todas esas cosas no existían en el estricto modo en que existen las cosas en el mundo real: esto es, hay analistas pero no se sabe muy bien que hacen, los diseños técnicos los hace el mismo que va a programarlos y el arquitecto es un tío que no sabe ni de donde viene ni a donde va, y lo que es peor: no sabe el tiempo que le queda. Con esto quiero decir que aunque los gerifaltes usaban los términos con enorme grandilocuencia y gran refocile cuando se conectan a Matrix para hacerse sus simulaciones particulares (aka pajas mentales), en el mundo real no pasaban de ser palabras huecas y conceptos extraños y sin sentido. Al final todo era bastante desastroso y en tiempo de codificación podía cambiarse la funcionalidad de arriba a abajo varias veces porque no se pensó lo mas mínimo si aquello encajaba con el resto o en que manera lo hacia… o si realmente era útil… o si realmente era lo que pedía el cliente… o si o si o si…

Y ahora viene cuando la matan porque se ha pedido ayuda a una empresa externa que se dedica a estos menesteres y claro, han flipado (como no, también tienen que comer los pobrecillos) y han definido una serie de procesos bastante exhaustivos para pilotar todo el proceso de desarrollo, desde el documento de Visión hasta el despliegue del producto ya terminado y todo el mondongo. Entonces es cuando los incompetentes que han vivido de cojones apoltronados en sus asientos rascándose el inglete y pagados de si mismos pensando que su palabra era misa y su inmaculada sabiduría iluminaba el tormentoso camino de los pobres desgraciados que nos arrastramos por el suelo escupiendo líneas de código como escarabajos pelotilleros… como digo, esta suerte de pseudo trabajadores  salen a la luz empezando a matizar, a ponderar, a valorar, a cuestionar en definitiva el procedimiento sugerido, en aras de una mayor “practicidad”; porque claro, eso que te han dicho que porque cojones se hace tan mal y desde hace tanto tiempo ya lo sabían ellos, como no, date cuen.

Concretamente el bacalao ha venido sobre la “interpretación” que este grupo de personas da al documento que recoge lo que tiene que hacer la aplicación y que recibe el bonito nombre de “especificación de requisitos”. Hay una serie de reglas que hay q cumplir para que una especificación de requisitos sea tal, como hay una serie de reglas a cumplir para que una carrera en apariencia desordenada por parte de 22 personas en pijama y en pos de una esfera, se pueda llamar futbol. Pues no oyes, que la especificación de requisitos es una cosa abierta al debate, a la interpretación. A los efectos puede ser una letrina donde todo tiene cabida en favor del pobre programador pelotero que no se albarda de nada: novelas escritas por el comercial justificando la inclusión o exclusión de tal necesidad, dibujos del departamento de diseño para aclarar las cosas (dibujos que rápidamente se quedan desfasados y no se molestan en remendar porque cuesta pasta), recortes de la wikipedia para las partes técnicas, mails entre los arquitectos para aclarar las cosas… un vergel en toda regla, un caos, una puta bacanal orgiástica de tecnicismos indigestos que el programador observa con cara de pueblo. Entonces intentas explicar como tiene que ser una especificación de requisitos ante la plana y te das cuenta de que estas solo. Mas solo que lo que estuviste cuando llegaste a este mundo y mas solo de lo que estarás cuando toque abandonarlo, por viejo y por pellejo.

Y estas solo porque el 95% de los puestos de dirección o de gestión están copados por físicos, matemáticos, industriales o telecos. Cuando mas arriba es el puesto de gestión mas físicos, industriales o economistas. Cuanto mas abajo mas telecos. Informáticos pocos o ninguno aunque sean mayoría picando código. Si habéis intentado explicarle a un teleco o a un físico qué es una especificación de requisitos y no han tratado el tema antes, entenderéis lo que digo. No estoy hablado de falta de capacidad, por supuesto que no, no hay que ser ningún superdotado o haberse chupado una carrera de 5 años mas prorrogas para saber hacer una especificación de requisitos mínimamente decente. Es sencillamente ignorar la existencia y desdeñar por sistema la importancia de las cosas que se ignoran. Es no saber lo que no se sabe y además, importarles un huevo porque si algo relativo a la informática no lo conocen es que no es importante. Si lo fuera ya lo dominarían. Es la incompetencia en estado puro y duro; relativa, porque pueden ser unos hachas en sus cosas (o incluso programando!) pero en lo que aqui concierte la palabra que me viene a la mente es  “vergonzoso”. Y como son mayoría es como para plegar la oreja y subirse las mantas hasta la cabeza.

Pero lo mejor de todo es que los únicos que tienen competencias a día de hoy en informática son… los telecos! tócate el fofete! claro, nuestro menistro/a alega que la informática es una ciencia “transversal” y claro, no ha lugar asignar competencias para esa panda de muertos de hambre que están todo el día con sus chuminaditas de análisis – diseño y demás zarandajas que no van a ningún lado.

En total, que esto no hay quien lo arregle. La verdad es q no se porque el tema me molesta tanto; a fin de cuentas la informática es una puta mierda bien gorda donde nada funciona como debe: te instalas la ultima Ubuntu y lo primero que hace es descargarse 200 megas de parches y la gente se cooooorrre de gustoooo. “Tengo el sistema al día!” Lo mismo pasa con Windows pero peor: reiniciar 37 veces, actualiza el sistema de actualizaciones, parchear el parcheador de parches… ahora te coloco el historial del navegador aqui pero tranquilo que en la próxima versión te lo coloco allá y asi te entretienes buscándolo; y si hoy la config de ethernet esta en /etc/network/interfaces tu tranquilo, no te pongas nervioso que mañana te la ponemos en ifcfg-ethx como antaño o te cambio el inittab o te toco los cojones, que de eso sabemos un ratillo.

Y asi vamos tirando.