Gestion de Backups mediante solucion Open Source 4
91
Me voUNIVERSIDAD TECNOLÓGICA DE CHILE ÁREA DE TELECOMUNICACIONES, CONECTIVIDAD Y REDES Gestión de Backups Mediante Solución Open Source Cristián Aguilera Urbina 2011 1
-
Upload
carloko-sanchez -
Category
Documents
-
view
1.404 -
download
4
Transcript of Gestion de Backups mediante solucion Open Source 4
Me voUNIVERSIDAD TECNOLÓGICA DE CHILE ÁREA DE TELECOMUNICACIONES, CONECTIVIDAD Y REDES
Gestión de Backups Mediante Solución Open Source
Cristián Aguilera Urbina
2011
1
UNIVERSIDAD TECNOLÓGICA DE CHILE ÁREA DE TELECOMUNICACIONES, CONECTIVIDAD Y REDES
Gestión de Backups Mediante Solución Open Source
Trabajo de Titulación presentado en conformidad a los requisitos para obtener el Título de Ingeniero en Conectividad y Redes.
Wilson Araya Vargas
Cristian Aguilera Urbina
2011
2
Agradecimientos
“A los que me brindan seguridad con todas sus dudas, gracias”
Agradezco a mis padres, familia y amigos por el apoyo incondicional y constante
en el desarrollo de mi educación.
3
Resumen
4
Tabla de Contenidos
Capítulo I Introducción...........................................................................7
1.1. - Origen Del Problema.............................................................................................................7
1.2.- Alternativas de Solución.........................................................................................................8
1.3.- Breve Descripción del Proyecto..............................................................................................8
1.4. - Objetivo General...................................................................................................................9
1.5.- Objetivos Específicos............................................................................................................11
1.6.- Fundamentación Teórica......................................................................................................11
1.7.-Contribución Esperada..........................................................................................................12
1.8.-Metodologia de Trabajo........................................................................................................12
Capítulo II Sistemas Operativos Linux.................................................13
2.1.- Que es Linux.........................................................................................................................13
2.2. - Que es Unix.........................................................................................................................14
2.3. - Diseño de Unix....................................................................................................................14
2.4. - Que es el Proyecto GNU......................................................................................................17
2.5.- Que es una distribución GNU/Linux.....................................................................................17
2.6.- Árbol de Directorios o Sistemas de Archivos de GNU/Linux.................................................18
Capítulo III Sistemas de Respaldo de Datos.......................................20
3.1.- Que es un Backup.................................................................................................................20
3.2.- Riesgos en Sistemas de Información....................................................................................21
3.3.- Tipos de Respaldos...............................................................................................................22
3.4.- Software para copias de seguridad......................................................................................23
3.5.- Estandarización....................................................................................................................24
Capítulo IV Bacula...............................................................................27
4.1.- Que es Bacula.......................................................................................................................27
4.2.- Componentes de Bacula.......................................................................................................30
4.3.- Funcionamiento de Bacula...................................................................................................35
4.4.- Características fundamentales de Bacula.............................................................................36
5
Capítulo V: Instalación de Bacula y Configuración de los Elementos
Necesarios...........................................................................................37
5.1.- Generalidades de Bacula......................................................................................................37
5.2.- Primer paso de la instalación...............................................................................................37
5.3.- Instalación de Bacula director..............................................................................................38
5.4.- Instalación de Bacula Storage..............................................................................................40
5.5.- Instalación de Bacula File.....................................................................................................41
5.6.- Instalación de la Consola de Bacula......................................................................................41
5.7.- Instalación de Bacula Client.................................................................................................42
Capítulo VI.- Configuración y Administración de Bacula.....................45
6.1.- Generalidades de configuración...........................................................................................45
6.2.- Configuración de Bacula director.........................................................................................45
6.3.- Configuración de Bacula File Daemon..................................................................................52
6.4.- Configuración de Bacula Storage Daemon...........................................................................53
6.5.- Administración.....................................................................................................................56
Capítulo VII Pruebas Técnicas de Rendimiento..................................61
7.1.- Objetivo del capitulo............................................................................................................61
7.2.- Laboratorios de trabajo........................................................................................................61
7.3.- Mediciones de consumo de hardware y red........................................................................65
Capítulo VIII Conclusiones..................................................................72
8.1.- Conclusiones parciales.........................................................................................................72
Bibliografía...................................................................................................................................73
6
Capítulo I Introducción
1.1. - Origen Del Problema
Hoy en día las empresas manejan una cantidad sustancial de información
que finalmente se traduce en la base del buen funcionamiento de la misma es por
eso que una de las tareas más importantes que debe realizar un administrador de
sistemas es el de realizar copias de seguridad de forma periódica y además que
estas sean generadas de forma correcta, otra cosa importante es que estas se
puedan restaurar fácilmente. Sin embargo muchos administradores dejan de lado
estas tareas o las realizan a través scripts complejos que carecen de la flexibilidad
que otros programas puedan otorgar.
En un estudio realizado por la compañía Imation el año 2009, realizado a 200
gerentes en TI, ha obtenido que tan solo una de cada tres empresas realizaba
pruebas a su sistema de copias de copias de seguridad trimestralmente, un 32 % ,
y otro 35 % solo lo hacia una vez al año, por otro lado en su sexto año el estudio
2010 sobre recuperación ante desastres, auspiciada por Symantec, para destacar
las tendencias empresariales relacionadas con la planificación y la preparación de
la recuperación ante desastres a nivel mundial en donde se encuestaron a mas de
1700 administradores de TI de grandes organizaciones de 18 países incluidos
Estados Unidos, Canadá, Brasil, Chile, Colombia y México se destaca que en
Latinoamérica los encuestados afirman que solo el 51 por ciento de las copias de
seguridad se lleva a cabo solo de forma semanal o incluso con una frecuencia
menor, en vez de hacerlo diariamente, eso es menor al promedio global de 82 por
ciento.
La solución Open Source en la que se basara este trabajo permite a los
administradores encargarse de sus respaldos de información de una forma
agradable, flexible y eficaz.
7
1.2.- Alternativas de Solución
Existen muchas soluciones de código abierto para realizar las tareas de
backups, tenemos Bácula, Amanda, Tar, Cpio, Afio, BackupPC, Cobian Backup,
entre otras.
Para este proyecto se ha optado por la implementación de Bácula, debido a su
alto grado de eficiencia y funcionalidad ya que este sistema entrega una serie de
herramientas que permiten al administrador efectuar respaldos, recuperación y
verificación de datos en una red con computadoras de diferentes clases.
1.3.- Breve Descripción del Proyecto
Como primera instancia se realizará una etapa de investigación de las
diferentes alternativas que provee una herramienta Open Source tanto en su
implementación como en su configuración, se hará un análisis de los
requerimientos de software, hardware y requerimientos de red necesarios para su
buen funcionamiento, se analizarán las ventajas y desventajas que puede llegar a
tener el trabajar con software Open Source.
Una vez terminada esta etapa se procederá a la implementación del proyecto en
sí, primero creando una maqueta de pruebas necesaria para el desarrollo del
proyecto, luego en la instalación del software, configuración de los parámetros y
requerimientos a utilizar y finalmente en el análisis de datos obtenidos para así
poder llevar a cabo en el futuro, tomando en consideración el resultado obtenido,
una implementación a mayor escala.
8
1.4. - Objetivo General
Implementar un sistema de respaldo de datos basado en una plataforma de
aplicación y sistema operativo Open Source y realizar pruebas de rendimiento en
términos de tráfico, recursos de red y procesamiento.
Figura 1.1 Principales componentes de Bácula Fuente: www.bacula.org
9
Figura 1.2 Esquema general Bacula
Fuente www.luizgustavo.pro.br/blog/2009/09/30/bacula-breve-introducao/
Bacula en general consta de dos módulos: el Director que es el encargado de
administrar las copias de seguridad y los Agentes instalados en los equipos que se
quieren respaldar.
10
1.5.- Objetivos Específicos
-Preparar hardware necesario.
-Adquirir software a utilizar.
-Instalar software tanto servidor como en computadoras a respaldar.
-Realizar configuraciones necesarias para el funcionamiento de Bácula.
-Verificar correcto funcionamiento de respaldos
-Implementación de servicios en servidores para este proceso.
-Implementación de los laboratorios de prueba.
-Medición de tiempo y uso de CPU y memoria de procesos asociados al
respaldo.
-Medición de uso de ancho de banda utilizada por sistema de respaldo
mediante herramientas de monitoreo de red.
1.6.- Fundamentación Teórica
Se utilizará una metodología analítica de investigación, la cual se basará en
la realización de pruebas, se construirán hipótesis, se testearan las hipótesis
mediante pruebas, se analizaran los resultados y se expondrán conclusiones del
tema.
Como norma de trabajo se respetaran las RFC de los protocolos correspondientes
al sistema de respaldo y se expondrán o detallaran datos de las mismas en el
trabajo.
11
1.7.-Contribución Esperada
Con el siguiente proyecto se espera llegar a conocer y comprender las
tecnologías open source existentes para el respaldo de información ya sea a nivel
personal o en el futuro a nivel profesional, ya que como administradores de red o
de sistemas una de las labores será efectivamente manejar de forma eficiente la
gestión de la información, con este tipo de herramientas de gestión centralizada de
backups podremos llevar a cabo este tipo de tareas de una manera ordenada.
También se pretende demostrar la importancia de la implementación de un
sistema de gestión backups dentro de una empresa en donde los datos que se
manejan tienen suma importancia respecto a la eficiencia y seguridad de estos.
1.8.-Metodologia de Trabajo
-Pautas de trabajo acorde a la carta Gantt con plazos estipulados para cada
proceso.
-Recopilación de información de internet
-Selección de información importante
-Entrevistas programadas con administradores de red
-Entrevistas con usuarios que operan bajo un sistema de respaldo de datos.
-implementación de servicios en servidores virtualizados
-Pruebas, mediciones y análisis en laboratorios.
12
Capítulo II Sistemas Operativos Linux
2.1.- Que es Linux
Linux es un sistema operativo así como muchos otros existentes (Windows,
Solaris, Mac OS), este fue creado por un estudiante finlandés de informática, Linus
Torvalds perteneciente a la Universidad de Helsinki en Finlandia y que publicó su
código fuente en el año 1990, esto como una opción a los sistemas Unix que
existían en ese tiempo.
GNU/Linux como también se le llama es un sistema que se basa en Unix, es
multiusuario y multitarea esto significa que permite proveer servicio y
procesamiento a múltiples usuarios simultáneamente. Linux es una buena
alternativa frente a otros sistemas operativos, ya que más allá de las ventajas
evidentes de costo, ofrece algunas características de mayor distinción en
comparación con las otras versiones de Unix para PC, la velocidad y confiabilidad
de Linux son mayores. También está en ventaja sobre la disponibilidad de
aplicaciones, ya que no hay mucha difusión de estos otros Unix (como Solaris,
XENIX o SCO) entre los usuarios de computadoras por sus altos costos.
Componentes de Linux
Linux se compone de forma general por cuatro componentes principales: el
núcleo (kernel), el shell, el sistema de archivos y las utilidades.
-El núcleo: Es un software que tiene la funcionalidad de gestionar los recursos de
hardware para que los distintos programas tengan acceso a este.
-El shell: Proporciona una interfaz para el usuario. Recibe órdenes del usuario y
las envía al núcleo para ser ejecutadas.
-El sistema de archivos: Organiza la forma en que se almacenan los archivos en
dispositivos de almacenamiento, tales como los discos. Los archivos están
13
organizados en directorios. Cada directorio puede contener un número cualquiera
de subdirectorios, cada uno de los cuales puede a su vez, contener otros archivos.
2.2. - Que es Unix
Unix es el núcleo de un Sistema Operativo de tiempo compartido; un
programa que controla los recursos de una computadora y los asigna entre los
usuarios. Permite a los usuarios ejecutar sus programas; controla los dispositivos
periféricos (discos, terminales y otros) conectados a la máquina.
Unix no sólo abarca el núcleo, sino que incluye también programas esenciales,
entre ellos: compiladores, editores, programas para copiado, entre otros.
Linus se basa sobre Unix
Se basa en una característica, este sistema operativo sería Software Libre,
esto significa que una vez que el usuario compra un CD o bien lo descarga
gratuitamente desde Internet, es libre de redistribuirlo y modificarlo de acuerdo a
sus necesidades, siempre que, como lo indica la Licencia Pública General GNU -
acrónimo de "GNU is Not Unix", del modo que ha dispuesto la Free Software
Foundation, se incluya el código fuente. Esto también incluye derecho a poder
instalar Linux en cualquier número de ordenadores o equipos de cómputo que el
usuario desee.
2.3. - Diseño de Unix
Si se habla de la arquitectura de Linux/Unix los conceptos centrales en el
modelo del sistema son los archivos y los procesos. En la siguiente figura se
observa un diagrama de bloques del kernel, mostrando varios módulos y las
relaciones entre ellos. En particular, se muestra el subsistema de archivos en la
parte izquierda y el subsistemas de control de procesos en la parte derecha, los
dos mayores componentes del Kernel.
14
Figura 2.1 Arquitectura de Linux
Fuente:http://4.bp.blogspot.com/_1TVvt-tRs/Rdo50aoeX6I/AAAAAAAAABQ/lPUumCuUUiA/s1600-
h/diagrama.jpg
Esta figura muestra tres niveles: usuario, Kernel y hardware. Las llamadas al
sistema y las librerías representan entre los programas de usuario y el Kernel. Las
llamadas al sistema son parecidas a las funciones en los programas en C y las
librerías trasforman estas funciones a las primitivas necesarias para entrar en el
sistema operativo. Los programas en lenguaje ensamblador deben invocar a las
llamadas al sistema directamente sin las librerías de las llamadas al sistema.
Las llamadas interactúan con el subsistema de archivos y con el subsistema de
control de procesos. El subsistema de archivos controla los archivos, asigna
espacio a los archivos, administra el espacio libre, controla el acceso a los
archivos, etc. Los procesos interactúan con el subsistema de archivos mediante un
específico conjunto de llamadas al sistema.
15
El subsistema de archivos accede a los archivos de datos usando un mecanismo
de buffer que regula el flujo de datos entre el Kernel y los dispositivos de
almacenamiento secundario. El mecanismo de búffer interactúa con los
controladores de dispositivos de E/S de tipo de bloque para iniciar las
transferencias de datos desde y hacia el Kernel.
El subsistema de procesos es el responsable de la sincronización de los procesos,
la comunicación entre procesos, administración de memoria principal y la
planificación de procesos. Tanto el subsistema de archivos y el subsistema de
procesos interactúan cuando se carga un archivo en memoria para su ejecución.
El módulo de administración de memoria controla la asignación de memoria. Si en
algún momento no hay suficiente memoria física para todos los procesos, el
Kernel los mueve entre la memoria principal y la secundaria.
El módulo de planificador o sheduler asigna la CPU a los procesos. Planifica los
procesos para ser ejecutados por turno hasta que voluntariamente liberen la CPU
mientras esperan un recurso o hasta que el Kernel los saca cuando su tiempo de
ejecución supera el tiempo cuantum
Finalmente, el control de hardware es el responsable de las interrupciones y de las
comunicaciones con la máquina. Los dispositivos como los discos o terminales
pueden interrumpir a la CPU mientras un proceso se está ejecutando. Así, el
Kernel debe restablecer la ejecución del proceso interrumpido después de servir a
la interrupción.
16
2.4. - Que es el Proyecto GNU
El proyecto GNU, fue iniciado por Richard Stallman y fue lanzado en 1984,
con el objetivo de crear un sistema operativo libre completo tipo UNIX, el sistema
GNU.
Las variantes del sistema operativo GNU que utilizan el núcleo llamado Linux, son
utilizadas ampliamente en la actualidad; aunque a menudo estos sistemas se
refieren como “Linux”, la manera correcta de llamarlos es sistemas GNU/Linux
GNU es un acrónimo recursivo para "GNU No es Unix" y se pronuncia
fonéticamente en español.
2.5.- Que es una distribución GNU/Linux
Una distribución Linux o GNU/Linux, es un conjunto de aplicaciones
reunidas en torno al núcleo del sistema, que permiten brindar mejoras para instalar
fácilmente un sistema Linux o GNU/Linux. Son “sabores” de Linux que en general,
se destacan por las herramientas para configuración y sistemas de paquetes de
software a instalar. Entre las distribuciones más conocidas pueden citarse a:
Figura 2.2 Debian GNU/Linux Figura 2.3 Fedora
Fuente imágenes google Fuente imágenes google
17
Figura 2.4 Kubuntu Figura2.5 SuSe Linux
Fuente imágenes google Fuente imágenes google
Figura 2.6 Ubuntu
Fuente imágenes google
2.6.- Árbol de Directorios o Sistemas de Archivos de GNU/Linux
Las distribuciones GNU/Linux tienen muchos directorios, cuyos nombres
probablemente no resulten familiares. Estos directorios están organizados en
forma de árbol y todos ellos parten del directorio raíz (/).
En GNU/Linux, todo tiene su reflejo en algún archivo o en algún directorio del
sistema de archivos.
Desde el punto de vista del usuario, en GNU/Linux existen dos tipos de directorios:
los directorios del sistema y el directorio del usuario.
18
Dicho de una manera sencilla, un sistema de archivos es más o menos "la forma
de escribir los datos en el disco duro". Es importante conocer ésta estructura para
la correcta administración del sistema y la resolución de problemas.
A continuación se muestra la estructura de los directorios más importantes dentro
de un sistema operativo GNU/Linux:
1. /: Raíz del Sistema.
2. /bin: Es la abreviación de "binaries", o ejecutable. Es donde residen la mayoría
de los programas esenciales del sistema.
3. /etc: Contiene una serie de ficheros de configuración del sistema GNU/LINUX.
19
Capítulo III Sistemas de Respaldo de
Datos
3.1.- Que es un Backup
Hacer un backup o copia de seguridad consiste en guardar en algún tipo de
medio extraíble la información crítica que existe en un sistema, ya sea información
de los usuarios en los computadores o en servidores.
El objetivo principal de realizar estas copias de seguridad es tener la capacidad de
asegurar la recuperación de los datos ante posibles pérdidas o catástrofes. Esta
capacidad para la mayoría empresas se convierte en algo de suma importancia,
incluso algo crítico para las empresas debido a la creciente cantidad de
información con que se trabaja hoy en día.
Una copia de seguridad, en su adaptación más simple y como su propio nombre
indica, es una réplica de cierta información, sin ningún tipo de arreglo sobre la
misma (compresión, etc). Dicho duplicado debe almacenarse en un medio distinto
al que se encuentra la información original, ya que si hubiera algún inconveniente
en el medio donde se encuentra almacenada la información original (rotura, robo,
fallo software, etc) el backup realizado no serviría en absoluto.
Los medios donde se pueden hacer estos backups pueden ser un disco duro
externo, un CD-ROM grabable, cintas de datos, discos ZIP o JAZ o magneto-
ópticos.
Se pueden clasificar las copias de seguridad en 2 grandes grupos:
20
-Copias de seguridad del sistema, cuyo objetivo es la recuperación y arranque de
un sistema informático tras un desastre en el cual se almacenaran copias de los
ficheros de software de base y software de aplicación.
-Copias de seguridad de datos, cuyo objetivo es la recuperación de los datos ante
eventuales pérdidas ocurridas por algún incidente.
3.2.- Riesgos en Sistemas de Información
Como es sabido la información y los datos son de vital importancia para los
negocios. Sin embargo lo que sucede en la mayoría de los casos es la falta de
precauciones que se suele tener al confiar al núcleo de los negocios al sistema de
almacenamiento de lo que en la mayoría de los casos resulta ser una
computadora pobremente armada tanto del punto de vista de hardware como de
software.
Si el monitor, la memoria e incluso la CPU del computador dejan de funcionar, se
pueden reemplazar y no hay mayores dificultades. Pero si falla el disco duro, el
daño puede ser irreversible, puede significar la pérdida total de información. Es
principalmente por esta razón, por la que debemos respaldar la información
importante. Ahora si esto le sucediera a una empresa, las pérdidas económicas
podrían ser enormes. Los negocios de todos los tipos y tamaños confían en la
información digitalizada para facilitar su ejercicio. La pérdida de información
provoca un daño de fondo como pérdida de oportunidades de negocio, clientes
decepcionados, reputación perdida, entre otros.
La tecnología no está libre de errores, y los backups son utilizados como un
procedimiento de contingencia en caso de que una falla o error se presente.
Las interrupciones informáticas se presentan de diferentes formas tales como:
virus informáticos, fallos de electricidad, errores de hardware y software, caídas de
red, hackers, errores humanos, incendios, inundaciones y muchas más. Y aunque
no se pueda prevenir cada una de estas interrupciones, la empresa sí puede
prepararse para evitar las consecuencias que éstas puedan tener sobre su
21
negocio. Del tiempo que tarde en reaccionar una empresa dependerá la gravedad
de sus consecuencias.
Figura 3.1 Grafico de errores más comunes
Fuente www.ignaciomarcos.com.ar/index.php/2007/03/21/mtodos-de-backup-primera-parte/
Como se menciona anteriormente las interrupciones informáticas se pueden
presentar de distintas maneras, este grafico muestra la distribución de los errores
más comunes que se pueden producir donde se aprecia que los errores más
comunes son los de hardware, seguidos por los errores humanos.
3.3.- Tipos de Respaldos
Existen diferentes tipos de respaldos, los que mayormente se aplican sobre
la información crítica o la información de mayor relevancia para los usuarios, los
principales son:
-Backup Completo, el cual consiste en realizar una copia completa de toda la
información principal, por lo cual se requiere una mayor capacidad de espacio de
almacenamiento y tiempo de backup.
-Backup Incremental, con este tipo de backup se copian solamente los datos que
hayan sido modificados con respecto a otro backup incremental anterior, o bien un
backup total si este no existe. Este tipo de backup no sustituye a los anteriores.
Para restaurar un backup incremental es necesario restaurar el backup completo y
todos los backup incrementales por orden cronológico que estén implicados. Si se
22
pierde uno de los backup incrementales, no es posible restaurar una copia exacta
de los datos originales.
-Backup Diferencial, en este tipo de backup se copian solamente los datos que
hayan sido modificados con respecto a un backup completo anterior, requiere
menor espacio de almacenamiento y menor tiempo para su ejecución, para poder
restaurar este tipo de backup es necesario primeramente restaurar el backup
completo en el que está basado, por lo tanto requiere mayor tiempo de
restauración, un backup diferencial puede reemplazar a otro backup diferencial
más antiguo sobre el mismo backup completo.
3.4.- Software para copias de seguridad
En el mercado existe una gran cantidad de software para realizar copias de
seguridad, sin embargo para poder realizar una buena elección primeramente se
deben definir las necesidades requeridas para determinar el software adecuado a
implementar.
Dentro de los más conocidos se encuentran ZendalBackup, Cobian, SeCoFi,
CopiaData y NortonGhost, Arecabackup, fwbackups, Bacula, Amanda, cada uno
con características distintas y adaptados a las necesidades de cada usuario.
El Backup es la mejor manera de resguardo de datos críticos, pero hay que tener
en cuenta la probabilidad de que la copia de datos no haya funcionado
correctamente y en caso de necesidad de restauración de los datos se pueda
realizar ya que la información de la copia de seguridad puede encontrarse corrupta
por diversos motivos: el medio en el que se efectuaba la copia se encuentra
dañado, los automatismos de copia no se han ejecutado correctamente y muchos
otros motivos que pueden causar que los backups sean erróneos, y por lo tanto
inservibles.
23
Para evitar esto es importante cerciorarse de que se hacen las copias
correctamente y comprobar que se es capaz de restaurar la copia de seguridad a
su ubicación original.
En el caso teórico de que no se pueda restaurar la información, existe una última
alternativa, ya que en el mercado existen aplicaciones de recuperación de datos
que pueden ayudar en caso de que no se pueda restaurar una copia de seguridad,
como son: Advanced File Recovery , diskdoctors, RecuperaData y stellar. También
existen métodos de recuperación de datos vía web, como e-ROL y por último, y en
casos extremos como unidades dañadas, sólo nos quedaría recurrir a un
laboratorio especializado en la recuperación de datos, como RecoveryLabs
3.5.- Estandarización
Existen diversos criterios de evaluación de la seguridad, internos a una
organización, sectoriales, nacionales e internacionales entre otros y para estos un
variedad de estándares aplicables a diferentes niveles TCSEC (Trusted Computer
Security, militar, US, 1985), ITSEC (Information Technology Security, Europeo,
1991), Common Criteria (Internacional, 1986-1988), *7799 ( Británico +
Internacional, 2000), en la actualidad, tras adoptar *7799 como estándar
internacional, es el más extendido y aceptado, en Chile se emplea el ISO /IEC
17799:2005 para establecer las características mínimas de seguridad y
confidencialidad de los documentos electrónicos denominado Decreto Supremo Nº
83 “Norma técnica sobre Seguridad y Confiabilidad del Documento Electrónico”.
La norma ISO 17799 es una norma internacional que ofrece recomendaciones
para realizar la gestión de la seguridad de la información dirigida a los
responsables de iniciar, implantar o mantener la seguridad de una organización.
Dentro de esta se define a la información como un activo que posee valor para la
organización y requiere por lo tanto, una protección adecuada. El objetivo de la
24
seguridad de la información es proteger este activo para asegurar la continuidad
de la organización, minimizar daños y maximizar el retorno de las inversiones y las
oportunidades de negocio.
La seguridad de la información se define como la preservación de:
Confidencialidad: esto significa que se asegure que la información sea
accesible solo para aquellos autorizados a tener acceso.
Integridad: Garantía de exactitud y completitud de la información y de los
métodos de su procesamiento.
Disponibilidad: Aseguramiento de que los usuarios autorizados tienen
acceso cuando lo requieran y sus activos asociados.
Figura 3.2 Seguridad de la información.
El objetivo de la norma ISO 1799 es proporcionar una base común para
desarrollar normas de seguridad dentro de las organizaciones y ser una práctica
eficaz de la gestión de seguridad.
El estándar equivalente en Chile es el BS ISO/IEC 27002:2005, se trata de una
norma no certificable, pero que recoge la relación de controles a aplicar (o al
25
menos a evaluar) para establecer un sistema de gestión de seguridad de
información (SGSI) esta norma contiene 39 objetivos de control y 133 controles
agrupados en 11 dominios.
La norma UNE-ISO/IEC 17799 establece diez dominios de control que cubren por
completo la Gestión de la Seguridad de la Información:
1. Política de seguridad.
2. Aspectos organizativos para la seguridad.
3. Clasificación y control de activos.
4. Seguridad ligada al personal.
5. Seguridad física y del entorno.
6. Gestión de comunicaciones y operaciones.
7. Control de accesos.
8. Desarrollo y mantenimiento de sistemas.
9. Gestión de continuidad del negocio.
10. Conformidad con la legislación.
De estos diez dominios se derivan 36 objetivos de control (resultados que se
esperan alcanzar mediante la implementación de controles) y 127 controles
(prácticas, procedimientos o mecanismos que reducen el nivel de riesgo).
La norma ISO 17799 no es una norma tecnológica, ha sido redactada de forma
flexible e independiente de cualquier solución de seguridad especifica, proporciona
buenas prácticas neutrales con respecto a la tecnología y a las soluciones
disponibles en el mercado. Estas características posibilitan su implantación en
todo tipo de organizaciones, sin importar su tamaño o sector de negocio.
26
Capítulo IV Bacula
4.1.- Que es Bacula
Bacula es un software que permite gestionar los respaldos, restauraciones y
además la verificación de los archivos ubicados en los distintos computadores y/o
servidores de la red. Se basa en un esquema Cliente/Servidor es relativamente
sencillo de utilizar, y modular lo que permite su utilización en una LAN pequeña o
a mayor escala en una gran red empresarial.
Es un software Open Source por lo que está en constante desarrollo, además su
licencia es GLP, lo que hace que su código fuente esté disponible para lo que se
desee modificar además contiene una amplia gama de documentación.
En su versión Server, esta disponible solo para sistemas operativos Linux, pero
existen diversas recopilaciones para la versión cliente para distintos sistemas
operativos.
El sistema de Bacula se compone de cinco elementos que son:
-Bacula Director (DIR).
-Bacula File (FD).
-Bacula Storage (SD).
-La consola.
-El catálogo.
Estos son los requerimientos del sistema que necesita Bacula para su
funcionamiento
27
-Bacula se ha compilado y probado en los sistemas OpenSuSe Linux, FreeBSD y
Solaris, para su compilación requiere GNU C++ versión 2.95 o superior.
- Dependiendo del gestor de base de datos elegido, se necesita como mínimo la
versión MySQL 4.1, PostgreSQL 7.4, SQLite 3.
-La consola para GNOME ha sido desarrollada y probada en GNOME 2.x , ya no
existe soporte para GNOME 1.4.
-El Tray Monitor se ha desarrollado para GTK+-2.x. Precisa GNOME menor o igual
a la versión 2.2, KDE mayor o igual a la versión 3.1 o cualquier gestor de ventanas
que soporte el estándar FreeDesktop System tray.
Figura 4.1 Elementos de Bacula
Fuente: Sistemas de respaldo, Víctor Hugo dos Santos.
28
Figura 4.2 Esquema general de una red con Bácula Fuente: Sistemas de respaldo, Víctor Hugo dos
Santos.
29
4.2.- Componentes de Bacula
Bacula Director (DIR)
Es el servicio a cargo de la gestión de todas las operaciones de backup. El
DIR se encarga de los trabajos que se realizaran, cuando, donde y como,
además se encarga de la de los ficheros que se le pidan y de su
verificación.
Figura 4.3 Bacula Director Fuente Sistemas de respaldo, Víctor Hugo dos Santos.
30
Bacula File/Cliente
Es el software que se instalara en el equipo del cliente o usuario donde se
quiera realizar un respaldo, su función principal es leer y transmitir los
ficheros que el Director le pida y/o restaurarlos.
Figura 4.4 Bacula File Fuente Sistemas de respaldo, Víctor Hugo dos Santos.
Bacula Storage
31
Es el servicio que se encarga de la lectura y escritura física de los archivos
en las unidades de respaldo que se encuentres definidas (cintas, discos
duros, entre otros)
Figura 4.5 Bacula Storage Fuente Sistemas de respaldo, Víctor Hugo dos Santos.
La Consola
32
Es el programa que se instalara en la(s) maquina(s) que se conectaran al
Director y desde donde se podrá ejecutar las órdenes, programar las
tareas, monitorear, hacer las consultas entre otros comandos
administrativos
Figura 4.6 Bacula Storage Fuente Sistemas de respaldo, Víctor Hugo dos Santos.
33
El Catalogo
El catalogo es en si la base de datos donde Bacula Director guarda y
registra todas sus operaciones. El catalogo distingue a Bacula de un
programa de backup del sistema operativo, tales como tar, cpio o dump,
porque mantiene un registro de todos los volúmenes utilizados, los jobs
ejecutados y todos los archivos grabados, permitiendo, de esta manera,
una restauración y administración de volúmenes eficientes. Bacula,
actualmente, soporta tres tipos diferentes de bases de datos: MySQL,
PostgrSQL y SQLite, esto debe ser seleccionado cuando se instala el
software.
Figura 4.7 Bacula Storage Fuente Sistemas de respaldo, Víctor Hugo dos Santos
34
4.3.- Funcionamiento de Bacula
Como primer paso en el Director (DIR) se define una serie de trabajos
(Jobs),la fecha y hora que se quiera poner en marcha el trabajo de backup, todo
esto de acuerdo a las necesidades de cada empresa.
Luego el director se contacta con el primer cliente (FD) que está establecido y se
comprueban los ficheros o directorios definidos y finalmente los Clientes envían
los archivos que hayan cambiado al servicio Storage (SD) que almacena en el
volumen indicado los ficheros que enviaran los clientes.
Figura 4.8 Funcionamiento de Bacula Fuente www.asfasfos.com/2010/03/bacula-una-solucion-
gratuita-de-copias.html
35
4.4.- Características fundamentales de Bacula
Organización interna para ejecución automática de tareas.
Planificación para múltiples trabajos al mismo tiempo.
Ejecución de una tarea o múltiples al mismo tiempo
Secuencias de tareas usando prioridades.
Independencia del sistema operativo en el formato de los volúmenes.
Linux,Solaris, y Windows clients pueden realizarse en el mismo volumen.
Comprobación de catálogos “Tripwire like capability (system break-
indetection)”
Soporte de cambiado automático de cintas y para auto cargadores por
código de barras y etiquetado automático.
Soporte para múltiples “drive autochangers”.
Listas de acceso para limitación de acceso a datos.
Soporte para ordenadores de 64 bits.
Encriptación de las comunicaciones por stunnel.
Backup consistentes de ficheros abiertos sobre Win32 systems
(WinXP,Win2003)
Las posibilidades de Bacula son muchas, pero para sacar el máximo rendimiento
habría que disponer de un servidor dedicado que se encargue de las múltiples
tareas a las que se encomiende a este versátil software del cual se conocen
implementaciones que incluyen alta disponibilidad y operación en ambientes de
misión critica.
36
Capítulo V: Instalación de Bacula y
Configuración de los Elementos
Necesarios
5.1.- Generalidades de Bacula
La versión que se utilizará en los laboratorios de pruebas corresponde a
Bacula 5.0.3 lanzada el 6 de agosto del 2010 y fue liberada bajo licencia AGLP
versión 3 por bacula.org, que es la principal comunidad de desarrolladores y
colaboradores para el proyecto Bacula.
No es obligatorio pero si muy recomendable que todas las maquinas que
intervengan en el proceso sean accesibles por un nombre de dominio o tengan
una IP estática ya que para poder configurar los archivos se necesitaran estos
datos.
5.2.- Primer paso de la instalación
Como primera instancia se debe instalar una base de datos para el catalogo
de Bacula, este soporta MySQL, SQLite y postgreSQL, pero por defecto al instalar
el paquete Bacula se instala MySQL.
Para Instalar MySQL se debe ejecutar el siguiente comando en una terminal
#sudo apt-get install mysql-server
Durante el proceso se pedirá que introduzca una contraseña para el usuario root
de MySQL
37
Imagen 5.1, Configuración de Password de root, Fuente: Servidor de pruebas.
Una vez completada la instalación, el servidor MySQL se iniciara
automáticamente.
5.3.- Instalación de Bacula director
Este es el demonio que maneja al resto, debe instalarse en la maquina que
realizara los respaldos y debe comunicarse con el servidor donde se encuentra la
base de datos, o estar en la misma máquina y escuchar en Localhost.
Para su instalación debe ejecutarse el siguiente comando
#sudo apt-get install Bacula-director-mysql
38
Imagen 5.2 Instalación de Bacula Director Fuente: Servidor de pruebas
Este paquete instalara Bacula director y configurara la base de datos con la que
trabaja.
Para verificar que se creó la base de datos para Bacula ejecutamos lo siguiente:
#sudo mysql
Una vez dentro.
Mysql>show databases
Y deberíamos observar un recuadro donde se ve la base de datos de Bacula
creada:
39
Imagen 5.3 bases de datos Mysql Fuente servidor
5.4.- Instalación de Bacula Storage
Este demonio se encarga de la lectura/escritura física de los archivos en los
volúmenes que estén definidos, puede ser la misma máquina que la anterior o una
diferente en este caso será la misma
Para su instalación se debe ejecutar lo siguiente:
#sudo apt-get install Bacula-sd Bacula-sd-tools
Imagen 5.4 Instalación de Bacula Storage Fuente: Servidor de pruebas
Se descargan los repositorios y se instalan.
40
5.5.- Instalación de Bacula File
Mediante este demonio Bacula obtiene los demonios que necesita
respaldar, por lo que es necesario instalarlo en las maquinas que necesiten ser
respaldadas
Para su instalación se debe ejecutar
#sudo apt.get install Bacula-fd
Imagen 5.5 Instalación de Bacula File Fuente: Servidor de pruebas
Ahora, luego de realizar todos estos pasos, tendremos instalados todos los
demonios que interactúan para lograr que Bacula funcione como un eficiente
sistema de respaldo de información.
5.6.- Instalación de la Consola de Bacula
Este es el software que se instala en la o las maquinas que se conecte al
servidor, desde este software podremos dar las ordenes, programar tareas, hacer
consultas entre otras funciones administrativas.
Para instalar
#sudo apt-get install Bacula-console
41
Otra forma de interactuar con Bacula es mediante Webmin que es una interfaz
basada en web para administración de sistemas Unix, el cual incluye dentro de
sus opciones poder configurar muchas de las opciones que ofrece Bacula
Imagen 5.6 Instalación de Webmin Fuente: Servidor de pruebas
5.7.- Instalación de Bacula Client
Para que los equipos a respaldar puedan comunicarse con el servidor
Bacula se debe instalar Bacula client, este software se puede descargar de la
página oficial de Bacula en la cual se encuentra una distribución para sistemas
operativos de 32 y 64 bits http://www.bacula.org/en/?page=downloads
Se hace doble click sobre el archivo descargado y se comienza la instalación la
cual es guiada por un Wizard.
42
Imagen 5.7 Instalación de Bacula Client Fuente: Servidor de pruebas
Se selecciona los archivos a instalar
Imagen 5.8 Instalación de Bacula Client Fuente: Servidor de pruebas
Y luego se configuran los archivos client y bat, el primero para que se comunique
con el file daemon y el segundo es para instalar una consola de administración por
lo cual no se debe instalar en todas las maquinas, solo en las de los
administradores de Bacula.
43
Imagen 5.9 configuración de Bacula Fuente: Cliente 1
Imagen 5.10 configuración de Bat Fuente Cliente 1
44
Capítulo VI.- Configuración y
Administración de Bacula
6.1.- Generalidades de configuración
Una vez instalados todos los demonios de Bacula se procede a modificar
los archivos de configuración necesarios para que las diferentes instancias de
Bacula puedan interactuar entre sí.
En el directorio /etc/Bacula/, se encuentran todos los archivos de configuración
necesarios para poder configurar Bacula, estos archivos son:
-Bacula-dir.conf, archivo de configuración de Bacula director.
-bacula-sd.conf, archivo de configuración del storage daemon.
-bacula-fd-conf, archivo de configuración de file daemon.
Además para la administración del software se utilizara Webmin
6.2.- Configuración de Bacula director
Este es el archivo donde se configuraran las opciones más importantes, ya
que es este demonio el encargado de controlar el flujo de los datos.
Primero se debe ingresar al fichero ejecutando:
#sudo gedit /etc/Bacula/Bacula-dir.conf
Y abrirá una ventana en la cual se podrán realizar las configuraciones necesarias
que a continuación se muestran:
“Director”
45
Se define a si mismo.
Imagen 6.1 Configuración de Bacula Director Fuente Servidor de pruebas
Name: Nombre que se asigna al director. Es el mismo nombre que se permitirá a
los otros demonios.
DIRport: Puerto de escucha para las consolas, por defecto viene configurado el
puerto 9101.
QueryFile: Archivo con las consultas a la base de datos.
WorkingDirectory: Directorio de trabajo donde, esto no se debe cambiar.
PidDirectory: Directorio donde crear los archivos con pid
Maximum Concurrent Jobs: Número máximo de trabajos concurrentes que
acepta, establecer este valor igual a 1 implica que el director solo hará un trabajo
46
cada vez, este es el valor por defecto, si este valor aumenta se permite que varios
directores utilicen esos demonios a la vez.
Password: Contraseña que se le pedirá al programa de consola. Esta contraseña
no se pide por teclado, sino que se almacena en el archivo de configuración del
programa de consola.
Messages: Donde se enviaran los mensajes asociados a un trabajo concreto.
DirAdress: Dirección donde escucha el director. Indicar 127.0.0.1 implicara que
no podrán abrirse consolas Bacula en maquinas remotas, pero no causa
problemas si tenemos los demás demonios en otras maquinas puesto que es el
director el que abre las conexiones con los otros demonios. En este caso se
configuro la dirección IP del mismo servidor.
“Client”
Aquí se especificaran los datos del Bacula file daemon con el que se conectara
para leer los ficheros necesarios, para ello se especificara lo siguiente
47
Imagen 6.2 Configuración de Bacula Director Fuente Servidor de pruebas
Name: Nombre del fichero daemon. Este nombre no tiene que coincidir
necesariamente con el que se configura el file-daemon, es solo para nombrarlo
dentro de Bacula, pero por recomendación general se hace coincidir para
mantener un orden, en este caso se utilizo Ubuntu-fd haciendo referencia al
sistema operativo y al tipo de demonio.
Address: IP o Hostname de la maquina que tiene el file daemon, en este caso se
utiliza Localhost debido a que todos los demonios se encuentran en el mismo
servidor.
FDPort: puerto donde escucha el file daemon, por defecto el puerto es el 9102.
Catalog: Se configura que catalogo es el que se utilizara el file daemon, un
catalogo es un listado de los ficheros que se están respaldando.
Password: Contraseña que enviara el director al file daemon para autentificarse.
48
File Retention: este parámetro indica cuanto tiempo deben permanecer los
archivos en el catalogo. Pasando este tiempo se eliminan del catalogo, pero esto
no influye en que se hagan o no los backups de estos ficheros.
Job Retention: Indica cuanto tiempo como máximo estará un trabajo esperando.
AutoPrune: si está en “yes”, una vez pasados los periodos File Retention y/o Job
Retention se eliminan del catalogo y/o cola los ficheros/trabajos.
“storage”
Es aquí donde se especificaran los dispositivos que podrá utilizar Bacula para
almacenar los backups, pueden existir varios que se diferenciaran por el nombre,
se deben indicar los siguientes campos.
Imagen 6.3 de Bacula Director Fuente Servidor de pruebas
49
Name: Nombre del medio de backup, en este caso se utiliza “File” debido a que el
backup se almacenara como un archivo. No es el nombre del Storage Daemon
sino del medio, por ejemplo: Carrusel_Cintas o Fichero_Local, entre otros.
Address: Maquina donde está el Storage Daemon que maneja el medio de
almacenamiento, es este caso se utiliza la misma IP del servidor debido a que se
encuentra todo en un solo equipo.
SDPort: Puerto de escucha de Storage Daemon, por defecto es el 9103.
Password: Contraseña que enviara el Director para autentificarse contra el
storage daemon.
Device: Nombre del medio configurado en el Storage Daemon que se debe usar.
El Storage Daemon configura uno o varios dispositivos de almacenamiento,
nombrándolos de alguna manera, pues ese nombre es el que se utiliza aquí.
Media Type: Cuando se configura el medio se especifica que tipo de medio es,
aquí también se debe indicar y debe coincidir.
“Catalog”
50
Imagen 6.4 de Bacula Director Fuente Servidor de pruebas
Name: nombre del catalogo que se utilizara.
Dbname: Nombre de la base de datos
Db Address: Maquina donde está configurado el servidor MySql
DBuser: usuario con privilegios en la base de datos especificada anteriormente
suficientes para crear y modificar datos.
Password: Contraseña de dicho usuario en esa base de datos.
51
6.3.- Configuración de Bacula File Daemon
Para acceder al archivo de configuración se ejecuta
#sudo gedit /etc/Bacula/Bacula-fd.conf
Imagen 6.5 Configuración de Bacula File Fuente Servidor de pruebas
52
En este archivo se definen tres tipos de resources, donde un resource define un
elemento de Bacula.
En este archivo se definen 3 tipos de resources distintos
Director: Indica que director puede conectarse con este file daemon; como se ve
se definen dos: Ubuntu-dir y Ubuntu-mon, el segundo es el director especial que
actúa de monitor, se configura automáticamente, el primero es el que se ha
añadido o modificado manualmente. El nombre que se especifica es el nombre
que se le ha dado al director, configurado previamente y la password es la que se
espera que dé cuando se autentifique.
FileDaemon: Define los parámetros del propio file daemon, parámetros como el
puerto escucha o la IP a la que debe asociarse ( si al IP es 127.0.0.1 solo aceptara
conexiones de la maquina local). También se especifica el nombre que se le da al
file daemon, es de suma importancia que coincida con el nombre que se configuro
en el director.
Messages: Indica que mensajes se podrán enviar a cada director. Una vez que se
modifica el archivo se reinicia el demonio y estará listo para funcionar con Bacula.
6.4.- Configuración de Bacula Storage Daemon
Se debe abrir el archivo de configuración al igual que con los otros
anteriormente
#sudo gedit /etc/Bacula/Bacula-sd.conf
53
Imagen 6.6 Configuración de Bacula Storage Fuente Servidor de pruebas
54
Storage: se define a si mismo y que parámetros usar.
Name: Indica el nombre que se asigna al storage daemon.
SDPort: Numero de puerto utilizado por el daemon.
WorkingDirectory: Directorio de trabajo donde, esto no se debe cambiar.
PidDirectory: Directorio donde crear los archivos con pid.
Maximum Concurrent Jobs: Número máximo de trabajos concurrentes que
acepta.
SDAdress: Dirección donde escucha el storage deamon. En este caso se
configuro la dirección IP del mismo servidor.
Director: Indica que director puede conectarse con este storage daemon; como se
ve se definen dos: Ubuntu-dir y Ubuntu-mon, el segundo es el director especial
que actúa de monitor, se configura automáticamente, el primero es el que se ha
añadido o modificado manualmente. El nombre que se especifica es el nombre
que se le ha dado al director, configurado previamente y la password es la que se
espera que dé cuando se autentifique.
Device: Nombre del medio configurado en el Storage Daemon que se debe usar.
El Storage Daemon configura uno o varios dispositivos de almacenamiento,
nombrándolos de alguna manera, pues ese nombre es el que se utiliza aquí.
Name: es el nombre que se aplicara para el tipo de backup.
Media Type: Cuando se configura el medio se especifica qué tipo de medio es,
aquí también se debe indicar y debe coincidir.
Archive Device: es la ruta donde se guardaran los backups.
55
6.5.- Administración
La administración de Bacula se puede hacer a través de consolas línea de
comando, GUI y Web, en este proyecto se utilizo Webmin.
Webmin es una herramienta de administración accesible mediante interfaz web
para sistemas Unix, a través de este se pueden configurar aspectos internos de
muchos sistemas operativos, como usuarios, cuotas de disco, servicios, archivos
de configuración, apagado del equipo, entre otros, asi como modificar y controlar
muchas aplicaciones Open Source, como servidos web apache, PHP, MySQL,
DNS, DHCP y por supuesto Bacula.
Para ingresar a la consola web se debe ingresar a través del navegador la
dirección IP donde fue instalado Bacula y por el puerto 10000
Figura 6.7 Ingreso a Webmin Fuente Servidor de pruebas
Una vez hecho esto se ingresa a la consola de administración en donde se
procederá a dirigirse a la zona de Bacula Backup System.
56
Figura 6.8 Menú de Bacula Fuente Servidor de pruebas.
Es aquí donde se puede comenzar con la administración de Bacula y sus
diferentes daemons.
Figura 6.9 Configuración del Director Fuente Servidor de pruebas.
57
Figura 6.10 Configuración del Storage Daemon Fuente Servidor de pruebas.
Figura 6.11 Configuración de File Daemon Fuente Servidor de pruebas.
En estas tres figuras se muestra lo que se configuro anteriormente en el archivo
de configuración de cada daemon, que serian los nombres, puertos con que
trabaja y directorios de trabajo.
58
Figura 6.12 Clientes Fuente Servidor de pruebas.
En esta sección se agregan los clientes a los que se les harán los respalos
Figura 6.13 Horarios Fuente Servidor de pruebas.
Figura 6.14 Trabajos de backup Fuente Servidor de pruebas.
Es aquí donde se programara cuando, en que horario y a quien se le realizará un
backup.
59
Figura 6.15 Dispositivos de almacenamiento Fuente Servidor de pruebas.
Aquí es donde se pueden agregar o administrar los dispositivos en donde se harán
los backups.
Figura 6.16 backup funcionando Fuente Servidor de pruebas.
Como se puede apreciar en esta figura se realizo un backup de tipo completo a
uno de los clientes manualmente.
60
Capítulo VII Pruebas Técnicas de
Rendimiento
7.1.- Objetivo del capitulo
El objetivo de este capítulo es presentar las pruebas de rendimiento y
consumo de recursos tanto del servidor en el que se encuentra Bacula con sus
daemons como de los clientes, además de esto se medirá el consumo de red que
hace para el traspaso de la información.
En cuanto a la medición del rendimiento cliente-servidor de una aplicación como
Bacula depende de varios factores que hacen difícil hacer un análisis de consumo.
Existen diversos factores a tener en consideración como el tipo de servidor del
director, la carga de trabajo, el volumen de la copias, el trafico y el tipo de clientes
así como de sus dispositivos, en cuanto a la velocidad de ejecución hay que
ceñirse a condiciones similares a las anteriores, ya que dependerá de la carga del
servidor y del trafico como de los volúmenes de datos.
7.2.- Laboratorios de trabajo
61
El laboratorio de trabajo numero uno se compone de un equipo que trabaja
como servidor con Ubuntu 10.10 en donde está instalado Bacula con sus
daemons, además se cuenta con 2 computadores con Windows XP, que serán los
clientes a los cuales se les harán los respaldos, este laboratorio será empleado
para realizar pruebas de funcionamiento y pruebas parciales para luego realizar un
laboratorio que conste con una mayor cantidad de equipos a los cuales se les
realizaran los backups.
En el siguiente cuadro se muestran los detalles de cada equipo utilizado en el
laboratorio numero uno.
Equipo Detalle técnico Detalles
Computador
Utilizado como server 1
Nombre:Ubuntu-Servidor
1.-Procesador AMD Athlon(tm) II X4 630 Processor, 4 cores
2.-Memoria RAM DDR2 1.71 GB total
3.-Disco duro 224.29 GB total
Ubuntu 10.10 the Maverick Meerkat - released in October 2010.
Corriendo: -Bacula-dir 5.0.1
-Bacula-fd 5.0.1
-Bacula-sd 5.0.1
Computador
Utilizado como cliente 1
hp modelo pavilion dv5 1132-la
1.- Procesador amd athlon x2 dual core 2 GHz.
2.- Memoria RAM DDR2 2 GB
3.-Disco duro 120 GB total
4.- NIC de Fast Ethernet PCI-E de la familia Realtek RTL8102E/RTL8103E
Consumo de 12 v y 3.3 A
Windows XP SP3
Computador
Utilizado como cliente 2
hp modelo pavilion dv5 1132-la
1.- Procesador amd athlon x2 dual core 2 GHz.
2.- Memoria RAM DDR2 2 GB
3.-Disco duro 120 GB total
4.- NIC de Fast Ethernet PCI-E de la familia Realtek
Consumo de 12 v y 3.3 A
Windows XP SP3
62
RTL8102E/RTL8103E
Tabla 7.1 Especificaciones técnicas de los equipos de laboratorio numero 1.
La topología física del primer laboratorio consta de los dos computadores clientes
y un computador que es el servidor de Bacula conectados por un switch para
simular una topología LAN.
El criterio de decisión para optar por este hardware se baso en los requerimientos
mínimos que se necesitaban para cada sistema operativo y a partir de esto se
seleccionó un hardware que permitiera el funcionamiento no solo el sistema
operativo sino que también las aplicaciones que se necesitarían para el
funcionamiento de los respaldos.
Los requisitos mínimos recomendados para Ubuntu 10.10, teniendo en cuenta los
efectos de escritorio, son los siguientes:
- Procesador x86 a 1 GHz
- Memoria RAM: 512 MB
- Disco Duro 5 GB (swap incluida)
Y para Windows XP con Service Pack 3 son los siguientes:
- Procesador 300 MHz
- Memoria RAM 128 MB
- Disco Duro mínimo de 1,5 GB
63
Imagen 7.1 Topología física de Laboratorio numero uno
Una vez realizadas las pruebas y comprobación del correcto funcionamiento del
sistema se procede a armar y configurar un segundo laboratorio con el fin de
realizar pruebas con un servidor de mayores prestancias como con una mayor
cantidad de usuarios para así poder determinar con una base más solida la
eficiencia y eficacia del sistema.
El segundo Laboratorio consta de un Servidor HP Proliant MI150 y de cinco
computadores con cuatro maquinas virtuales cada uno simulando en total 20
equipos con Windows XP profesional de 32 bits estos conectado por medio de un
switch para su comunicación en la LAN.
A continuación se muestra una tabla con las características del sistema.
Equipo Detalle Técnico Detalle
Servidor HP
Proliant MI150
1.-Procesador Quad-Core Intel®
Xeon® processor E5405 (2.00
GHz, 1333 FSB, 80W)
2.-Memoria RAM DDR2 6 GB
Ubuntu 10.10 the Maverick Meerkat - released in October 2010.
Corriendo: -Bacula-dir 5.0.1
-Bacula-fd 5.0.1
64
3.-Disco Duro 4 TB (4x1TB) SATA
4.-Red HP NC105i PCI Express
Gigabit Server Adapter
10/100/1000
-Bacula-sd 5.0.1
5 computadores
HP Pavilion
S5110LA
1.-Procesador AMD Athlon X2
Dual-Core 7550
2.-Memoria Ram DDR2 3 Gb
3.-Disco Duro 320 GB SATA
4.- NIC de Fast Ethernet PCI-E de la familia Realtek RTL8102E/RTL8103E
Windows XP profesional Base
(32 bits)
Corriendo VMware Workstation
7.0.1 con 4 maquinas virtuales
windows XP SP3, (40 Gb Disco
duro, 512 GB RAM)
Tabla 7.1 Especificaciones técnicas de los equipos de laboratorio numero 2
A continuación se muestra la topología física utilizada en el segundo laboratorio
Figura 7.2 Topología física laboratorio número dos
65
7.3.- Mediciones de consumo de hardware y red
Estas mediciones de consumo de hardware se realizaron mediante varias
pruebas en el laboratorio número uno, una realizando un backup completo de
cada cliente y la otra realizando dos backup incrementales.
Para cada cliente se realizo un backup completo de un volumen de 20 Gb para el
cliente 1 uno de 35 Gb para el cliente 2, el consumo de CPU y RAM de ambos fue
relativamente parejo como se muestra a continuación en los gráficos, la diferencia
estuvo en el tiempo de ejecución de cada uno, para el volumen de 20 Gb. El
tiempo de ejecución fue aproximadamente de 35 minutos para el volumen de 20
Gb y para el volumen de 35 Gb. fue de aproximadamente 40 minutos.
En el backup incremental sucedió algo parecido, el uso de CPU y RAM fue similar
y lo que vario fue el tiempo en que se ejecutaron los respaldos
66
Imagen 7.2 Backup Completo Cliente 1 fuente servidor de pruebas
67
Imagen 7.3 Backup completo cliente 2 fuente servidor de pruebas
68
Imagen 7.4 Backup Incremental Cliente 1 fuente servidor de pruebas
69
Imagen 7.5 Backup Incremental Cliente 2 fuente servidor de pruebas
Resumen de Resultados
Completo cliente 1
(20 Gb)
Completo cliente 2
(35 Gb)
Incremental cliente
1 (600 Mb)
Incremental cliente
2 (439 Mb)
37% CPU 59% CPU 29% CPU 32% CPU
27% RAM 32% RAM 23% RAM 20% RAM
35 Minutos 40 Minutos 3 Minutos 2,5 Minutos
70
Después de realizadas las pruebas de funcionamiento y mediciones de consumo básicas
se procede a realizar pruebas con un mayor número de clientes para así poder determinar
la eficacia del sistema implementado y ver si es viable su futura implementación en una
PYME u organización que lo requiera.
Como primera prueba se realizo una medición de CPU realizando 1 respaldo completo y
uno incremental con volúmenes de 20 GB para el respaldo completo y de 10 GB para los
respaldos incrementales, esto se realizo con 2 clientes simultáneos hasta llegar a los 20
clientes sucesivamente. Los resultados porcentuales son los siguientes:
Grafico 7.1 Porcentaje de uso de CPU Fuente Servidor de pruebas nº 2
Como se puede apreciar en el siguiente grafico el número de usuarios con
respecto al porcentaje de uso de CPU es exponencial a mayor cantidad de
usuarios se incrementa el uso del procesamiento.
La segunda prueba realizada fue la de consumo de memoria RAM con los
resultados que se muestran a continuación
71
Grafico 7.2 porcentaje de uso de memoria RAM Fuente Servidor de pruebas nº 2
Se puede apreciar en el siguiente grafico al igual que en el primero que el uso de
memoria va a incrementar al realizarse mas backups simultáneos sin embargo el
uso de memoria disponible no supera el 35 % del total.
Finalmente se realizó una prueba de consumo de red
72
Capítulo VIII Conclusiones
8.1.- Conclusiones parciales
Bacula es un sistema de gestión de backups completo, eficaz, de fácil
administración e intuitivo.
Con respecto al uso de recursos tanto de CPU, RAM y red y de acuerdo a las
mediciones realizadas se puede concluir que el consumo de recursos es
relativamente bajo por lo que hace que el sistema sea fácilmente implementado en
donde se requiera y donde se conste con los requerimientos mínimos que Bacula
necesita para su funcionamiento.
Según las primeras pruebas en donde medimos el uso de cpu
73
Bibliografía
Barrio J. (2009) Alcance Linux
Martinoli D. (2009) Sistemas Operativos Unix
Olcina F. (2010); Gestión de backups mediante Bacula. Revista Linux, n°9
(2009) URL: http://leycuen.blogspot.com/
(2010) URL: http://www.bacula.org/en/developers/index.html
(2010) URL: http://es.wikipedia.org/wiki/Bacula
Huaman A. (2009)
URL:http://www.slideshare.net/maxalonzohuaman/sistemas-de-respaldo-de-
informacion-presentation
Montenegro A. (2006)
URL:http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=backupLinux
74
