Manual Respaldo
31
Curso de Respaldo en GNU/Linux (20 horas) Teoría, Guía de prácticas y ejercicios Página 1 de 31
Transcript of Manual Respaldo
Curso de Respaldo en GNU/Linux (20 horas)
Teoría, Guía de prácticas y ejercicios
Página 1 de 31
Índice de contenido
Objetivos del curso..................................................................................................3
Requisitos................................................................................................................4
Introducción a la gestión de respaldos...................................................................5
Pasos en la evolución de los respaldos................................................................5
Recomendaciones y estrategias para la ejecución de Repaldos.............................7
La Ley de Murphy para los casos de respaldos:..............................................7
¿Por qué respaldar?.............................................................................................7
Tipos de respaldos...................................................................................................9
Respaldos completos...........................................................................................9
Respaldos incrementales.....................................................................................9
Respaldos diferenciales.....................................................................................10
Media de respaldo.................................................................................................11
Cintas.................................................................................................................12
Discos.................................................................................................................12
Creación, Evaluación e Implementación de un Plan de Recuperación de
Desastres...............................................................................................................14
Programas básicos para respaldos........................................................................16
Dump y Restore.................................................................................................16
Ejemplo 1. Utilizando dump a través de ssh..................................................17
Ejemplo 2. Uso de dump a través de ssh con RSH configurada....................17
tar..........................................................................................................................17
Respaldo incrementales con Tar. Aplicación práctica para un respaldo diario:
...........................................................................................................................18
cpio....................................................................................................................19
Página 2 de 31
pax.....................................................................................................................20
Amanda..............................................................................................................20
No hacer nada...................................................................................................21
Procedimiento de restauración de emergencia.................................................21
Antes del desastre..........................................................................................21
Después del desastre.....................................................................................23
Bacula....................................................................................................................24
Instalación de Bacula ........................................................................................24
Bacula-SD....................................................................................................25
BootStrapRecord............................................................................................26
Principales archivos de configuración...........................................................27
Probando el drive de la Cinta con Bacula..........................................................27
¿Como encontrar el drive de tu cinta en Bacula?..........................................28
Arrancando la consola de Bacula...................................................................28
Ejercicios. .............................................................................................................28
Solución:............................................................................................................28
Página 3 de 31
Objetivos del curso
● Crear Estrategias y políticas de respaldos para una disponibilidad efectiva
de la información institucional y su valor en los procesos de migración.
● Instalar, configurar y puesta en operación de los servicios de Respaldo.
Requisitos
Requiere conocimientos básicos de soporte en GNU/Linux
Página 4 de 31
Introducción a la gestión de respaldos.
Las técnicas empleadas tradicionalmente en las empresas para diseñar e
implementar las políticas de respaldos (backup) y recuperación de datos han
evolucionado en los últimos años. Las causas principales han sido la evolución de
la capacidad y funcionalidad de los grandes sistemas de almacenamiento y la ya
consolidada tecnología de redes de almacenamiento SAN(Storage Area
Network). Esto, unido al considerable descenso en el coste de los productos, ha
derivado en un aumento de implantaciones de estos entornos en pequeñas y
medianas empresas.
Pasos en la evolución de los respaldos
1. Centralización de los procesos de backup gracias a la evolución en los
dispositivos de copias (capacidad de cintas y librerías robotizadas), lo que
permitía que en cada oficina solo se necesitara un operador para gestionar el
mantenimiento de las copias.
Esta centralización también conllevaba un problema como eran los cuellos de
botella que se producían en las redes de datos. La aparición de redes gigabit así
como la construcción de redes de backup paliaron el problema.
2. La Tecnología SAN( Storage Area Network) ha revolucionado los procesos de
backup. Gracias a esta tecnología una serie de servidores pueden compartir un
elemento de almacenamiento, como puede ser una librería y realizar el backup
contra el mismo medio de la misma forma que si estuviese conectada
directamente contra el. De esta forma liberamos tráfico en la red y al sistema
Página 5 de 31
gestor de realizar los procesos de backup.
3. La utilización de LUNs (Logical Unit Number) en los mecanismos de
respaldos ha permitido mejorar los procesos de copia y recuperación de datos.
La evolución de los arrays de discos permiten la creación de forma instantánea
de clones de los discos. Este mecanismo se ha aprovechado en los sistemas de
backup ya que disponemos de un conjunto de LUNs con una copia consistente de
los datos y aplicaciones, lo que nos da facilidad para realizar copias a cinta en
cualquier momento o incluso utilizar también estas LUNs para la recuperación
de información perdida, evitando el proceso y tiempo de recuperación desde
cinta.
4. El siguiente paso en la evolución es el "Serverless Backup". Consiste en dotar
de cierta inteligencia tanto a los elementos de almacenamiento como de respaldo
(discos y cintas) de forma que a la hora de realizar el backup estos sean capaces
de realizar la transferencia de los datos de uno a otro sin necesidad de un
sistema de gestión.
Página 6 de 31
Recomendaciones y estrategias para la ejecución de Repaldos.
La Ley de Murphy para los casos de respaldos:
● Si un archivo puede borrarse, se borrará.
● Si dos archivos pueden borrarse, se borrará el más importante.
● Si tenemos una copia de seguridad, no estará lo suficientemente actualizada.
Solución: tener copias de seguridad, actualizarlas con la frecuencia necesaria y
tenerla siempre disponible y operativa ante cualquier contingencia.
¿Por qué respaldar?
Las interrupciones se presentan de formas muy variadas: virus informáticos,
fallos de electricidad, errores de hardware y software, caídas de red, hackers,
errores humanos, incendios, inundaciones, entre otros. 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 negocio. Del tiempo
que tarde en reaccionar una empresa dependerá la gravedad de sus
consecuencias.
Página 7 de 31
Dentro de las tareas de mantenimiento se encuentra la realización de respaldos
periódicos del equipo. La discusión sobre los diferentes métodos existentes
puede ser muy amplia, sin embargo, presentamos algunas recomendaciones para
su ejecución:
● Para realizar backup de muchos equipos de manera combinada, será
necesario contar con un buen gestor . Amanda es una buena opción libre,
compatible con muchos sistemas Unix-like (SCO, FreeBSD, IRIX, AIX, HP-
UX, GNU/Linux), pero requiere Samba para trabajar con Windows. Otra
herramienta muy usada, que si tiene soporte para Windows, es Bacula.
● La practicidad de las cintas serán difíciles de superar.
● Es recomendable realizar respaldos full de manera periódica e
intercalarlos con respaldos parciales.
● Para que un respaldo sea útil, es indispensable que pueda ser recuperado
y para estar seguros de esto es necesario que la política de respaldo
incluya simulaciones periódicas donde restauremos nuestros sistemas
desde las cintas u otros medios de almacenamiento.
● Considerar la posibilidad de guardar copias de los respaldos en sitios
remotos, para contingencias mayores.
● Los métodos más comunes de respaldos en GNU/Linux son utilizar tar,
cpio o dump. Si no utilizamos un gestor de respaldo, dump es una opción
muy interesante por su manejo de niveles para copias incrementales y su
Página 8 de 31
integración con el sistema de archivos ext2/ext3. Como desventajas, tiene
su lentitud, y que no es compatible con todos los filesystems existentes.
● La única forma de obtener una imagen exacta del disco, con la certeza de
que no contendrá ningún tipo de inconsistencia a nivel lógico del disco, ni
a nivel transaccional de las aplicaciones, es realizar respaldos offline.
Tipos de respaldos
● Respaldos completos
● Respaldos incrementales
● Respaldos diferenciales
Respaldos completos
Un respaldo completo es aquel donde cada archivo es escrito a la media de
respaldo. Si los datos a respaldar nunca cambian, cada respaldo completo creado
será una copia exacta de la anterior.
Esta similaridad se debe al hecho de que un respaldo completo no verifica para
ver si un archivo ha cambiado desde el último respaldo; ciegamente escribe todo
a la media de respaldo, haya sido modificada o no.
Esta es la razón por la que los respaldos completos no se hacen todo el tiempo -
cada archivo es escrito a la media de respaldo. Esto significa el uso de gran
cantidad de media de respaldo aún cuando nada se haya cambiado. Respaldar
100 GB de datos cada noche cuando solamente cambió 10 MB de datos, no es
una buena solución; por eso es que se crean los respaldos incrementales.
Página 9 de 31
Respaldos incrementales
A diferencia de los respaldos completos, los respaldos incrementales primero
revisan para ver si la fecha de modificación de un archivo es más reciente que la
fecha de su último respaldo. Si no lo es, significa que el archivo no ha sido
modificado desde su último respaldo y por tanto se puede saltar esta vez. Por
otro lado, si la fecha de modificación es más reciente, el archivo ha sido
modificado y se debería copiar.
Los respaldos incrementales son utilizados en conjunto con respaldos regulares
completos (por ejemplo, un respaldo semanal completo, con respaldos
incrementales diarios).
La principal ventaja obtenida de los respaldos incrementales es que se ejecutan
muchísimo más rápido que un respaldo completo. La principal desventaja es que
restaurar un archivo dado puede implicar pasar a través de varios respaldos
incrementales hasta encontrar el archivo. Cuando se restaura un sistema de
archivos completo, es necesario restaurar el último respaldo completo y cada
respaldo incremental subsecuente.
En un intento de aliviar la necesidad de pasar a través de varios respaldos
incrementales, se puede utilizar un enfoque ligeramente diferente. Esto se
conoce como respaldo diferencial.
Respaldos diferenciales
Página 10 de 31
Los respaldos diferenciales son similares a los respaldos incrementales en que
ambos solamente copian archivos que han sido modificados. Sin embargo, los
respaldos diferenciales son acumulativos, en otras palabras, con un respaldo
diferencial, una vez que un archivo ha sido modificado continua siendo incluído
en todos los respaldos diferenciales subsecuentes hasta el próximo respaldo
completo.
Esto significa que cada respaldo diferencial contiene todos los archivos
modificados desde el último respaldo completo, haciendo posible realizar una
total restauración solamente con el último respaldo completo y el último
respaldo diferencial.
De la misma manera que la estrategia de respaldo de los respaldos
incrementales, los respaldos diferenciales siguen el mismo enfoque: un respaldo
completo periódico seguido de más frecuentes respaldos diferenciales.
El efecto de utilizar los respaldos diferenciales de esta forma es que los
respaldos diferenciales tienden a crecer un poco con el tiempo (asumiendo que
diferentes archivos son modificados con el paso del tiempo entre respaldos
completos). Esto coloca los respaldos diferenciales en un punto entre los
respaldos incrementales y los completos en términos de utilización de la media y
velocidad de los respaldos, mientras que ofrecen restauraciones completas y de
archivos individuales mucho más rápidas (debido a que hay menos respaldos en
los que buscar/restaurar).
Dadas estas características, vale la pena considerar cuidadosamente los
respaldos diferenciales.
Página 11 de 31
Media de respaldo
Los administradores de sistemas más experimentados usualmente piensan sobre
respaldos en términos de leer y escribir en cintas, pero hoy día existen otras
opciones.
En algún momento, los dispositivos de cintas eran los únicos dispositivos de
media de respaldo que se podían utilizar razonablemente para propósitos de
respaldos. Sin embargo, esto ha cambiado.
Cintas
Las cintas fueron el primer tipo de media removible disponible como medio de
almacenamiento. Tiene los beneficios de bajos costos y una capacidad de
almacenamiento razonablemente buena. Sin embargo, las cintas tienen algunas
desventajas, como por ejemplo, es susceptible a desgastarse y el acceso a los
datos en una cinta es por naturaleza secuencial.
Estos factores implican que es necesario hacer un seguimiento del uso de las
cintas (retirando las cintas una vez que hayan alcanzado el final de su vida útil) y
que las búsquedas de un archivo en cinta pueden ser una tarea bastante lenta.
Por otro lado, las cintas son uno de los medios de almacenamiento masivo menos
costosos disponibles y tienen una larga historia de confiabilidad. Esto significa
que construir una biblioteca de cintas de un buen tamaño no necesita consumir
una gran parte de su presupuesto, y puede contar con poderla utilizar ahora y en
un futuro.
Página 12 de 31
Discos
En años pasados, las unidades de disco nunca se utilizaban como medio para
respaldos. Sin embargo, los precios se han reducido tanto que, en algunos casos,
el uso de discos duros como unidades de respaldo, tiene sentido.
La razón principal para el uso de unidades de disco como medio para respaldos
sería su velocidad. No hay un medio de almacenamiento masivo más rápido
disponible. La velocidad puede ser un factor crítico cuando la ventana para hacer
el respaldo de su centro de datos es corta y la cantidad de datos a copiar es
grande.
A continuación algunas razones por las cuales el almacenamiento en disco no es
el medio ideal para respaldos.
1. Normalmente los discos duros no son removibles. Un factor clave para una
estrategia de respaldo efectiva es que se pueda retirar la media de su
centro de datos y en algún tipo de almacenamiento fuera del sitio. Un
respaldo de la base de datos de producción sentada en un disco duro medio
metro más allá de la base de datos misma no es un respaldo; es una copia.
Y las copias no son muy útiles si los datos del centro de datos y sus
contenidos (incluyendo las copias) son dañadas o destruídas por algún tipo
de evento desafortunado.
2. Las unidades de disco duro son costosas (al menos comparadas con otros
tipos de media). Hay situaciones donde el dinero realmente no es un
problema, pero en todos los demas casos, los costos asociados con el uso
de discos duros para respaldos significa que el número de copias de
respaldo se debe mantener bajo para así mantener bajos los costos
Página 13 de 31
generales. Menos copias de seguridad significa menos redundancia si por
alguna razón uno de los respaldos no se puede leer.
3. Los discos duros son frágiles. Si se le cae un disco, usted perdió el
respaldo. Es posible comprar estuches especiales que pueden reducir (pero
no eliminar completamente) este peligro, pero esto hace una propuesta
costosa aún más costosa.
4. Las unidades de disco no son media para archivado. Asumiendo que pueda
superar todos los otros problemas asociados con la realización de
respaldos a unidades de disco, debería considerar lo siguiente. La mayoría
de las organizaciones tienen varios requerimientos legales para mantener
los registros disponibles por cierto tiempo. Las posibilidades de obtener
data utilizable desde una cinta de 20 años son mucho más grandes que las
posibilidades de hacerlo desde un disco de 20 años. Por ejemplo, ¿tendrá el
hardware necesario para conectarlo a su sistema? Otra cosa a considerar
es que una unidad de disco es mucho más compleja que una unidad de
cinta. Cuando un motor de 20 años gira un plato de disco de 20 años,
causando que los cabezales de lectura/escritura de 20 años vuelen sobre la
superficie del plato, ¿cuáles son las posibilidades de que estos
componentes funcionen sin problema después de haber estado 20 años
sentados sin hacer nada?
Creación, Evaluación e Implementación de un Plan de Recuperación de Desastres
Un sitio de respaldo es vital, sin embargo es inútil sin un plan de recuperación de
desastres. Un plan de recuperación de desastres indica cada faceta del proceso
Página 14 de 31
de recuperación, incluyendo (pero no limitado) a:
● Los eventos que denotan posibles desastres.
● Las personas en la organización que tienen la autoridad para declarar un
desastre y por ende, colocar el plan en efecto.
● La secuencia de eventos necesaria para preparar el sitio de respaldo una
vez que se ha declarado un desastre.
● Los papeles y responsabilidades de todo el personal clave con respecto a
llevar a cabo el plan.
● Un inventario del hardware necesario y del software requerido para
restaurar la producción.
● Un plan listando el personal a cubrir el sitio de respaldo, incluyendo un
horario de rotación para soportar las operaciones contínuas sin quemar a
los miembros del equipo de desastres.
● La secuencia de eventos necesaria para mover las operaciones desde el
sitio de respaldo al nuevo/restaurado centro de datos.
Los planes de recuperación de desastres a menudo llenan mútiples carpetas de
hojas sueltas. Este nivel de detalle es vital porque en el evento de una
emergencia, el plan quizás sea lo único que quede de su centro de datos anterior
(además de los otros sitios de respaldo, por supuesto) para ayudarlo a
reconstruir y restaurar las operaciones.
Mientras que los planes de recuperación de desastres deberían de estar a la
mano en su sitio de trabajo, también se deberían conservar copias fuera de sus
instalaciones. De esta forma, si un desastre destruye sus instalaciones no se
eliminarán todas las copias de su plan de recuperación. Un buen lugar para
almacenar una copia es en su ubicación de almacenamiento de respaldos.
Página 15 de 31
También se pueden mantener copias del plan de recuperación de desastres en
los hogares de miembros claves de equipo, siempre y cuando esto no viole las
políticas de seguridad de la empresa.
Página 16 de 31
Programas básicos para respaldos.
Los tres principales programas para respaldos son dump, tar y cpio.
Dump y Restore
Los programas UNIX® que se han usado durante muchos años para hacer copias
de seguridad son dump y restore. Operan en las unidades como una colección de
bloques de disco, bajo la abstracción de archivos, los enlaces y directorios
creados por el sistema de archivos. Dump respalda un sistema de archivos
completo en un dispositivo. No es capaz de respaldar solamente parte de un
sistema de archivos o un árbol de directorios que se extienda por más de un
sistema de archivos. Dump no escribe archivos y directorios a cinta, escribe los
bloques de datos “crudos” (raw) que conforman los archivos y directorios.
Nota: Si utiliza dump en su directorio raíz, no respaldará /home, /usr
ni muchos otros directorios, ya que suelen ser puntos de montaje de
otros sistemas de archivos o enlaces simbólicos hacia dichos sistemas
de archivos.
Dump tiene peculiaridades que se mantienen desde sus primeros días en la
Version 6 de AT&T UNIX (alrededor de 1975). Los parámetros por defecto son
los adecuados para cintas de 9 pistas (6250 bpi), pero no para los medios de alta
densidad disponibles hoy en día (hasta 62,182 ftpi). Estos valores por defecto
deben obviarse en la línea de comandos para aprovechar la capacidad de las
unidades de cinta actuales.
También es posible respaldar datos a través de la red a una unidad de cinta
conectada a otra computadora con rdump y rrestore. Ambos programas
dependen de rcmd y ruserok para acceder a la unidad de cinta remota. Por
Página 17 de 31
consiguiente, el usuario que realiza el respaldo debe estar listado en el archivo
.rhosts de la computadora remota. Los argumentos para rdump y rrestore deben
ser adecuados para usarse en la computadora remota. Cuando realice un rdump
desde una unidad de cinta Exabyte conectada a una Sun llamada komodo, use:
# rdump 0dsbfu 54000 13000 126 komodo:/dev/nsa8 /dev/da0a 2>&1
Advertencia: existen implicaciones de seguridad al permitir autentificación
mediante .rhosts. Le recomendamos que evalúe la situación cuidadosamente.
También es posible usar dump y restore de una forma más segura a través de
ssh.
Ejemplo 1. Utilizando dump a través de ssh
#dump -0uan -f - /usr | gzip -2 | ssh -c blowfish \
[email protected] dd of=/misarchivosgrandes/dump-usr-l0.gz
Uso del método integrado de dump, configurando la variable de ambiente RSH:
Ejemplo 2. Uso de dump a través de ssh con RSH configurada
# RSH=/usr/bin/ssh /sbin/dump -0uan -f [email protected]:/
dev/sa0 /usr
tar
Tar también es de la época de la Version 6 de AT&T UNIX (alrededor de 1975).
Trabaja en cooperación con el sistema de archivos; escribe archivos y directorios
a cinta. No soporta el rango completo de opciones que ofrece cpio, pero no
requiere el inusual comando de pipeline que utiliza cpio.
Página 18 de 31
Usando un “pipe” y rsh para mandar los datos a una unidad de cinta remota.
# tar cf - . | rsh nombredemaquina dd of=dispositivo-de-cinta obs=20b
Si le preocupa la seguridad del proceso de hacer un respaldo a través de una red
debe usar ssh en lugar de rsh.
Respaldo incrementales con Tar. Aplicación práctica para un respaldo
diario:
ARCHIVO : backupfull.sh
#!/bin/sh
DATA=/backup/correo
DEST=$DATA/full.tgz
SOURCE=/home
LOG=/opt/backup/log
TODAY=`date “+%Y-%m-%d %a”`
# Borrar copia existente
/bin/rm -f $DEST
# Crear respaldo local
/bin/tar -chzf $DEST $SOURCE
# Borrar los respaldos incrementales
/bin/rm -f $DATA/i*
#### fin del archivo
ARCHIVO : backupincremental.sh
#!/bin/sh
DATA=/backup/correo
LASTFULL=$DATA/full.tgz
Página 19 de 31
SOURCE=/home
TODAY=`date “+%Y-%m-%d_%a”`
LASTDATE=`stat -c %y $LASTFULL`
DEST=$DATA/i$TODAY.tgz
# Borrar el incremental existente (si existe)
/bin/rm -f $DATA/i*
# Crear incremental
/bin/tar -chz –newer “$LASTDATE” -f $DEST $SOURCE
### fin del archivo
CONFIGURACION DEL CRON
00 22 * * 6 /root/backupfull.sh
00 22 * * * /root/backupincremental.sh
FUNCIONAMIENTO
1.- Archivo backupfull.sh , genera un comprimido de la carpeta /home/, y lo
guarda en /backup/correo, esto se ejecuta los sabados a las 11pm.
2.- Archivo backupincremental.sh, la primera vez genera un comprimido
omitiendo los archivos contenidos en full.tgz , cuando lo hace por segunda vez
primero elimina el incremental generado anteriormente y lo vuelve a crear
nuevamente, esto se realiza todos los dias a las 11pm.
cpio
Es el programa de intercambio de archivos de cinta para medios magnéticos.
cpio tiene opciones (entre muchas otras) para realizar intercambio de bytes,
escribir un número diferente de formatos de archivo y hacer “pipe” de datos
Página 20 de 31
hacia otros programas. Esta última opción hace de cpio una elección excelente
para medios de instalación. cpio no sabe cómo recorrer el árbol de directorios,
así que debe facilitarle una lista de directorios a través de stdin.
cpio no permite respaldos a través de la red. Puede usar un pipe y rsh para
mandar los datos a una unidad de cinta remota.
# for f in lista_directorios; do
find $f >> backup.list
done
# cpio -v -o --format=newc < backup.list | ssh usuario@máquina "cat >
dispositivo_de_respaldo"
Donde lista_directorios es la lista de directorios que desea respaldar,
usuario@máquina es la combinación usuario/nombre de equipo que realizará el
respaldo y dispositivo_de_respaldo es donde el respaldo se escribirá
efectivamente (por ejemplo /dev/nsa0).
pax
Es la respuesta IEEE/POSIX® a tar y cpio. A través de los años las diversas
versiones de tar y cpio se han vuelto ligeramente incompatibles, así que en lugar
de pelear por hacerlo completamente estándar, POSIX creó una nueva utilidad de
archivado. pax trata de leer y escribir muchos de los diversos formatos de cpio y
tar, además de nuevos formatos propios. Su conjunto de comandos se parece
más a cpio que a tar.
Amanda
Amanda (Advanced Maryland Network Disk Archiver) es un sistema de
respaldos cliente/servidor, en lugar de un solo programa.
Página 21 de 31
● Respaldará a una sola unidad de cinta cualquier cantidad de computadoras
que tengan clientes y servidores en red con esta solución. Un problema
común en sitios con gran cantidad de discos grandes es que la cantidad de
tiempo requerida para respaldar los datos directamente a cinta excede la
cantidad de tiempo disponible para la tarea. Amanda resuelve este
problema utilizando un “disco intermedio” para respaldar varios sistemas
de archivos al mismo tiempo.
● Crea “conjuntos de archivo”, esto es, un grupo de cintas usadas durante un
periodo de tiempo para crear respaldos completos de todos los sistemas de
archivos listados en el archivo de configuración de Amanda. El “conjunto
de archivo” también contiene respaldos incrementales nocturnos (o
diferenciales) de todos los sistemas de archivos. Para restaurar un sistema
de archivos dañado hace falta el respaldo completo más reciente y los
respaldos incrementales.
● El archivo de configuración ofrece un control exhaustivo de los respaldos y
del tráfico de red que Amanda genera.
● Usará cualquiera de los programas de respaldo mencionados arriba para
escribir los datos a cinta.
● Se puede instalar como paquete y como port. No forma parte del sistema
base.
No hacer nada
No hacer nada no es un programa, pero es la estrategia de respaldo más
extendida. No tiene coste. No hay un calendario de respaldos a seguir.
Simplemente hay que decir que no. Si algo le sucediera a sus datos sonría y
acostúmbrese a su nueva situación.
Página 22 de 31
Si su tiempo y sus datos valen poco o nada, entonces “no hacer nada” es el
programa de respaldo más adecuado para usted. Pero cuidado, Linux es una
herramienta muy poderosa y puede suceder que dentro de seis meses tenga un
montón de archivos que sean valiosos para usted.
“No hacer nada” es el método correcto de respaldo para /usr/obj y otros árboles
de directorios que pueden ser fácilmente recreados por su computadora.
Procedimiento de restauración de emergencia
Antes del desastre
Solamente existen cuatro pasos que debe realizar en preparación de cualquier
desastre que pudiera ocurrir.
Primero, imprima la etiqueta de disco de cada uno de sus discos (disklabel da0 |
lpr), su tabla de sistemas de archivos (/etc/fstab) y todos los mensajes de
arranque, dos copias de cada uno.
Segundo, asegúrese que los disquetes de rescate (boot.flp y fixit.flp) tienen todos
sus dispositivos. La manera más fácil de revisarlo es reiniciar su máquina con el
disquete en la unidad y revisar los mensajes de arranque. Si todos sus
dispositivos aparecen en la lista y funcionan, pase al tercer paso.
Si ha habido algún problema tiene que crear dos disquetes de arranque
personalizados, que deben tener un kernel que pueda montar todos sus discos y
acceder a su unidad de cinta. Estos discos deben contener: fdisk, disklabel,
newfs, mount y cualquier programa de respaldo que utilice. Estos programas
deben estar enlazados estáticamente. Si usa dump, el disquete debe contener
restore.
Tercero, use cintas de respaldo regularmente. Cualquier cambio que haga
Página 23 de 31
después de su último respaldo puede perderse irremediablemente. Proteja
contra escritura las cintas de respaldo.
Cuarto, pruebe los disquetes (ya sea boot.flp y fixit.flp o los dos discos
personalizados que creó en el segundo paso) y las cintas de respaldo. Documente
el procedimiento. Almacene estas notas con los discos de arranque, las
impresiones y las cintas de respaldo. Estará tan perturbado cuando restaure su
sistema que las notas pueden pueden evitar que destruya sus cintas de respaldo.
(¿Como puede occurrirle esta destrucción? en lugar de tar xvf /dev/sa0, puede
teclear accidentalmente tar cvf /dev/sa0 y sobreescribir su cinta).
Como medida adicional de seguridad haga discos de inicio y dos cintas de
respaldo cada vez. Almacene una de cada en una ubicación remota. Una
ubicación remota no es el sótano del mismo edificio. Muchas firmas alojadas en
el World Trade Center aprendieron esta lección de la manera más difícil. Esa
ubicación remota debe estar separada físicamente de sus computadoras y
unidades de disco por una distancia significativa.
Después del desastre
La pregunta clave es: ¿sobrevivió su hardware? Ha estado haciendo respaldos
regularmente, así que no hay necesidad de preocuparse por el software.
● Si el hardware ha sufrido daños los componentes deben reemplazarse
antes de intentar de usar su sistema.
● Si su hardware está bien revise sus discos de arranque. Si usa disquetes de
arranque personalizados arranque en modo monousuario (teclee -s en el
“prompt” de arranque boot:). Sáltese el siguiente párrafo.
● Si utiliza los discos boot.flp y fixit.flp, siga leyendo. Inserte el disco boot.flp
en la primera unidad de disquete y arranque la máquina. El menú de
Página 24 de 31
instalación original se desplegará en pantalla. Seleccione la opción Fixit--
Repair mode with CDROM or floppy. Inserte el disco fixit.flp cuando se le
pida. Tanto restore como los demás programas que necesitará están en
/mnt2/rescue (/mnt2/stand para versiones de FreeBSD anteriores a 5.2).
Recupere cada sistema de archivos por separado.
● Trate de montar (por ejemplo mount /dev/da0a /mnt) la partición raíz de su
primer disco. Si la etiqueta del disco ha sufrido daños use disklabel para
reparticionar y etiquetar el disco de forma que coincida con la etiqueta que
imprimió y guardó previamente.
○ Use newfs para crear de nuevo sus sistemas de archivos. Monte de
nuevo la partición raíz del disquete en modo lectura/escritura (mount -u
-o rw /mnt).
○ Ejecute su programa de respaldo y utilice las cintas de respaldo para
restaurar sus datos en este sistema de archivos (restore vrf /dev/sa0).
○ Desmonte el sistema de archivos (umount /mnt). Repita el proceso con
cada sistema de archivos que sufrió daños.
Una vez que su sistema esté en marcha respalde sus datos en cintas nuevas.
Cualquiera que haya sido la causa de la caída o pérdida de datos puede suceder
de nuevo. Una hora más que gaste ahora puede ahorrarle mucho sufrimiento
más adelante.
Bacula
Es un completo software de backup. El despliegue de este software alcanza sin
problemas los niveles de Netbackup. Deja atrás a productos como BackupExec,
al incorporar clientes/agentes para los sistemas operativos más importantes.
Página 25 de 31
Instalación de Bacula
#apt-get install bacula-common bacula-console bacula-director-common bacula-fd bacula-sd libpq3 mysql-server mtx mt-st
Esto instalará la mayoría de los componentes de bacula. Finalmente instalamos:#apt-get install bacula-director-mysql
¿Como trabaja bacula?
Bacula, principalmente es un sistema de backup modular. Esto quiere decir entre
otras cosas, que podremos tener separados todos los componentes importantes
de Bacula. Estos componentes, que corren en el server y clientes, son:
- Bacula-Director: cerebro de todos los componentes.
- Bacula-SD:Storage daemon: demonio encargado del almacenamiento (a
disco, a cinta, robots...).
- Bacula-FD:File daemon: parte cliente, encargado de la realización del backup
de los ficheros.
- Console: consola de gestión.
Bacula-Director
Este demonio controla todo el sistema de respaldo y los otros demonios
(principalmente Bacula-FD & Bacula-SD) para facilitar un respaldo exitoso.
El servidor corriendo el Bacula-Director es considerado el servidor de respaldo
(Backup server). Éste demonio dbería estar corriendo para que la solución
Bacula trabaje.
Página 26 de 31
El script del Bacula-Director es:
#/etc/init.d/Bacula-director
Bacula-SD
Bacula-SD es el demonio de almacenamiento de Bacula. Como lo dice su
nombre, toma el cuidado de todos los dispositivos de almacenamiento,
incluyendo pero no limitado a discos, cintas, CD/DVDs.
Éste demonio debe estar corriendo al menos al momento del respaldo. De aquí
que el servicio es configurado también para que arranque en el background
cuando el sistema se inicia.
El script de inicio es:
#/etc/init.d/Bacula-sd
Bacula-FD
Bacula-FD es el demonio en el cliente, El cual debería estar corriendo en cada
servidor que necesita ser respaldado. Ésto incluye al servidor de Backup en caso
que este tenga archivos que respaldar. Normalmente, esto último será el caso
porque es importante hacer respaldo del catálogo de Bacula, el cual será vital
cuando se requiera restaurar la data en caso de desastre.
Existe un cliente diponible para las estaciones Windows para respaldar los
Página 27 de 31
ervidores Windows también.
El script de inicio es :
#/etc/init.d/Bacula-fd
Bconsole
Esta es la consola para hacer los cambios y actualizacioes después que ha sido
implementado Bacula. No es exactamente un deminio pero es un utilitario que
inicia y corre cuando un usuario se logea por consola. No requiere script de
inicio.
Bsmtp
Bacula corre éste utilitario cuando un mensaje ó alerta es enviado por el demonio Bacula-Director.
BootStrapRecord
The BootStrapRecord es el registro más crítico que tiene que ser respaldado en
un servidor diferente ó CD, pero tiene que ser en medio diferente a la cinta de
respaldo. BootStrapRecord es requerido para la reconstrucción en el caso de un
desastre del mismo servidor backup.
Principales archivos de configuración.
Todos los archivos de configuración requeridos están en el directorio
/etc/bacula. Los principales archivos son:
bacula-dir.conf
Página 28 de 31
bacula-fd.conf
bacula-sd.conf
bconsole.conf
Utilice su editor favorito para ver los contenidos de cada uno de ellos y sus
parámetros principales de configuración, los cuales se explicarán al momento de
la configuración en el laboratorio de prácticas.
Probando el drive de la Cinta con Bacula.
Algunas cintas no son estandars. Ellas trabajan con el software propietario y
presentan fallas interminentes cuando se usan con otro software.
Afortunadamente, Bacula viene con un utilitario para probar el drive de las
cintas.
Para probarlo ejecute:
#btape -c /etc/bacula/bacula-sd.conf /dev/nst0
¿Como encontrar el drive de tu cinta en Bacula?
#mt status
¿Como chequear el estatus del demonio de Bacula?
# ps auwx | grep bacula
Página 29 de 31
Arrancando la consola de Bacula.
La consola de Bacula es la principal interfaz con el demonio Bacula-Director.
#bconsole
Ejercicios.
Construir un script que automatice las copias diarias de un sistema.
Solución:
Este script se basa en un ejemplo realizado por por [email protected].
La idea es tener una copia semanal completa, una mensual también
completa y luego un archivo por cada día de la semana que contendrá los
cambios desde el domingo hasta ese día.
Esta política de copias es buena para casi cualquier sistema de usuarios
o servidores de Internet.
#!/bin/bash #script de copia completa e incremental #
COMPUTER=pc1pii300
#Directorios de los que se hace la copia DIRECTORIOS="/" BACKUPDIR=/backups
#Directorio que contiene el archivo de referencia para las copias incrementales TIMEDIR=/backups/last-full
Página 30 de 31
#escribir en este archivo el path completo de directorios/archivos #que no se copiaran EXCLUDEFILE=/backups/exclude
TAR=/bin/tar
#no modificar esto
DOW=`date +%w` #dia de la semana (0 domingo, 1 lunes...) DOWL=`date +%a` #dia de la semana en locales (Lun/Mon, Mar/Tue, /Wed...) DOM=`date +%d` #dia del mes (01..31) DM=`date +%d%b` #dia y mes (mes en locales, e.g ES ene, US jan)
# backup entero mensual if [ $DOM = "01" ]; then $TAR -X $EXCLUDEFILE -jcf $BACKUPDIR/$COMPUTER-$DM.tar.bz2
$DIRECTORIOS chmod 770 $BACKUPDIR/$COMPUTER-$DM.tar.bz2 fi
# Backup total semanal if [ $DOW = "0" ]; then NOW=`date +%d-%b` echo $NOW > $TIMEDIR/$COMPUTER-full-date $TAR -X $EXCLUDEFILE -jcf $BACKUPDIR/$COMPUTER-$DOWL.tar.bz2
$DIRECTORIOS chmod 770 $BACKUPDIR/$COMPUTER-$DOWL.tar.bz2 # Backup incremental que sobreescribe el de la semana pasada else NEWER="--newer `cat $TIMEDIR/$COMPUTER-full-date`" $TAR -X $EXCLUDEFILE $NEWER -jcf $BACKUPDIR/$COMPUTER-$DOWL.tar.bz2 $DIRECTORIOS chmod 770 $BACKUPDIR/$COMPUTER-$DOWL.tar.bz2 fi
Página 31 de 31
