AO DE LA PROMOCIN DE LA INDUSTRIA RESPONSABLE Y

DEL COMPROMISO CLIMATICO

UNIVERSIDAD NACIONAL DE SAN MARTIN

FACULTAD DE INGENIERIA DE SISTEMAS E INFORMATICA

ADMINISTRACION DE BASE DE DATOS

DISPONIBILIDAD
EN
FIREBIRD

Integrantes: Cdigo
BECERRA PEZO, Milton Kevin 087143
CALDERON BARTUREN, Yoni Leodan 067154
CANCINO SEVILLANO, Guillermo Ricardo 107138
PADILLA DIAZ, Guillermo 117150
RAFAEL VILLALOBOS, Rosel 087160
DEFINICION DE DISPONIBILIDAD
La disponibilidad es el grado en que una aplicacin o servicio est disponible
cundo y cmo los usuarios esperan. La disponibilidad se mide por la
percepcin de una aplicacin del usuario final. Los usuarios finales
experimentan frustracin cuando sus datos no estn disponibles, y ellos no
entienden o son capaces de diferenciar los complejos componentes de una
solucin global. Fiabilidad, valorizacin, continuas operaciones y deteccin de
errores son caractersticas de una solucin de alta disponibilidad:

Fiabilidad: Los componentes hardware fiables de una solucin de HA, el

software fiable, incluida la base de datos, servidores web y aplicaciones, es
la parte crtica de una implementacin de una solucin de alta
disponibilidad.

Recuperacin: Puede haber muchas opciones para recuperarse de un

fracaso si ocurre alguno. Es importante determinar qu tipo de fallos pueden
ocurrir en su entorno de alta disponibilidad y la forma de recuperarse de
estos fallos en el tiempo que satisface las necesidades comerciales. Por
ejemplo, si una tabla importante es eliminada de la base de datos, qu
medidas adoptaras para recuperarla? Su arquitectura ofrece la capacidad
de recuperarse en el tiempo especificado en un acuerdo de nivel de servicio
(SLA)?

Deteccin de errores: Si un componente en su arquitectura falla,

entonces la rpida deteccin, de dicho componente es esencial en la
recuperacin de un posible fracaso inesperado. Si bien es posible que
pueda recuperarse rpidamente de un corte de luz, si se lleva a otros 90
minutos para descubrir el problema, entonces usted no puede satisfacer
su SLA. La monitorizacin del estado del entorno de trabajo requiere un
software fiable, para ver de forma rpida y notificar al administrador de
bases de datos (DBA ) un problema.

Continuas operaciones: El continuo acceso a sus datos es esencial,

por muy pequeo o inexistente que sea el tiempo de cada del sistema, para
llevar a cabo las tareas de mantenimiento. Actividades como mover una
tabla de un lado a otro dentro de la base de datos, o incluso aadir
nuevas CPUs a su hardware debe ser transparente para el usuario final en
una arquitectura HA.

IMPORTANCIA DE LA DISPONIBILIDAD
La importancia de la alta disponibilidad vara dependiendo de las aplicaciones.
Sin embargo, la necesidad de aumentar los niveles de disponibilidad contina
acelerndose tanto como las empresas redisean sus soluciones para
conseguir una ventaja ms competitiva.
La mayora de las veces estas nuevas soluciones se basan en el acceso
inmediato a datos crticos para el negocio. Cuando los datos no estn
disponibles, la aplicacin puede dejar de funcionar. El tiempo de inactividad o
cada del sistema, puede conducir a prdida de productividad, prdida de
ingresos, daando las relaciones con los clientes, la mala publicidad, y pleitos.
Si una aplicacin con tarea crtica no est disponible, entonces la empresa se
encuentra en peligro.
No siempre es fcil colocar un coste directo sobre el tiempo de inactividad. El
enfado con los clientes, los empleados que han intervenido y la mala publicidad
son costosos, pero no directamente se pueden medir en dinero. Por otro lado,
la prdida de ingresos y las sanciones legales ocurridas por no alcanzar el SLA
garantizado no son fcilmente cuantificadas. El costo de la inactividad puede
crecer rpidamente en las industrias que dependen de soluciones que prestan
servicio en todo momento.
Otros factores a considerar en el coste de la inactividad son los niveles
mximos tolerables en cuanto a la duracin de un solo corte de luz ocurrido, y
la frecuencia mxima permisible de incidentes. Si la interrupcin en cuestin
dura menos de 30 segundos, entonces puede causar muy poco dao y resulta
casi imperceptible para los usuarios finales. Como la duracin de la interrupcin
crezca, crece el malestar, pasando de un pequeo problema a un gran
problema, y posiblemente en una accin legal. Al disear una solucin, es
importante tener en cuenta estas cuestiones y determinar el verdadero coste de
la inactividad. Una organizacin debe gastar una cantidad razonable de dinero
para construir soluciones que sean altamente disponibles, pero este coste est
justificado.
Existen soluciones de alta disponibilidad a disposicin de cada cliente
independientemente de su tamao. Tanto pequeos grupos de trabajo como las
empresas mundiales son capaces de extender por todo el mundo el alcance de
sus aplicaciones crticas de negocio. Con la alta disponibilidad y Internet se
consigue que las aplicaciones y sus datos estn ahora accesibles y fiables en
todas partes, en cualquier momento.
Uno de los retos en el diseo de una solucin de HA es examinar y abordar
todas las posibles causas de una posible inactividad. Es importante considerar
tanto las causas de tiempo de inactividad planificado y no planificado. El tiempo
de inactividad no planificado engloba los fallos del ordenador y los fallos de
datos. Los fallos de datos pueden ser causados por fallos en el
almacenamiento, errores humanos y fallos del sitio. Los tiempos de inactividad
planificados incluyen cambios en el sistema y los cambios de datos. Planear la
inactividad, en ocasiones puede ser muy perjudicial en las operaciones,
especialmente en las empresas mundiales que soportan usuarios en mltiples
zonas horarias.

ALTA DISPONIBILIDAD
Alta disponibilidad (High availability) es un protocolo de diseo del sistema y su
implementacin asociada que asegura un cierto grado absoluto de continuidad
operacional durante un perodo de medicin dado. Disponibilidad se refiere a la
habilidad de la comunidad de usuarios para acceder al sistema, someter
nuevos trabajos, actualizar o alterar trabajos existentes o recoger los resultados
de trabajos previos. Si un usuario no puede acceder al sistema se dice que
est no disponible. El trmino tiempo de inactividad (downtime) es usado para
definir cundo el sistema no est disponible.
Estrategias
CLUSTERING
Un cluster de alta disponibilidad es un conjunto de dos o ms mquinas que se
caracterizan por mantener una serie de servicios compartidos y por estar
constantemente monitorizndose entre s. Podemos dividirlo en dos clases:
1. Alta disponibilidad de infraestructura: Si se produce un fallo
de hardware en alguna de las mquinas del cluster, el software de alta
disponibilidad es capaz de arrancar automticamente los servicios en
cualquiera de las otras mquinas del cluster (failover). Y cuando la
mquina que ha fallado se recupera, los servicios son nuevamente
migrados a la mquina original (failback). Esta capacidad de
recuperacin automtica de servicios nos garantiza la alta disponibilidad
de los servicios ofrecidos por el cluster, minimizando as la percepcin
del fallo por parte de los usuarios.

2. Alta disponibilidad de aplicacin: Si se produce un fallo del hardware o

de las aplicaciones de alguna de las mquinas del cluster, el software de
alta disponibilidad es capaz de arrancar automticamente los servicios
que han fallado en cualquiera de las otras mquinas del cluster. Y
cuando la mquina que ha fallado se recupera, los servicios son
nuevamente migrados a la mquina original. Esta capacidad de
recuperacin automtica de servicios nos garantiza la integridad de
la informacin, ya que no hay prdida de datos, y adems evita
molestias a los usuarios, que no tienen por qu notar que se ha
producido un problema.
No hay que confundir un cluster de alta disponibilidad con un cluster de alto
rendimiento. El segundo es una configuracin de equipos diseado para
proporcionar capacidades de clculo mucho mayores que la que proporcionan
los equipos individuales (vanse por ejemplo los sistemas de tipo Cluster
Beowulf), mientras que el primer tipo de cluster est diseado para garantizar
el funcionamiento ininterrumpido de ciertas aplicaciones.
Clculo de la Disponibilidad
En un sistema real, si falla uno de los componentes, es reparado o sustituido
por un nuevo componente. Si este nuevo componente falla, es sustituido por
otro, y as sucesivamente. El componente fijo se considera en el mismo estado
que un nuevo componente. Durante su vida til, uno de los componentes
pueden ser considerado en uno de estos estados: Funcionando o en
Reparacin. El estado funcionando indica que el componente est operacional
y el en reparacin significa que ha fallado y todava no ha sido sustituido por un
nuevo componente.
En caso de defectos, el sistema va de funcionando en modo reparacin, y
cuando se hace la sustitucin volver al estado funcionando. Por lo tanto,
podemos decir que el sistema tiene durante su vida, una media de tiempo para
presentar fallas (MTTF) y un tiempo medio de reparacin (MTTR). Su tiempo
de la vida es una sucesin de MTTFs y MTTRs, a medida que este va fallando
y siendo reparado. El tiempo de vida til del sistema es la suma de MTTFs en
ciclos MTTF + MTTR ya vividos.
En forma simplificada, se dice que la disponibilidad de un sistema es la relacin
entre la duracin de la vida til de este sistema y de su tiempo total de vida.
Esto puede ser representado por la frmula de abajo:
Disponibilidad = MTTF / (MTTF + MTTR)
En la evaluacin de una solucin de Alta Disponibilidad, es importante tener en
cuenta si en la medicin de MTTF son vistos como fallas las posibles paradas
planificadas.
REPLICACION
La replicacin es un conjunto de tecnologas destinadas a la copia y
distribucin de datos y objetos de base de datos desde una base de
datos a otra, para luego sincronizar ambas bases de datos y mantener
su coherencia. La replicacin permite distribuir datos entre diferentes
ubicaciones y entre usuarios remotos o mviles mediante redes locales y
de rea extensa, conexiones de acceso telefnico, conexiones
inalmbricas e Internet.
La replicacin transaccional se usa normalmente en escenarios servidor
a servidor que requieren un alto rendimiento, como por ejemplo, la
mejora de la escalabilidad y la disponibilidad, el almacenamiento de
datos y la creacin de informes, la integracin de datos procedentes de
varios sitios, la integracin de datos heterogneos, y la descarga del
procesamiento por lotes. La replicacin de mezcla se ha diseado
principalmente para las aplicaciones mviles o de servidores distribuidos
que pueden encontrarse con conflictos de datos. Los escenarios ms
frecuentes son: el intercambio de datos con usuarios mviles, las
aplicaciones de punto de venta (POS) a consumidores, y la integracin
de datos de varios sitios. La replicacin de instantneas se usa para
proporcionar el conjunto de datos inicial para la replicacin transaccional
y de mezcla; tambin se puede usar cuando est indicada una
actualizacin completa de los datos.

MIRROR O ESPEJO
Un espejo lgico es un modo backup sofisticado, destinado especialmente para
bases de datos crticas o de carga alta.

El uso de un espejo lgico consiste en operar una base de datos en una

mquina y mantener en una segunda mquina una copia de esta base que se
actualiza peridicamente. Ambas mquinas se comunican por la red con la
mquina en funcionamiento transmitiendo regularmente a la mquina de espejo
los cambios realizados en la base de datos a travs del intermediario del
archivo de historial.

De esta manera, cuando hay un incidente que afecta a la base de datos

operacional, la base de datos espejo se puede utilizar para conseguir
rpidamente volver a trabajar sin prdida de datos. Por otra parte, la base de
datos operacionales nunca est "bloqueada" por las operaciones de backup.
Elegir el backup por espejo lgico.
El uso de un espejo lgico corresponde a necesidades concretas. La estrategia
estndar basada en copias de seguridad peridicas y el uso de un archivo de
historial constituye en la mayora de los casos una solucin simple, fiable y
econmica. Se hace backup de la base regularmente (cada 24 horas en
general). Durante la copia de seguridad, la base sigue siendo accesible en
modo de slo lectura. Este perodo de indisponibilidad parcial es muy corto, e
incluso en el caso de bases de datos grandes (mayores de 2 GB), no dura ms
de 5 minutos. Esta operacin puede incluso programarse para tener lugar fuera
de los perodos normales de uso de la base.
Sin embargo, para ciertos tipos de organizaciones, tales como hospitales, por
ejemplo, las bases de datos crticas deben ser totalmente operacionales las 24
horas del da. La base de datos no puede estar en modo de slo lectura,
aunque sea por un perodo muy corto de tiempo. En este caso, la creacin de
un espejo lgico es una buena solucin.
Nota: la base espejo slo refleja los cambios realizados a los datos. Este modo
de backup no es adecuado para bases en proceso de desarrollo, donde las
frecuentes modificaciones estructurales har que el espejo rpidamente sea
obsoleto o que requieren mltiples actualizaciones de la estructura de la base
espejo.
Un sistema de comunicacin y de gestin de errores entre el servidor principal
y el servidor espejo.
ATENCIN: un sistema de backup por espejo lgico no es compatible con los
backup "estndar" en una base en uso ya que el uso simultneo de estos dos
modos de backup dar lugar a la desincronizacin de la bases operacional y
espejo. Por consiguiente, debe estar seguro de que ningn backup, automtico
o manual, se efecte en la base operacional. Por otra parte, es posible hacer
backups de la base espejo (ver el siguiente prrafo).
Backup de la base espejo
Todos los medios convencionales se pueden utilizar para realizar backups en la
mquina espejo: backup manual va el comando de men Archivo, backup
peridico definido en las Preferencias/Propiedades de la base o backup
programado utilizando los comandos del lenguaje.
Nota: sin embargo, no es posible desactivar el archivo de historial actual en el
equipo espejo y debe asegurarse de que la opcin Utilizar el archivo de
historial est deseleccionada en el equipo espejo.
Para evitar riesgos de desincronizacin con la mquina operacional, 4D
bloquea automticamente la mquina espejo cuando se est llevando a cabo
una de las dos operaciones bsicas: la integracin del archivo de historial de la
mquina operacional y el backup de la base espejo.
Durante la integracin del archivo de historial, no es posible llevar a cabo un
backup. Si se utiliza el comando BACKUP, se genera el error 1417 (ver la
seccin Errores de gestin de backup).
Cuando un backup est en marcha, todos los procesos se congelan y no es
posible poner en marcha la integracin de un archivo de historial.

TECNICAS Y RECUPERACION DE BASE DE DATOS

RECUPERACION.
Recuperarse al fallo de una transaccin significa que la base de datos se
restaura al estado coherente ms reciente, inmediatamente anterior al
momento del fallo para esto el sistema guarda las informacin sobre los
cambios de las transacciones esta informacin se guarda en el registro del
sistema.
1. Si hay un fallo como la cada del disco, el sistema restaura una copia se
seguridad del registro, hasta el momento del fallo.
2. Cuando el dao se vuelve inconsistente, se pueden rehacer algunas
operaciones para restaurar a un estado consistente. En este caso no se
necesita una copia archivada.
Existen diversos mtodos para la restauracin de una base de datos corrupta a
un estado previo libre de daos. El tipo de tcnica de recuperacin usado en
cada situacin determinada depende de varios factores, incluyendo los
siguientes:

La extensin del dao sufrido por la base de datos. Por ejemplo, si se

encuentra que ha sido un nico registro el que ha sufrido daos, la tcnica de
recuperacin es trivial, en comparacin con el procedimiento de restauracin
necesario despus de un choque de una cabeza.

El nivel de actividad de la base de datos. Las tcnicas de recuperacin son

fciles de implementar en bases de datos que se modifican con escasa
frecuencia. Por el contrario, resulta mucho ms difcil y caro el diseo de
tcnicas de recuperacin para bases de datos que se estn actualizando
continuamente. En este ltimo caso, suele tratarse tambin de bases de datos
de gran importancia para sus usuarios, por lo que es de vital importancia que la
recuperacin sea rpida.
La naturaleza de la informacin de la base de datos. Para algunos tipos de
datos, la prdida de una pequea cantidad de informacin puede no resultar
particularmente crtica. En otras situaciones, tales como bases de datos
financieras, no es aceptable ninguna prdida de datos, independientemente de
su cuanta. Los dos tipos de circunstancias requieren muy diferentes
aproximaciones en lo que se refiere a fiabilidad y recuperacin.

Copias de seguridad de la base de datos

Para poder efectuar cualquier tipo de restauracin de una base de datos, es

necesaria la realizacin de copias de seguridad (backups) de la base de datos
de forma peridica. Este proceso consiste en la escritura de una copia exacta
de la base de datos en un dispositivo magntico separado del que contiene a la
propia base de datos. En los sistemas ms grandes, este dispositivo suele ser
una cinta magntica. En los sistemas basados en microordenadores, puede
tratarse de un cartucho de cinta de casete, o de uno o ms discos flexibles.
Habitualmente, mientras se est generando una copia de seguridad es preciso
detener todas las dems actividades de la base de datos.

A menudo se realiza ms de una nica copia, que luego se almacenan en un

lugar lejos del ordenador, y alejadas entre s, con el fin de que si algn tipo de
suceso catastrfico produjese la destruccin del ordenador, al menos una de
las copias en cinta no resultase daada por el mismo suceso. Cuando se trata
de bases de datos crticas, como las que guardan informacin bancaria, suele
guardarse al menos una copia en un lugar alejado bastantes kilmetros de la
instalacin del ordenador. Adems, no es raro que se mantengan varias
generaciones de copias, para aadir un nivel de seguridad adicional.

Un mtodo sencillo de recuperacin

El mtodo ms simple de recuperacin de una base de datos es el expuesto a

continuacin. Peridicamente, quiz una vez cada da, se realiza una copia de
seguridad de la base de datos. Comenzando a partir del momento en el que se
hace cada copia, se lleva manualmente una lista fsica, o diario (log), de todos
los cambios subsiguientes que se efectan en la base de datos. Si la base de
datos es daada o destruida, para recuperarla es preciso seguir la secuencia
de pasos siguiente:
- Reparar el problema de hardware o software que caus la cada del sistema.
- Restaurar la base de datos a partir de la copia de seguridad ms reciente.
Esto no restaura la base de datos a su estado en el instante en el que tuvo
lugar el dao.
- Volver a introducir manualmente en la base de datos los cambios realizados
desde que se hizo la copia, usando la lista fsica.
Diarios de transacciones y restauracin/reejecucin
Una extensin de la tcnica anterior consiste en el mantenimiento automtico
de un fichero de ordenador, que contenga una lista de los cambios hechos en
la base de datos entre dos copias de seguridad consecutivas. Esta lista se
conoce como diario de transacciones, y se mantiene siempre en un dispositivo
fsico diferente del que almacena a la propia base de datos. Habitualmente se
utiliza para este propsito una unidad de cinta magntica, o una unidad de
disco diferente. La razn para usar un dispositivo separado es simplemente
que si la base de datos resulta daada, la causa de dicho dao no tiene por
qu afectar a los datos almacenados en un dispositivo fsico diferente.
La forma de utilizar un diario de transacciones como ayuda para la restauracin
es idntica a la que ya se ha descrito, excepto en la ltima etapa. En este caso,
la restauracin de las transacciones anotadas en el diario las realiza una
utilidad del SGBD, que devuelve la base de datos al estado inmediatamente
anterior al momento del fallo. Este proceso se conoce habitualmente como
restauracin/reejecucin.

La clave para el uso con xito de un diario de transacciones radica en la

capacidad del SGBD para reconocer el comienzo y el final de cada transaccin.
Para cada transaccin de la base de datos, el diario contiene marcas de
"comienzo de transaccin" y "final de transaccin", adems de una grabacin
de los cambios individuales realizados en la base de datos para dicha
transaccin. La marca de "final de transaccin" se graba en el diario slo
despus de la conclusin con xito de la transaccin. As, si una cada del
sistema interrumpe el procesamiento de una transaccin, no aparecer ninguna
marca de "final de transaccin" en el diario. Cuando se realice un proceso de
restauracin/reejecucin, slo se restaurarn a partir del diario las
transacciones completadas, y se generar un informe impreso, que indicar
qu transacciones no se han completado y, por tanto, no han sido introducidas
en la base de datos.
Para bases de datos extremadamente activas, la tcnica de
restauracin/reejecucin puede resultar inadecuada, ya que el reprocesamiento
del diario puede llevar varias horas, durante las cuales la base de datos no
puede ser usada con normalidad. Si una base de datos es muy activa, esta no
disponibilidad puede revelarse intolerable, y ser preciso emplear otras
tcnicas de restauracin.
Recuperacin por retroceso
La recuperacin por retroceso resulta til en situaciones en las que el
procesamiento de la base de datos se ve interrumpido, pero la base de datos
en s no resulta daada de forma alguna. Un ejemplo de esto podra ser algn
tipo de fallo que produzca una terminacin anormal de la ejecucin del SGBD.
Las transacciones en marcha podran ser abortadas antes de su finalizacin, y
los registros asociados a las mismas quedaran en estados desconocidos,
aunque el resto de la base de datos no se vera afectada.
La tcnica de recuperacin por retroceso requiere que el diario de
transacciones contenga imgenes iniciales de cada registro de la base de
datos que haya sufrido modificaciones desde la ltima copia de seguridad. Una
imagen inicial es una copia de un registro tal como se encontraba
inmediatamente antes de ser modificado como parte de una transaccin, es
decir, justo antes del inicio de dicha transaccin.
El procesado de recuperacin por retroceso conlleva que despus de que se
haya colocado nuevamente en funcionamiento el SGBD, con la base de datos
correcta, tal como estaba cuando tuvo lugar la interrupcin, se pase a procesar
el diario de transacciones. Para cada transaccin incompleta anotada en el
diario se reemplaza la versin actual del registro de la base de datos por la
imagen inicial correspondiente. As, cada registro de la base de datos que ha
sufrido modificaciones durante una transaccin no completada es devuelto a su
estado inicial, antes del comienzo de la transaccin. El resultado de este
proceso es la eliminacin de la base de datos de todas las huellas de
transacciones incompletas, es decir, las que estaban en marcha cuando tuvo
lugar la cada.
Para que la recuperacin por retroceso pueda funcionar, el diario de
transacciones debe contener marcas de "comienzo de transaccin" y de "final
de transaccin" para cada transaccin. Cuando se realiza un proceso de
recuperacin, las transacciones incompletas se detectan por la ausencia de
una marca de "final de transaccin".
La cantidad de esfuerzo necesaria para efectuar una recuperacin por
retroceso puede ser mucho menor que la que se necesita para una
recuperacin por restauracin/reejecucin. Por ejemplo, supongamos que se
han grabado 1000 transacciones en un diario entre el momento en que se hizo
la ltima copia de seguridad y el instante del fallo (un fallo que no dae a la
base de datos). Supongamos asimismo que en el instante del fallo se
encuentran en marcha 5 transacciones. Con la tcnica de
restauracin/reejecucin, la base de datos debe ser restaurada a partir de la
ltima copia, por lo que habr que procesar 995 transacciones. Por su parte,
una recuperacin por retroceso parte de la base de datos tal como se
encuentra, limitndose a deshacer los efectos de las 5 transacciones
incompletas.

Recuperacin por adelanto

El adelanto es otro tipo de mecanismo de recuperacin, que se usa a menudo
cuando una base de datos ha sido daada y debe, por tanto, ser restaurada a
partir de una copia de seguridad. Se parece a la tcnica del retroceso, y
comparte con sta la ventaja de que es mucho ms rpida que el mtodo de
restauracin/reejecucin. Requiere que el diario de transacciones contenga una
imagen final de cada registro de la base de datos que ha sido modificado desde
la ltima copia. Una imagen final es una copia de un registro, inmediatamente
despus de haber sido modificado como parte de una transaccin, es decir, en
el estado en que se encuentra al finalizar dicha transaccin.
Etapas:
1. Despus de un fallo que produce un dao en la base de datos, se utiliza la
ltima copia de seguridad para restaurarla.
2. Se procesa el diario, a partir del punto en que se efectu la ltima copia de
seguridad. Para cada transaccin completada anotada en el diario, se sustituye
la versin actual del registro de la base de datos por la imagen final
correspondiente.
Esta tcnica es considerablemente ms rpida que la de
restauracin/reejecucin, ya que la sustitucin de un registro por su imagen
final lleva mucho menos tiempo que el proceso de recreacin de la base de
datos completa a partir de la copia de seguridad.
Existen variaciones del mtodo de adelanto bsico, diseadas para mejorar
an ms la velocidad de la recuperacin de la base de datos. Por ejemplo, el
conjunto completo de imgenes finales puede ordenarse primero por nmero
de registro. De esta forma, despus slo hace falta escribir en la base de datos
la ltima imagen final de cada registro. Para los registros con varias
modificaciones anotadas en el diario, esto puede suponer un considerable
ahorro en tiempo de procesamiento.

6.4. Demostracin de los Herramientas de Disponibilidad en el Gestor (Haga un

ejemplo de cmo sacar una copia de seguridad y como restaurarlo, adems de
ciertas opciones de configuracin de copias de seguridad propias de cada
gestor)