MailStore: Backup del correo electrónico

13 febrero, 2012 Deja un comentario

Recientemente he tenido un problema con mi proveedor de correo y he perdido correos electrónicos muy valiosos. Como lo tenía conigurado via IMAP y no tenía copia de seguridad ya que la hacía el propio proveedor de correo (Pensaba que para eso les pagaba, para que las hicieran ellos…) he intentado buscar un remedio para que no me vuelva a pasar.

Hay varios modos de hacer una copia de seguridad, pero he encontrado un programa que esta realmente bien. Permite hacer copias de seguridad de tu correo local, de un servidor pop, imap, exchange…o de todos a la vez. Te permite exportar de un proveedor a otro todo tu correo vía Imap, buscar en las copias de seguridad correos electrónicos y muchas cosas más. La configuración es super sencilla, ya que prácticamente es como configurar una cuenta de correo electrónico en cualquier cliente y hacer un doble click encima de la cuenta.

En fin, a lo mejor hay otras herramientas, pero a mí con esta me vale (Además es gratuita para uso personal…). Aquí os dejo el enlace: MailStore

Categorías:Backup

Cambiar comportamiento permisos Windows 2003 Server

8 febrero, 2012 Deja un comentario

Por defecto Windows 2003 Server se comporta del siguiente modo cuando copiamos/movemos un archivo o carpeta:

- Si lo movemos a un Volumen NTFS diferente, los permisos que persisten son los de la carpeta de destino.

- Si lo movemos dentro del mismo volumen NTFS, el archivo o la carpeta guardan sus permisos originales.

Para cambiar este comportamiento, podemos modificar el registro tal y como lo indica Microsoft en el siguiente enlace:

Cambiar comportamiento permisos

Resumiendo lo que dice Microsoft…si queremos cambiar el comportamiento en el primer caso para que se respeten los permisos originales en lugar de los de la carpeta destino:

  1. Haga clic en Inicio , haga clic en Ejecutar , escriba regedit en el cuadro Abrir y, a continuación, presione ENTRAR.
  2. Busque la siguiente clave del Registro y haga clic en ella:
    HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer
  3. En el menú Edición , haga clic en Agregar valor y, a continuación, agregue el siguiente valor del registro:
    Nombre del valor: ForceCopyAclwithFile
    Tipo de datos: DWORD
    Valor de datos: 1

Si queremos cambiar el comportamiento del segundo caso y queremos que se respeten los permisos de la carpeta destino:

  1. Haga clic en Inicio , haga clic en Ejecutar , escriba regedit y, a continuación, presione ENTRAR.
  2. Busque y haga clic en la siguiente subclave del Registro:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer
  3. En el menú Edición , haga clic en Agregar valor y, a continuación, agregue el siguiente valor del registro:Nombre del valor: MoveSecurityAttributes
    Tipo de datos: DWORD
    Datos de valor: 0
  4. Editor de registro de salida.
  5. Asegúrese de que la cuenta de usuario que se utiliza para mover el objeto tiene el conjunto de permisos Cambiar permisos . Si no se establece el permiso, conceda el permiso Cambiar permisos a la cuenta de usuario.

Nagios en Debian Lenny

5 octubre, 2010 Deja un comentario

Hoy veremos como instalar y configurar Nagios de una manera básica en Debian Lenny.

Para instalarlo, bastará con un:

aptitude install nagios3

Nos vamos al directorio del Nagios:

cd /etc/nagios3

Creamos un login para entrar en Nagios e introducimos la contraseña:

htpasswd -c htpasswd.users nagiosadmin

Para probar, introducimos la IP de nuestro servidor seguido de nagios3 en la barra de direcciones y nos debería de salir algo parecido a esto:



Los archivos de configuración se encuentran en el directorio /etc/nagios3/conf.d. En el directorio /etc/nagios3 se encuentra un archivo de configuración (nagios.cfg) que de momento no vamos a tocar, ya que no es necesario para una configuración básica.

Vamos a centrarnos en los archivos que están en el directorio conf.d. El primero, contacts.cfg:

Aqui se le dice a Nagios a quien enviará emails, de que tipo, con que frecuencia, etc. Podemos crear grupos de usuarios para que reciban las mismas notificaciones. En este caso, solo creare un usuario y un grupo.

Ahora, voy a explicar del modo en que yo configuro Nagios. Seguro que los habrá mejores, pero a mi me funciona bien así. Vamos a configurar 3 archivos:

El primero, es el hosts.cfg. Si este archivo no existe, lo creamos. En el, vamos a introducir todos los hosts, dispositivos de red, etc. de los que queramos monitorizar algo. Soy partidario de organizar muy bien los archivos de texto, por lo que pongo etiquetas por grupos y demás. Un ejemplo de este archivo de configuración, podría ser el siguiente:

########################################

### DISPOSITIVOS DE RED ###

########################################

define host {

host_name Fortinet_Interna

alias Fortinet_Interna

address 192.168.1.1

use generic-host

}

define host {

host_name Fortinet_Externa

alias Fortinet_Interna

address 172.16.0.2

use generic-host

}

define host {

host_name Router_Ono_Interna

alias Router_Ono_Interna

address 172.16.0.1

use generic-host

}

define host {

host_name Switch1

alias Switch1

address 192.168.1.205

use generic-host

}

define host {

host_name Switch2

alias Switch2

address 192.168.1.206

use generic-host

}

define host {

host_name Switch3

alias Switch3

address 192.168.1.207

use generic-host

}

define host {

host_name Switch4

alias Switch4

address 192.168.1.208

use generic-host

}

define host {

host_name DiscoRed1

alias DiscoRed1

address 192.168.1.22

use generic-host

}

define host {

host_name DiscoRed2

alias DiscoRed2

address 192.168.1.240

use generic-host

}

define host {

host_name Centralita1

alias Centralita1

address 192.168.1.200

use generic-host

}

define host {

host_name Centralita2

alias Centralita2

address 192.168.1.201

use generic-host

}

define host {

host_name iLO-SRV*****

alias iLO-SRV*****

address 192.168.1.250

use generic-host

}

define host {

host_name iLO-ESXi1

alias iLO-ESXi1

address 192.168.1.251

use generic-host

}

define host {

host_name iLO-SRVW2008

alias iLO-SRVW2008

address 192.168.1.252

use generic-host

}

########################################

### SERVIDORES WINDOWS ###

########################################

define host {

host_name SRV*****

alias SRV*****

address 192.168.1.5

use generic-host

}

define host {

host_name vSRV*****

alias vSRV******

address 192.168.1.4

use generic-host

}

define host {

host_name vSRVApliWeb

alias vSRVApliWeb

address 192.168.1.47

use generic-host

}

########################################

### SERVIDORES DEBIAN ###

########################################

define host {

host_name vSRVDebian

alias vSRVDebian

address 127.0.0.1

use generic-host

}

define host {

host_name vSRVDebianWS1

alias vSRVDebianWS1

address 192.168.1.103

use generic-host

}

########################################

### SERVIDORES VMWARE ###

########################################

define host {

host_name ESXi1

alias ESXi1

address 192.168.1.14

use generic-host

}

El siguiente archivo es el hostgroups_nagios2.cfg. En este archivo vamos a agrupar todos los hosts dados de alta en el archivo anterior. A Nagios no le gusta que un host no esté dentro de un grupo (Nos mandará “Warnings”). Así que no se debe olvidar meter a todos los host en grupos. En mi caso el archivo ha quedado así:

########################################

### GRUPOS DISPOSITIVOS DE RED ###

########################################

define hostgroup {

hostgroup_name Dispositivos_Red

alias Dispositivos_Red

members Fortinet_Interna,Fortinet_Externa,Router_Ono_Interna,Centralita1,Centralita2,DiscoRed1,DiscoRed2,Switch1,Switch2,Switch3,Switch4,iLO-SRVAstarte,iLO-ESXi1,iLO-SRVW2008

}

########################################

### GRUPOS SERVIDORES WINDOWS ###

########################################

define hostgroup{

hostgroup_name Servidores_Windows ; The name of the hostgroup

alias Servidores Windows ; Long name of the group

members SRV*****,vSRV*****,vSRVApliWeb

}

########################################

### GRUPOS SERVIDORES DEBIAN ###

########################################

define hostgroup {

hostgroup_name Servidores_Debian

alias Servidores Debian GNU/Linux

members vSRVDebian, vSRVDebianWS1

}

########################################

### GRUPOS SERVIDORES WEB ###

########################################

define hostgroup {

hostgroup_name Servidores_Web

alias Servidores Web

members vSRVDebian, vSRVDebianWS1

}

########################################

### GRUPOS SERVIDORES VMWARE ###

########################################

define hostgroup {

hostgroup_name Servidores_VMWARE

alias Servidores VMWARE

members ESXi1

}

El último archivo a editar es el services_nagios2.cfg. En este, vamos a dar de alta todos los servicios que queramos que Nagios monitoree y le asignaremos los grupos de hosts a dichos servicios. Los servicios los he “copiado” del archivo /etc/nagios3/conf.d/localhost_nagios2.conf (Servicios a monitorear en máquinas Linux) y del archivo windows.cfg (Servicios a monitorear en máquinas Windows). Este último archivo lo he buscado con un updatedb + locate, porque no me acordaba de donde se encontraba. En mi caso, este archivo ha quedado así:

########################################

### SERVICIOS DISPOSITIVOS DE RED ###

########################################

define service {

hostgroup_name Dispositivos_Red

service_description PING

check_command check_ping!100.0,20%!500.0,60%

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

########################################

### SERVICIOS SERVIDORES WINDOWS ###

########################################

define service{

hostgroup_name Servidores_Windows

service_description NSClient++ Version

check_command check_nt!CLIENTVERSION

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

define service{

hostgroup_name Servidores_Windows

service_description Tiempo Funcionando

check_command check_nt!UPTIME

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

define service{

hostgroup_name Servidores_Windows

service_description Rendimiento CPU

check_command check_nt!CPULOAD!-l 5,80,90

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

define service{

hostgroup_name Servidores_Windows

service_description Uso de memoria

check_command check_nt!MEMUSE!-w 80 -c 90

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

define service{

hostgroup_name Servidores_Windows

service_description Espacio en Unidad C

check_command check_nt!USEDDISKSPACE!-l c -w 80 -c 90

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

#define service{

# hostgroup_name Servidores_Windows

# service_description W3SVC

# check_command check_nt!SERVICESTATE!-d SHOWALL -l W3SVC

# use generic-service

# notification_interval 0 ; set > 0 if you want to be renotified

# }

define service{

hostgroup_name Servidores_Windows

service_description Explorer

check_command check_nt!PROCSTATE!-d SHOWALL -l Explorer.exe

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

########################################

### SERVICIOS SERVIDORES DEBIAN ###

########################################

define service {

hostgroup_name Servidores_Debian

service_description SSH

check_command check_ssh

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

# Define a service to check the disk space of the root partition

# on the local machine. Warning if < 20% free, critical if

# < 10% free space on partition.

define service{

hostgroup_name Servidores_Debian

service_description Espacio en disco

check_command check_all_disks!20%!10%

use generic-service ; Name of service template to use

notification_interval 0 ; set > 0 if you want to be renotified

}

# Define a service to check the number of currently logged in

# users on the local machine. Warning if > 20 users, critical

# if > 50 users.

define service{

hostgroup_name Servidores_Debian

service_description Usuarios Actuales

check_command check_users!20!50

use generic-service ; Name of service template to use

notification_interval 0 ; set > 0 if you want to be renotified

}

# Define a service to check the number of currently running procs

# on the local machine. Warning if > 250 processes, critical if

# > 400 processes.

define service{

hostgroup_name Servidores_Debian

service_description Procesos Totales

check_command check_procs!250!400

use generic-service ; Name of service template to use

notification_interval 0 ; set > 0 if you want to be renotified

}

# Define a service to check the load on the local machine.

define service{

hostgroup_name Servidores_Debian

service_description Rendimiento CPU

check_command check_load!5.0!4.0!3.0!10.0!6.0!4.0

use generic-service ; Name of service template to use

notification_interval 0 ; set > 0 if you want to be renotified

}

########################################

### SERVICIOS SERVIDORES WEB ###

########################################

define service {

hostgroup_name Servidores_Web

service_description HTTP

check_command check_http

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

########################################

### SERVICIOS SERVIDORES VMWARE ###

########################################

define service {

hostgroup_name Servidores_VMWARE

service_description PING

check_command check_ping!100.0,20%!500.0,60%

use generic-service

notification_interval 0 ; set > 0 if you want to be renotified

}

Ahora vamos a comprobar que la configuración que hemos introducido es correcta. Para ello:

nagios -v /etc/nagios3/nagios.cfg

Seguramente Nagios nos de algún error. Pero nos indica el archivo y línea en el que se encuentra, por lo que solo tendremos que ir y corregirlos. Habrá que repetir este proceso hasta que NAgios nos diga que no encuentra ningún error. Una vez conseguido, reiniciamos Nagios:

/etc/init.d/nagios3 restart

Si nos vamos a la interfaz web de Nagios e intentamos forzar un check de los servicios en todos los hosts, nos dará un error porque Nagios por defecto no ejecute comandos externos. El error en cuestión es el siguiente:

Could not stat() command file ‘/var/lib/nagios3/rw/nagios.cmd’!

Para arreglar esto, editamos el archivo /etc/nagios3/nagios.cfg y nos vamos a la línea donde se encuentra la directiva ‘check_external_commands’ y le ponemos un valor igual a 1, como en la imagen:

c3 external commands.png

Ejecutamos los siguientes comandos:

/etc/init.d/nagios3 stop

dpkg-statoverride —update —add nagios www-data 2710 /var/lib/nagios3/rw

dpkg-statoverride —update —add nagios nagios 751 /var/lib/nagios3

/etc/init.d/nagios3 start

Ahora ya deberá funcionar correctamente la interfaz web, le pidamos lo que le pidamos…
El siguiente paso es configurar el envío de correos electrónicos. En el primer archivo que editamos pusimos la configuración de los contactos a los que les tenía que llegar el correo y ahora vamos a configurar el envío de los mails. Hay varios modos de hacerlo (Con scripts de Perl, usando un servidor de correo local, un smarthost, etc.). En mi caso he instalado y configurado un Postfix en el propio servidor de Nagios para que mande los emails usando un servidor de correo externo.
Instalamos Postfix:

aptitude install postfix

Durante la instalación, le diremos que vamos a usar un SmartHost y le pondremos el nombre de nuestro servidor de correo. Por ejemplo: smtp.midominio.com
Una vez instalado, creamos el archivo /etc/postfix/sasl/passwd y le introducimos la siguiente información:

[smtp.tudominio.com]:25 tucuenta@tudominio.com:TuPassword

Guardamos el archivo y ahora le asignamos los permisos correspondientes:

chmod 600 /etc/postfix/sasl/passwd

Y por último lo transformamos en un fichero indexado de tipo hash con la ayuda de postmap:

postmap /etc/postfix/sasl/passwd

Reiniciamos Postfix (/etc/init.d/postfix restart) y para probar el envío ejecutamos:

mail -s “Prueba” tucorreo@tudominio.com

Debemos pulsar CTRL+D para que envíe

Y nos debería de llegar el correo…

Para monitorear equipos con Linux o dispositivos de red a los que solo queramos hacerle un ping, con esto será bastante. Pero como supongo que también habrá que controlar máquinas Windows, vamos a seguir con la configuración. Ahora vamos a editar el archivo /etc/nagios-plugins/config/nt.cfg y lo dejamos así:

# ‘check_nt’ command definition

define command{

command_name check_nt

command_line /usr/lib/nagios/plugins/check_nt -H $HOSTADDRESS$ -p 12489 -s TuPassword -v $ARG1$ $ARG2$

}

Reiniciamos el Nagios para que valide los cambios y ahora vamos a configurar los equipos Windows. Para que Nagios recupere la información de estos equipos, vamos a instalarle un cliente llamado NSClient++. Lo podemos descargar de aquí. Como este cliente no es solo para Nagios, tendremos que hacer unos cuantos ajustes en su configuración para que funcione correctamente.

Durante la instalación, le diremos la IP del servidor Nagios, así como la contraseña que escribimos antes en el archivo /etc/nagios-plugins/config/nt.cfg. A la hora de seleccionar la ventana con los “checks”, marcaremos todos menos la última opción (WMI Checks…creo que se llamaba). Cuando nos pregunté si queremos iniciar el servicio, le decimos que NO.

Ahora deberemos seguir 5 pasos para terminar de configurar el cliente.

1. Nos vamos al administrador de servicios, buscamos el servicio del NSClient y le damos a ver sus propiedades. Debemos marcar la casilla que “Permite a los servicios interactuar con el escritorio”. Lo tenemos en la siguiente imagen:

Todavía NO inciamos el servicio. Sigamos.

El archivo de configuración se llama NSC.ini y se encuentra en el directorio donde hemos instalado el cliente (Normalmente en Archivos de Programa >> NSclient). Este archivo consta de varias secciones con distintas directivas en cada una. Vamos a seguir los 4 pasos restantes:

2. Dentro de la sección [Modules] vamos a descomentar todo, a excepción de las directivas ‘RemoteConfiguration.dll’ y ‘CheckWMI.dll’. También descomentamos la directiva ‘Password’ y le ponemos la contraseña que pusimos durante la instalación del cliente

3. Ahora, en la sección [Settings], descomentamos la directiva ‘allowed_host’ y le ponemos la IP del servidor Nagios.

4. En la sección [NSClient], descomentamos la directiva ‘port’, dejando el número de puerto establecido por defecto.

5. Por último, desde una ventana de MS-DOS, ejecutamos el comando: lodctr /R. Con este comando, aunque no es obligatorio, reiniciamos los contadores de rendimiento y demás, evitando errores como el de la siguiente imagen:

Pues ya hemos terminado. Ahora, si apuntamos a la interfaz web de Nagios y nos validamos, debería de aparecernos algo parecido a esto: (Variará según los equipos que hayáis dado de alta)

Leer más…

Categorías:Debian Linux, Monitorización Etiquetas:

Backups con Bacula (II)

29 septiembre, 2010 9 comentarios

Bueno, continuemos. La primera parte del artículo esta aquí.

Una vez hecha la copia de seguridad de todos los archivos de configuración, vamos a instalar el paquete necesario para que Bacula use MySQL para guardar su base de datos.

Primero, instalemos el servidor MySQL:

aptitude install mysql-server

Durante la instalación, nos pedirá la contraseña del usuario root de MySQL y algunas cosas más.

Luego, instalaremos el paquete necesario para que Bacula use MySQL:

aptitude install bacula-director-mysql

A mi, personalmente, me gusta usar phpmyadmin para gestionar las bases de datos de MySQL. Para instalarlo:

aptitude install phpmyadmin

Una vez esté todo instalado, ya podemos empezar a configurar Bacula.

Lo primero que hago es saber donde voy a almacenar mis copias de seguridad. En mi caso, lo haré en un disco de red al que accederé montando una carpeta en Debian que apunta a un recurso compartido por el disco de red.

Para montar esa unidad, primero creo el directorio con el siguiente comando:

mkdir /mnt/bacula

Una vez creado, monto en ese diectorio la carpeta del disco de red con el siguiente comando:

mount -t smbfs -o usuario@dominio,password=Password //192.168.1.240/bacula /mnt/bacula

Lo probamos, y si funciona, creamos un script que contenga el comando anterior y lo copiamos en la carpeta /etc/init.d. Luego, ejecutamos el siguiente comando para que el script se ejecute siempre al arranque de nuestro sistema:

update-rc.d montar_carpetas_bacula.sh defaults

Aclaración: montar_carpetas_bacula.sh es el nombre que le he dado al script que he creado. Luego le di permisos 744 y de ejecución, antes de copiarlo a la carpeta /etc/init.d

Ahora, vamos a empezar a tocar los archivos de configuración de Bacula. Vamos a empezar por los más sencillos, pero antes debemos modificar unos parámetros del archivo principal. Para ello:

nano /etc/bacula/bacula-dir.conf

Aquí modificamos el nombre del demonio Director y le ponemos una IP (En este caso el propio ordenador) y le establecemos una contraseña.

Continuemos editando los archivos más sencillos. Nos vamos a editar el bconsole.conf:

Le ponemos el nombre y la contraseña del Director. Guardamos y salimos (Si usamos nano sería un CTRL+O y CTRL+X, respectivamente)

Ahora vamos a por el bacula-sd.conf:

En el punto 1, configuramos el nombre y la IP del propio demonio. En el 2, le ponemos los datos del Director. En el 3, ponemos los datos para el Tray Monitor (Ya lo veremos más adelante). En punto 4 es un ejemplo de un dispositivo donde guardar las copias de seguridad. (En nuestro caso, es un archivo). Si queremos guardar las copias de cada equipo/servidor en carpetas diferentes, deberemos crear un dispositivo por cada equipo/servidor.configuración

Continuamos con el bacula-fd.conf. La configuración es muy parecida al archivo anterior:

En el punto 1, configuramos los datos del director. En el 2, los del Tray Monitor. En el 3, el nombre y la IP del propio demonio y en el 4, la configuración de los envíos de alertas por email. Este archivo es el que tendremos que modificar en cada cliente del que hagamos copias de seguridad. Ya lo iremos viendo…

El archivo que nos queda por configurar, el bacula-dir.conf, es el principal. En el vamos a poner cuando se hacen las copias, de que clientes, que tipo de copias, etc. Voy a poner una breve descripción de cada apartado que configuraremos dentro de este archivo y un ejemplo de cada uno:

Director

En el configuraremos (Aunque ya lo hicimos anteriormente) los datos del propio demonio (Su IP, nombre, puerto a usar, etc.) En mi caso, la configuración quedó así:

Director { # define myself

Name = vSRVDebian-dir

DIRport = 9101 # where we listen for UA connections

QueryFile = “/etc/bacula/scripts/query.sql”

WorkingDirectory = “/var/lib/bacula”

PidDirectory = “/var/run/bacula”

Maximum Concurrent Jobs = 3

Password = “*****************” # Console password

Messages = Daemon

DirAddress = 127.0.0.1

}

Catalogo

Aquí vamos a definir los datos del Catálogo, que es la base de datos que usa Bacula. Pondremos el nombre de la base de datos, así como su usuario y contraseña. (Estos datos los pusimos cuando instalamos el paquete bacula-director-mysql). En mi caso queda así:

# Generic catalog service

Catalog {

Name = Catalogo

dbname = “bacula”; dbuser = “bacula”; dbpassword = “************”

}

Clientes (File Services)

En este apartado tendremos que “dar de alta” a todos los clientes de los que realizaremos copia de seguridad:

# Client (File Services) to backup

Client {

Name = vSRVDebianWS1-fd

Address = 192.168.1.103

FDPort = 9102

Catalog = Catalogo

Password = “*******************” # password for FileDaemon

File Retention = 30 days # 30 days

Job Retention = 6 months # six months

AutoPrune = yes # Prune expired Jobs/Files

}

Client {

Name = vSRVApliWeb-fd

Address = 192.168.1.47

FDPort = 9102

Catalog = Catalogo

Password = “************” # password for FileDaemon

File Retention = 30 days # 30 days

Job Retention = 6 months # six months

AutoPrune = yes # Prune expired Jobs/Files

}

Client {

Name = vSRVDebian-fd

Address = 192.168.1.115

FDPort = 9102

Catalog = Catalogo

Password = “**************” # password for FileDaemon

File Retention = 30 days # 30 days

Job Retention = 6 months # six months

AutoPrune = yes # Prune expired Jobs/Files

}

JobDefs

En un Jobdef podemos tener las mismas directivas que un job (Tarea). Al crear un jobdef, no estamos creando una tarea, sino que estamos configurando una serie de directivas “por defecto” que podremos usar para configurar uno o varios jobs, ahorrándonos muchas líneas de configuración. Por ejemplo: Tenemos varios servidores Linux de los que deseamos hacer copias de seguridad completas. En vez de crear varios jobs con todas sus directivas en cada uno, creamos varios jobs a los que le decimos que se “alimenten” de las directivas del jobdef. Si repetimos una directiva en el job, que ya esté referenciada en el jobdef, Bacula usará la opción que hayamos puesto en el job.

JobDefs {

Name = “JD-vSRVDebianWS1″

Type = Backup

Level = Incremental

Client = vSRVDebianWS1-fd

FileSet = “LinuxCompleto”

Schedule = “CicloSemanal”

Storage = FS-vSRVDebianWS1

Messages = Standard

Pool = Pool-vSRVDebianWS1

Priority = 10

}

JobDefs {

Name = “JD-vSRVApliWeb”

Type = Backup

Level = Incremental

Client = vSRVApliWeb-fd

FileSet = “Alfresco”

Schedule = “CicloSemanal”

Storage = FS-vSRVApliWeb

Messages = Standard

Pool = Pool-vSRVApliWeb

Priority = 10

}

JobDefs {

Name = “JD-vSRVDebian”

Type = Backup

Level = Incremental

Client = vSRVDebian-fd

FileSet = “LinuxCompleto”

Schedule = “CicloSemanal”

Storage = FS-vSRVDebian

Messages = Standard

Pool = Pool-vSRVDebian

Priority = 10

}

Jobs

Los jobs son las “tareas” que deberá realizar Bacula. Pueden ser de backup, restauración, etc. Como dije antes, las tengo referenciadas a jobdefs.

# Define the main nightly save backup job

# By default, this job will back up to disk in /nonexistant/path/to/file/archive/dir

Job {

Name = “Backup-vSRVDebianWS1″

JobDefs = “JD-vSRVDebianWS1″

Write Bootstrap = “/mnt/bacula/vSRVDebianWS1/vSRVDebianWS1.bsr”

}

Job {

Name = “Backup-vSRVApliWeb”

JobDefs = “JD-vSRVApliWeb”

Write Bootstrap = “/mnt/bacula/vSRVApliWeb/vSRVApliWeb.bsr”

}

Job {

Name = “Backup-vSRVDebian”

JobDefs = “JD-vSRVDebian”

Write Bootstrap = “/mnt/bacula/vSRVDebian/vSRVDebian.bsr”

}

# Backup the catalog database (after the nightly save)

Job {

Name = “Backup-Catalog”

JobDefs = “JD-Catalogo”

# This creates an ASCII copy of the catalog

# WARNING!!! Passing the password via the command line is insecure.

# see comments in make_catalog_backup for details.

# Arguments to make_catalog_backup are:

# make_catalog_backup

RunBeforeJob = “/etc/bacula/scripts/make_catalog_backup bacula bacula ********* 127.0.0.1″

# This deletes the copy of the catalog

RunAfterJob = “/etc/bacula/scripts/delete_catalog_backup”

Write Bootstrap = “/var/lib/bacula/BackupCatalog.bsr”

Priority = 11 # run after main backup

}

#

# Standard Restore template, to be changed by Console program

# Only one such job is needed for all Jobs/Clients/Storage …

#

Job {

Name = “Restaurar-vSRVDebianWS1″

Type = Restore

Client=vSRVDebianWS1-fd

FileSet=”LinuxCompleto”

Storage = FS-vSRVDebianWS1

Pool = Pool-vSRVDebianWS1

Messages = Standard

Where = /mnt/bacula/restaurar/vSRVDebianWS1

}

Job {

Name = “Restaurar-vSRVApliWeb”

Type = Restore

Client=vSRVApliWeb-fd

FileSet=”Alfresco”

Storage = FS-vSRVApliWeb

Pool = Pool-vSRVApliWeb

Messages = Standard

Where = /mnt/bacula/restaurar/vSRVApliWeb

}

Job {

Name = “Restaurar-vSRVDebian”

Type = Restore

Client=vSRVDebian-fd

FileSet=”LinuxCompleto”

Storage = FS-vSRVDebian

Pool = Pool-vSRVDebian

Messages = Standard

Where = /mnt/bacula/restaurar/vSRVDebian

}

Job {

Name = “Restaurar-Catalogo”

Type = Restore

Client=vSRVDebian-fd

FileSet=”Catalogo”

Storage = FS-Catalogo

Pool = Pool-Catalogo

Messages = Standard

Where = /mnt/bacula/restaurar/catalogo

}

Schedules

Los “schedules” son las programaciones horarias con las que se realizaran los trabajos. Yo he optado por dejar la que trae Bacula, ya que me parece buena para los servidores de los que tengo que realizar copias de seguridad. Por defecto, hace copias completas el primer domingo de cada mes, diferenciales el resto de domingos del mes e incrementales todos los demás días.

Schedule {

Name = “CicloSemanal”

Run = Full 1st sun at 02:00

Run = Differential 2nd-5th sun at 02:00

Run = Incremental mon-sat at 02:00

}

# This schedule does the catalog. It starts after the WeeklyCycle

Schedule {

Name = “CicloSemanalDespuesBackup”

Run = Full sun-sat at 23:10

}

Filesets

Los filesets son las listas de archivos de los que queremos hacer copias de seguridad. Aquí incluyo listas de ejemplo de servidores Linux y de servidores Windows.

# List of files to be backed up

FileSet {

Name = “LinuxCompleto”

Include {

Options {

signature = MD5

}

File = /

}

Exclude {

File = /proc

File = /tmp

File = /.journal

File = /.fsck

}

}

FileSet {

Name = “Alfresco”

Enable VSS = yes

Include {

Options {

signature = MD5

}

File = “C:/Alfresco”

}

}

FileSet {

Name = “Catalogo”

Include {

Options {

signature = MD5

}

}

File = /var/lib/bacula/bacula.sql

}

}

Storages

Aqui damos de alta los dispositivos que pusimos en el archivo bacula-sd.conf.

# Definition of file storage device

Storage {

Name = FS-vSRVDebianWS1

Address = 192.168.1.115 # N.B. Use a fully qualified name here

SDPort = 9103

Password = “***************”

Device = FS-vSRVDebianWS1

Media Type = File

}

Storage {

Name = FS-vSRVApliWeb

Address = 192.168.1.115 # N.B. Use a fully qualified name here

SDPort = 9103

Password = “***************”

Device = FS-vSRVApliWeb

Media Type = File

}

Storage {

Name = FS-vSRVDebian

Address = 192.168.1.115 # N.B. Use a fully qualified name here

SDPort = 9103

Password = “***************”

Device = FS-vSRVDebian

Media Type = File

}

Storage {

Name = FS-Catalogo

Address = 192.168.1.115 # N.B. Use a fully qualified name here

SDPort = 9103

Password = “***************”

Device = FS-Catalogo

Media Type = File

}

Pools

Un Pool es un “almacén” de volúmenes. Un volumen es un dispositivo donde Bacula almacenará las copias de seguridad (Una cinta, un archivo, un DVD, etc.). Los volúmenes no los creamos aquí, lo haremos posteriormente desde la consola de Bacula.

# Default pool definition

Pool {

Name = Pool-vSRVDebianWS1

Pool Type = Backup

Recycle = yes # Bacula can automatically recycle Volumes

AutoPrune = yes # Prune expired volumes

Volume Retention = 365 days # one year

}

Pool {

Name = Pool-vSRVApliWeb

Pool Type = Backup

Recycle = yes # Bacula can automatically recycle Volumes

AutoPrune = yes # Prune expired volumes

Volume Retention = 365 days # one year

}

Pool {

Name = Pool-vSRVDebian

Pool Type = Backup

Recycle = yes # Bacula can automatically recycle Volumes

AutoPrune = yes # Prune expired volumes

Volume Retention = 365 days # one year

}

Pool {

Name = Pool-Catalogo

Pool Type = Backup

Recycle = yes # Bacula can automatically recycle Volumes

AutoPrune = yes # Prune expired volumes

Volume Retention = 365 days # one year

}

Emails

Esta es la última directiva que tendremos que configurar. Es la que nos permitirá enviar los emails a través de Bacula. Para ello, Bacula usa bsmtp. Con solo añadir nuestros servidor de correo electrónico e introducir las direcciones a las que queremos que lleguen los emails, estará todo listo.

# Reasonable message delivery — send most everything to email address

# and to the console

Messages {

Name = Standard

#

# NOTE! If you send to two email or more email addresses, you will need

# to replace the %r in the from field (-f part) with a single valid

# email address in both the mailcommand and the operatorcommand.

# What this does is, it sets the email address that emails would display

# in the FROM field, which is by default the same email as they’re being

# sent to. However, if you send email to more than one address, then

# you’ll have to set the FROM address manually, to a single address.

# for example, a ‘no-reply@mydomain.com’, is better since that tends to

# tell (most) people that its coming from an automated source.

#

mailcommand = “/usr/lib/bacula/bsmtp -h mail.tu-dominio.com -f \”\(Bacula\) \\” -s \”Bacula: %t %e of %c %l\” %r”

operatorcommand = “/usr/lib/bacula/bsmtp -h mail.tu-dominio.com -f \”\(Bacula\) \\” -s \”Bacula: Intervention needed for %j\” %r”

mail = alertas@tu-dominio.com = all, !skipped

operator = alertas@tu-dominio.com = mount

console = all, !skipped, !saved

#

# WARNING! the following will create a file that you must cycle from

# time to time as it will grow indefinitely. However, it will

# also keep all your messages if they scroll off the console.

#

append = “/var/lib/bacula/log” = all, !skipped

}

Una vez hecho esto, solo tendremos que reiniciar los demonios de Bacula e instalar los clientes en los equipos/Servidores que queramos. En los clientes, modificaremos en el archivo bacula-fd.conf y le pondremos los datos del demonio Director de Bacula.

Para probar todo, arrancamos la consola de bacula con el comando “bconsole”, creamos los volúmenes con el comando “label” y escribimos “run” desde dentro de esta consola. Nos saldrá una lista con todos nuestros trabajos y solo tendremos que elegir uno.

Si queremos comprobar el estado de los demonios de bacula, ejecutaremos el comando “status”.

Y, por último, para restaurar algo, o bien usamos las tareas de restauración que hemos creado, o bien ejecutamos el comando “restore”.

De este modo es como lo he configurado. Seguro que hay mejores modos de hacerlo, pero a mí de este me funciona bien. Una última cosa, tened siempre a mano una copia del catálogo de Bacula y los archivos bootstrap intentad ponerlos en un sitio que también tengáis a mano. Harán falta si queremos recuperarnos de un desastre.


Categorías:Backup, Debian Linux

Backups con Bacula (I)

20 septiembre, 2010 Deja un comentario

Hoy, lo único “especial” que he hecho, además de resolver problemas sin mucha ciencia, ha sido empezar a configurar un sistema decopias de seguridad o backup con Bacula en un Debian. Para quien no sepa de lo que hablo, que lea un pocosobre Bacula…y un poco sobre Debian.

Una vez que lo hayáis leído, habréis visto que Bacula es un sistema de copias de seguridad bastante completo y que seguro cumplirá con la gran mayoría de necesidades que una empresa necesita en sus sistemas de backup.

Hago un inciso muy importante…una empresa que no tiene un buen sistema de copias de seguridad…no tiene datos. Al menos así lo pienso yo.

Continuo por donde iba…normalmente en mi empresa usamos elSymantec Backup Exec para realizar las copias de seguridad. Nos va muy bien, no tenemos quejas, salvo cada vez que hay que pagar licencias por usarlo. En este caso, como voy a hacer copias de seguridad de máquinas virtuales Linux, me sobra con Bacula. ¿No sabes lo que es una máquina virtual? Léete algo sobre lasmaquinas virtuales.

Bueno, la instalación de Bacula en Debian es muy sencilla…todo se limita a un:

  • aptitude install bacula

Pero una vez instalado, empiezan las “complicaciones”. Que si quiero usar MySQL como sistema gestor de base de datos, que si no me conectan los demonios entre sí, que no tengo ni idea de como configurar una copia de seguridad, que si no tiene una interfaz gráfica para su administración (Aunque esto no es totalmente cierto…), pero cuando vas profundizando, te das cuenta que es relativamente sencillo de entender en cuanto a su funcionamiento.

Personalmente, prefiero perder mucho tiempo al principio configurando todo lo que necesito como es debido, que configurar las 4 cosas para salir al paso y después verme con problemas que podrían haber tenido solución si hubiese hecho las cosas como es debido.

En informática nunca vayais a salir del paso. Si teneis un problema, hay que intentar dar la mejor solución siempre. Un “Ahora lo hago así y ya lo cambiaré” no vale. Al final no lo cambias, y cuando te das cuenta, la bola ha crecido demasiado y tienes un verdadero problema encima de la mesa. Así que hay que intentar siempre dejarlo todo lo más cerrado posible (Se que hay muchas veces que el tiempo o la urgencia del problema no lo permite, pero siempre hay que intentarlo…)

Voy a realizar una pequeña descripción Bacula y de sus archivos de configuración. Os aviso de que no soy partidario de escribir “recetas mágicas” que todo el mundo pueda copiar y pegar para que funcionen correctamente. Para algunos casos pueden venir bien, pero siempre prefiero entender lo que estoy haciendo, porque si el día de mañana tengo un problema (Seguro que llegan) seré capaz de afrontarlo. Si hago un copy&paste, no me entero de lo que estoy haciendo(Si…de acuerdo, en algunos casos sí xD), y al más mínimo problema…batacazo.

Aun así, intentaré contar como lo he hecho yo (No quiere decir que este bien, porque todo se puede mejorar) paso a paso. Para que cualquiera pueda configurarlo pero sabiendo lo que está haciendo en cada momento.

Bacula no es más (Ni menos) que un conjunto de demonios que interactúan entre sí para realizar las copias de seguridad. Estos demonios pueden residir en el mismo host…o no. A Bacula le es indiferente mientras que le indiquemos correctamente donde está cada uno. Bueno, vamos al lío.

Vamos a definir los demonios de Bacula:

  1. Director (Demonio bacula-director). Es el demonio principal de Bacula. Dice cuando, como y donde se realizan los backup o restore. Este demonio tiene que correr en una máquina con acceso a la base de datos (Catálogo). Su archivo de configuración es:bacula-dir.conf
  2. Storage (Demonio bacula-storage). Es el demonio que se encarga de administrar los dispositivos físicos sobre los que se realizaran los backups. Su archivo de configuración:bacula-fd.conf
  3. File (Demonio bacula-file). Es un agente que debe de estar corriendo en la maquina de cuyos datos queramos realizar un backup. Resumiendo: Empaqueta los datos y se los pasa al demonio bacula-storage para que los “guarde” en los dispositivos físicos. Su archivo de configuración:bacula-sd.conf

Independientemente de estos demonios, hay otras dos cosas que debemos de saber que existen. Una de ellas es el Catálogo y la otra es la consola de bacula.

El Catálogo es la base de datos donde Bacula va a almacenar que copias de seguridad se han hecho, cuando, donde están los archivos, etc. Es muy importante realizar copias de seguridad del Catálogo cada vez que se realice un backup de cualquier máquina. Esto viene configurado por defecto en Bacula, ya lo veremos más adelante.

La consola es la interfaz de administración de Bacula. Desde aquí crearemos los Volumenes (Paciencia, ya veremos que son), ejecutaremos trabajos, los cancelaremos, veremos el estado del servidor, cliente, etc. En resumen, desde aquí gestionaremos Bacula. Es una consola bastante intuitiva y fácil de utilizar. No os asustéis los que solo estáis acostumbrados a funcionar a golpe de ratón. La consola tiene su propio archivo de configuración:bconsole.conf

En Debian, los archivos de configuración se encuentran en el directorio /etc/bacula. Una costumbre que tengo antes de tocar nada, es realizar una copia de seguridad de los archivos de configuración. Así, si metemos la pata (Casi seguro que lo haremos) podemos volver al estado inicial. Por ejemplo, para realizar una copia de seguridad de la configuración del bacula-director, ejecutaremos el siguiente comando:

  • cp /etc/bacula/bacula-dir.conf /etc/bacula/bacula-dir.conf.original

Cuando hagamos esto, ya estaremos tranquilos para poder trabajar con libertad y sin miedo a meter la mata (Aunque esto tampoco es malo…más bien es recomendable, porque así es como se aprende mejor)

En cuanto tenga tiempo, intentaré describir las partes que componen cada archivo de configuración, para que no tengamos problemas en realizar los cambios necesarios a los archivos para adaptarlos a nuestras necesidades.

PD: Que no se me olvide cambiar el motor de BD que usa por defecto Bacula por MySQL.


Categorías:Backup, Debian Linux

Cabina Dell PowerVault MD3000i

13 septiembre, 2010 7 comentarios

Vamos a ver como se instala y configura una Cabina de discos Dell PowerVault MD3000i.

Antes de instalar nada, hay que tener clara la estructura de red, direcciones IP y demás que vamos a asignar a los diferentes dispositivos.

Esta cabina dispone de dos módulos de conexión para proporcionar redundancia. Cada modulo tiene 2 puertos iSCSI y uno de gestión (Ethernet). Por lo tanto, habrá que asignar tres direcciones IP por cada módulo.

En mi caso, he decidido usar las siguientes direcciones IP:

Modulo 1
Puerto ethernet de gestión: 192.168.2.250 255.255.255.0
Puerto iSCSI 0: 10.0.0.2 255.0.0.0
Puerto iSCSI 1: 10.0.0.3 255.0.0.0

Modulo 2
Puerto ethernet de gestión: 192.168.2.249 255.255.255.0
Puerto iSCSI 0: 10.0.0.4 255.0.0.0
Puerto iSCSI 1: 10.0.0.5 255.0.0.0

Ahora vamos a asignar las direcciones IP a las tarjetas de nuestro servidor. Lo ideal sería disponer de 4 tarjetas de red en cada servidor que queramos conectar a la cabina de discos. De este modo, tendríamos una redundancia completa. Las tarjetas de red se van a conectar del siguiente modo:

Tarjeta de red 1: Red interna de la Empresa (La misma que los puertos ethernet de gestión de la cabina)
Tarjeta de red 2: Red interna de la Empresa (La misma que los puertos ethernet de gestión de la cabina) pero a un switch diferente de donde esté la tarjeta de red 1.
Tarjeta de red 3 (iSCSI): Puerto 0 del módulo 1 de la cabina
Tarjeta de red 4 (iSCSI): Puerto 0 del módulo 2 de la cabina

Las direcciones IP que le vamos a asignar van a ser las siguientes:
Tarjeta de red 1: 192.168.2.5 255.255.255.0
Tarjeta de red 2: 192.168.2.4 255.255.255.0
Tarjeta de red 3: 10.0.0.6 255.0.0.0
Tarjeta de red 4: 10.0.0.7 255.0.0.0

Si observamos, todo el tráfico iSCSI está una red diferente a la red local de la Empresa. Esto es una buena práctica.

Una vez esté todo conectado, vamos a comenzar a configurar la cabina. Para ello, la cabina dispone de un software de gestión que debemos instalar en un ordenador con un sistema operativo de Microsoft (Preferiblemente el servidor al que estará conectada la cabina). El programa se llama Modular Disk Storage Management Client. Aquí tenemos un manual de como se usa dicho programa.

Durante la instalación del mismo, nos pedirá que actualicemos dos componentes de Windows (Si no lo tenemos actualizados). Si no lo tenemos, hacemos click y lo instalará de manera automática. También nos pedirá que instalemos el Microsoft iSCSI Initiator. Yo recomiendo instalar la última versión directamente de Microsoft, ya que es una versión más moderno que el que nos proporciona Dell.

Nota: Al instalar el Microsoft iSCSI Inititator, es muy importante marcar la casilla para que instale el multipath. Si no, podríamos tener problemas en la configuración del acceso a la cabina.

Este programa nos permitirá, posteriormente, conectar el sistema operativo de Microsoft con la cabina de almacenamiento.

Una vez hecho todo lo anterior, se instalará el programa de gestión de la cabina de discos.

Este es el programa de gestión de la cabina de discos

Y este el Microsoft iSCSI Inititator

Vamos a ejecutar el programa:

Cuando se abra, le damos a Añadir Matriz y le decimos que la busque en modo automático.

Cuando el programa encuentre la matriz, la añadirá de modo automático y nos aparecerá la venta con el asistente que nos ayudará en la configuración inicial:

Los primeros pasos son sencillos y solo se trata de rellenar los datos que nos vaya pidiendo. Vamos a salta directamente a la parte de la configuración de los puertos iSCSI.

En la siguiente ventana se configurarán los 4 puertos iSCSI de los que disponemos en la cabina (Recuerdo que era 2 por cada módulo). Simplemente introduciremos los datos de las direcciones IP que habíamos anotado con anterioridad (No es necesario poner una puerta de enlace)

Luego, vamos a hacer lo mismo pero con los puertos ethernet de gestión, estableciéndole las direcciones IP que también habíamos anotado con anterioridad.

Una vez que hemos configurado la conectividad de la cabina, vamos a proceder a configurar los discos.

Aquí, una vez más, tenemos que tomar una decisión antes de ponernos manos a la obra. En este caso se trata de que tipo de RAID vamos a elegir para nuestra cabina. En mi caso, dispongo de 6 discos SAS a 15.000 R.P.M.

En principio podríamos optar por dos estrategias: Una RAID 6 o una RAID 5 más un disco de reserva. Para el que no sepa lo que es una RAID, puede leerse esto.

En ambos casos, perderíamos dos discos de los seis que disponemos, por lo que el tamaño disponible no era un factor importante a la hora de tomar una decisión.

Al final, me decidí por una RAID 5 más un disco de reserva, por la velocidad de la propia RAID y porque además uno de los discos estaría sin usar, permaneciendo en mejor estado para un posible uso. Una vez decidido lo que vamos a hacer, podemos continuar.

Nos vamos al paso 7 de nuestro asistente y hacemos click en configuración manual/configurar discos físicos de reserva activa.

Hacemos click en asignar y elegimos el número de discos que queremos dejar en reserva. En mi caso, solo dejaré uno.

Ahora, nos vamos a la pestaña Configuración y hacemos click en Crear grupos de discos y discos virtuales. En este asistente, solo deberemos introducir la información de la RAID que hemos decido usar, así como el número de discos virtuales de los que queremos disponer. En mi caso, todo el espacio disponible lo he asignado a un único disco virtual.

Una vez configurada la RAID y creado el disco virtual, lo único que nos queda por crear son los servidores que tendrán acceso a estos discos virtuales.

Para ello, primero hay que dar de “alta” al servidor. En principio vamos a crear un grupo de servidores al que posteriormente iremos añadiendo todos las máquinas que tendrán acceso al disco virtual. Nos vamos a Configuración–> Crear grupo de sist. principal y seguimos el asistente.

Ahora vamos a dar de alta los servidores y a añadirlos al grupo que hemos creado anteriormente. Nos vamos a configuración–>Configurar acceso al sistema principal. Añadimos uno nuevo y lo damos de alta. Nos pedirá el nombre de iniciador iSCSI y su etiqueta. Para saber el nombre, abrimos el programa Microsoft iSCSI Inititator y lo copiamos de ahí. Luego, lo pegamos en la casilla correspondiente. En la etiqueta podemos poner o que queramos, puesto que solo tiene funciones indicativas.

En la siguiente ventana le ponemos nombre al host y le decimos que tipo de Sistema Operativo tiene.

Para terminar, le decimos que este sistema va a compartir el disco con otros servidores (Si este es nuestro caso) y lo añadimos al grupo que hemos creado anteriormente. NOTA: Aconsejo hacerlo siempre de este modo aunque en principio solo tengamos un servidor. También funcionará y si en un futuro tenemos otro diferente, solo tendremos que añadirlo al grupo que creamos antes.

El último paso, es asignar el disco virtual al grupo de servidores que hemos creado. Nos vamos al menú configuración–>Crear asignaciones del sist. principal al disco virtual.

Seleccionamos nuestro grupo de hosts y le damos a siguiente. Simplemente tendremos que seguir el asistente.

Una vez hecho todo lo anterior y si todo ha ido bien. La pantalla principal del programa debería tener un aspecto parecido a este.

Ya hemos terminado de configurar la cabina de discos. Ahora hay que enlazar los servidores con el disco virtual que hemos creado. Abrimos el Micosoft iSCSI Initiator y le damos a “Add target portal”. Aquí hay que tener en cuenta los datos que introducimos (Ojo, si nos equivocamos no pasará nada, simplemente que el Sistema Operativo no conectará con el disco virtual). No estaría de más tener un papel con todas las IP´s que asignamos al principio y como conectamos los cables.

En el campo IP, pondremos la IP que le asignamos al puerto iSCSI número 0 del módulo 1. Le damos a avanzado. En la primera casilla siempre hay que poner Microsoft iSCSI Initiator y en el siguiente campo, la IP de la tarjeta de red que está conectada directamente al puerto 0 del módulo 1.

Repetimos los pasos anteriores para añadir el otro puerto iSCSI (Puerto 0 del módulo 2) y la tarjeta de red que está conectada directamente a este puerto. Al final debería de queda algo así.

De manera automática, nos debería de aparecer en el Microsoft iSCSI Initiator la conexión al disco virtual y todo debería de funcionar. Bueno, todo, menos la redundancia en caso de caida de la tarjeta de red del servidor que está conectada al puerto 0 del módulo 1. Para configurar esta redundancia y que si esta tarjeta (O el módulo 1 de la cabina) cae, todo siga funcionando, nos queda un último paso.

Vamos a crear una segunda conexión usando la tarjeta de red que está conectada al puerto 0 del módulo 2. Pinchamos en Log on, marcamos las casillas tal y como están en la imagen (Muy importante activar el multipath) y le damos a avanzado. En el primer campo ponemos la IP de la tarjeta de red del servidor y en el segundo campo, la IP del puerto 0 del módulo 2 de la cabina.

Si le damos a las propiedades del Target, veremos que tendremos dos conexiones y que las dos tendrán el estado de “Conectadas”

Si todo ha salido bien, ya debería de estar todo funcionando. Nos iríamos al administrador de discos y nos debería de aparecer el disco virtual con el tamaño que le asignamos. Solo tendríamos que “formatearlo” y asignarle una letra para poder comenzar a introducir información.

NOTAS IMPORTANTES:

  • Cuando configuramos las IP´s a los dispositivos de la cabina de discos, el programa de configuración parece dejar de responder. Hay que dejarlo que termine, aunque tarde mucho tiempo. Si no, tendríamos que entrar a la configuración de la cabina vía cable de consola.
  • Cada vez que cambiemos la IP a los dispositivos de la cabina (A lo mejor hay que hacer varios intentos para cambiar la misma IP), hay que eliminar la matriz del programa de configuración y volverla a añadir de modo automático. Este proceso es seguro y no se pierde la configuración de nada de lo hecho en la cabina.
  • Cuando instalamos el Microsoft iSCSI Inititator, este nos asigna un nombre. Es mejor dejarlo como está y no intentar cambiarlo, porque podríamos tener problemas al conectar con la cabina.
  • Al probar lo de la redundancia, hay que tener en cuenta que tarda un poco en hacerse efectiva, ya que la cabina tiene que “trasladar” el disco virtual de un módulo a otro.

Por si hacen falta, las IP´s que trae asignada los dispositivos de la cabina por defecto son las siguientes:

  1. Puerto de gestión del módulo 1 –> 192.168.128.101 255.255.255.0
  2. Puerto de gestión del módulo 2 –> 192.168.128.102 255.255.255.0
  3. Puerto iSCSI 0 del módulo 1 –> 192.168.130.101 255.255.255.0
  4. Puerto iSCSI 1 del módulo 1 –> 192.168.131.101 255.255.255.0
  5. Puerto iSCSI 0 del módulo 2 –> 192.168.130.102 255.255.255.0
  6. Puerto iSCSI 1 del módulo 2 –> 192.168.131.102 255.255.255.0


Categorías:SAN

Restaurar / Migrar Active Directory (Capítulo I)

20 agosto, 2010 Deja un comentario

Tengo un Windows 2003 Server que es tanto el servidor de aplicaciones como el controlador de dominio de una Empresa. Tengo que formatearlo, pero tengo que salvar el Directorio Activo a toda costa, ya que tiene la información de muchísimos usuarios, grupos, etc. Tras leer algún libro y buscar información en Internet, voy a tratar de hacer un resumen de como (Creo) se tiene que resolver este tipo de problemas.

Antes que nada un pequeño consejo: A ser posible, tener siempre el controlador de dominio en un servidor diferente al servidor de aplicaciones. Si se puede, lo ideal es tenerlo instalado en un servidor al que no tengan que acceder los usuarios para ejecutar ninguna aplicación ni nada por el estilo.

Vamos a solucionar el problema…

Tenemos un único controlador de dominio.

  1. Hacer una copia de seguridad con el NTBackup de nuestro servidor (Solo del SystemState).
  2. Formatear e instalar de nuevo Windows 2003 Server. (Nota importante: El “nuevo” servidor debe tener el mismo nombre y la misma dirección IP que el servidor que acabamos de formatear.
  3. Instalar y configurar el Servidor DNS (Cambiar las propiedades TCP/IP para que nuestro servidor apunte a el mismo como servidor DNS)
  4. Restaurar la copia de seguridad con el NTBackup.

Despues de seguir estos pasos y reiniciar, deberíamos de tener el Active Directory restaurado correctamente.

Tenemos más de un controlador de dominio.

En estos casos, se pueden realizar dos cosas: O transferir todos los Roles FSMO a otro controlador de dominio o hacer un backup con el NTBackup y llevar a cabo una restauración autoritativa del Directorio Activo.

En este artículo de DocSharing explican perfectamente como realizar este proceso y los diferentes tipos de restauración que existen.

En la siguiente entrada, me voy a centrar como llevar a cabo una transferencia de roles FSMO a otro servidor ya que a mi modo de ver es la manera más segura de realizar una “copia de seguridad” del AD. Para ello, usaré como base esta guía publicada en bujarra.com, que a


Categorías:Windows 2003 Server
Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.