INSTITUTO TECNOLÓGICO

SUPERIOR DEL SUR DEL ESTADO

DE YUCATÁN.

ADMÓN. DE BASE DE DATOS.

Nombre de la alumna:

Elvia Perlita Ramírez Cel.

PROFESOR:

I.S.C David Avilés.

SEXTO SEMESTRE GRUPO “A”

INGENIERÍA EN SISTEMAS COMPUTACIONALES.

Investigación: “RESPALDO Y RECUPERACIÓN DE BD”

Fecha de entrega: 31/03/14

RESPALDO Y RECUPERACIÓN EN SQL SERVER

Diseñar un plan de respaldo y recuperación involucra decidir qué bases de datos

respaldar, con qué frecuencia, donde almacenar los respaldos, qué tan

frecuentemente sobre-escribirlos y qué tan rápido necesitas recuperar la base de

datos. Sin embargo, para diseñar una estrategia de respaldo, primero hay que

pensar en el proceso de recuperación y en la pérdida de datos que el negocio

puede soportar, ya que de ese factor dependerá el tipo de respaldos a realizar, la

frecuencia, y el modelo de recuperación (recovery model) a usar para configurar la

base de datos.

Las bases de datos en SQL Server soportan tres modelos de recuperación: Full,

Bulk-Logged y Simple y cada uno de estos modelos tiene una influencia muy

particular sobre el tamaño del Transaction Log y el grado de pérdida de datos en

caso de falla.

Bajo el modelo FULL, SQL Server registra todas las transacciones realizadas

dentro de la bitácora de transacciones (transaction log), incluyendo inserciones

masivas (bulk), construcciones de índices, y las operaciones regulares. A

diferencia del modelo simple, la bitácora de transacciones crece progresivamente

hasta que la respaldas explícitamente. Este es el modelo que ofrece la mayor

flexibilidad en la recuperación de los datos, através de restauraciones a cualquier

punto en el tiempo.

Bajo el modelo SIMPLE las transacciones también se registran en la bitácora de

transacciones aunque a menor detalle y las transacciones no activas se descartan

de la bitácora de forma regular en cada checkpoint, en vez de en cada respaldo.

Es decir, la bitácora no crece progresivamente si no que se trunca en cada

checkpoint, a menos que existan transacciones activas. De ser así, entonces la

bitácora crece hasta que las transacciones activas terminen y la bitácora pueda

ser truncada sin problema.

En cuanto a los tipos de respaldo se refiere, SQL Server ofrece varias opciones:

Completo, Diferencial, Filegroup, Bitácora de Transacciones y Copy-Only.

Completo

El respaldo completo no necesita mucha explicación ya que involucra respaldar

todas y cada una las páginas que forman parte de la base de datos y aquellas

asociadas con la bitácora de transacciones que se generaron mientras el respaldo

estuvo activo.  La desventaja de los respaldos completos es que si la base de

datos es muy grande, entonces pueden requerir bastante tiempo y espacio.

Diferencial

El respaldo diferencial consiste en respaldar todas las páginas que han sufrido

cambios desde el último respaldo completo y para poder que funcione tienes que

haber tomado un respaldo completo anteriormente.  Dado que se respaldan

solamente las páginas que han cambiado desde el último respaldo completo, los

respaldos diferenciales generalmente son más rápidos que los completos.

Nota: La base de datos Maestra no puede respaldarse diferencialmente.

Filegroup

El respaldo tipo filegroup consiste en respaldar todos los archivos que pertenecen

a un filegroup en particular. Es importante señalar que aunque es

posible respaldar un archivo en específico, dicha granularidad no es recomendable

ya que el proceso de recuperación requiere que todos los archivos pertenecientes 

al filegroup siendo recuperado se encuentren en el mismo punto o estado. Este

tipo de respaldos se usan en combinación con los respaldos de la bitácora de

transacciones para recuperar secciones de la base de datos.

Bitácora de transacciones

El respaldo de la Bitácora de Transacciones o Transaction Log solamente puede

hacerse cuando el modelo de recuperación de la base de datos es FULL o Bulk-

logged y se realiza principalmente con el fin de reducir la cantidad de datos que

pudieran perderse en caso de una falla y reducir el tamaño del archivo que

almacena la bitácora. Cuando realizas un respaldo de la bitácora, SQL Server

respalda todas las páginas nuevas desde el último respaldo completo, diferencial,

o desde el último respaldo de la bitácora. Esto significa que cada respaldo de la

Bitácora de Transacciones captura todas las transacciones asociadas con un

punto en el tiempo.

Detach/Attach

Esta funcionalidad no es necesariamente una estrategia de respaldo pero te

permite desconectar o desprender una base de datos de un servidor y conectarla

o prenderla en otro. Una vez que ha desprendido la base de datos, puedes copiar

los archivos que la comprenden a otro servidor y luego activarla ahí.

Los eventos que pueden afectar negativamente tus bases de datos y para los

cuales tienes que prepararte son: Borrar información accidentalmente, corrupción

por fallas de hardware y desastres naturales. Las técnicas o procedimientos que

seguirás para restaurar una base de datos dependerán de los tipos de respaldos

que formen parte de la estrategia de respaldo que diseñaste y pusiste en

operación.

Cuando restauras una base de datos de usuario sobre una Master Database

nueva, la Master Database se actualiza usando la información contenida en la

base de datos de usuario que estás restaurando.

Si la Master Database falla y no tienes respaldo para componerla entonces tienes

que correr el programa de setup.exe para tratar de repararla o hacer una Master

nueva. Recuerda que la Master Database contiene información sobre la estructura

de la base de datos, parámetros de configuración del servidor, cuentas de usuario,

dispositivos de respaldo, etc. y por lo tanto es importante respaldarla cada vez que

se hagan cambios en estas áreas. Una recomendación común es respaldar la

base de datos Master un día sí y un día no y mantener varias respaldos a la mano.

SQL Server te permite operar casi normalmente durante los respaldos a excepción

de que no puedes agregar o quitar bases de datos ni tampoco reducirlas de

tamaño (shrink).  Esta funcionalidad es posible gracias a que SQL Server respalda

la sección del Transaction Log que se usó mientras la operación de respaldo

estuvo en efecto o activa, lo cual permite que SQL Server sea capaz de deshacer

las transacciones que se quedaron a medias o incompletas durante el respaldo. 

Sin embargo, si bien es cierto que parte del Transaction Log se incluye como parte

de la operación de respaldo, dicha copia no es suficiente para considerar que el

transaction log ha sido respaldado. Dicho de otra forma, si tu base de datos ha

sido configurada para correr bajo el modelo de recuperación llamado “FULL” o

“BULK-LOGGED”, entonces tienes  que respaldar el transaction log por separado.

Nota: Para poder respaldar el transaction log, tienes que haber hecho un respaldo

completo alguna vez, de lo contrario el respaldo del transaction log arrojará error.

Los parámetros o información mínima que necesitas para respaldar una base de

datos son el nombre de la base de datos y el dispositivo de respaldo donde vas a

almacenar los datos, ya sea el nombre de un archivo o un <backup device>. Por lo

general, los respaldos residen en un solo archivo pero también tienes la opción de

especificar varios dispositivos (hasta un máximo de 64).

En SQL Server tienes la opción de hacer los respaldos usando la interface gráfica

SQL Server Management Studio (SSMS) o através de comandos T-SQL. Sin

embargo, hay que tener en cuenta que si usas T-SQL entonces pierdes uno de los

mayores beneficios de SQL Server: Procedimientos de recuperación

automatizados.

Backup Devices

Son un objeto que apunta a un archivo físico en disco, en cinta o en la red.  Si el

backup device apunta a cinta, entonces el tape drive tiene que estar conectado

directamente al servidor y no puede ser remoto. Los backup devices son útiles

porque te evitan tener que usar rutas o paths fijos, lo cual te da flexibilidad a la

hora de diseñar scripts para respaldar la base de datos y transportarlos de una

región a otra (de TEST a  PROD).

Aunque es posible que juntes varios respaldos en un solo archivo, esta práctica no

es recomendable y la manera correcta de hacerlo es que cada respaldo resida en

sus propios archivos.

RESPALDAR Y RECUPERACIÓN DELA BASE DE DATOS MYSQLEl método más utilizado para crear copias de seguridad de MySQL se basa en el

uso del comando mysqldump. Este comando se incluye dentro de las utilidades

del propio servidor MySQL, por lo que ya se instaló cuando instalaste MySQL.

Para comprobar que dispones de mysqldump, abre una consola de comandos y

ejecuta lo siguiente:

$ mysqldump

para comprobar la versión instalada:

$ mysqldump –version: mysqldump Ver 10.XX Distrib 5.X.XX

Si se produce un error de tipo "command not found", es posible que no hayas

instalado MySQL correctamente o que tengas que indicar la ruta completa hasta

donde se encuentre el comando, como por ejemplo:

$ /usr/local/mysql/bin/mysqldump

Copia de seguridad básica

Ejecuta el siguiente comando para realizar una copia de seguridad completa de la

base de datos llamada NOMBRE_BASE_DE_DATOS. No olvides reemplazar

TU_USUARIO y TU_CONTRASEÑA por las credenciales que utilizas para

acceder al servidor de base de datos:

$ mysqldump --user=TU_USUARIO --password=TU_CONTRASEÑA

NOMBRE_BASE_DE_DATOS > copia_seguridad.sql

Si por ejemplo el usuario es root, la contraseña también es root y la base de datos

se llama acme, el comando que debes ejecutar es el siguiente:

$ mysqldump --user=root --password=root acme > copia_seguridad.sql

Si por motivos de seguridad no quieres escribir la contraseña como parte del

comando, puedes reemplazar la opción --password=XX por -p. Al hacerlo, MySQL

te pedirá que escribas la contraseña a mano cada vez que realices una copia de

seguridad:

$ mysqldump --user=root -p acme > copia_seguridad.sql

Enter password: *********

Recuperando una copia de seguridad

Las copias de seguridad sólo son útiles si se pueden recuperar fácilmente los

datos cuando se produce un error. Suponiendo que los datos a recuperar se

encuentran en el archivo copia_seguridad.sql, el comando que debes ejecutar

para recuperar la información de la base de datos es el siguiente:

$ mysql --user=TU_USUARIO --password=TU_CONTRASEÑA <

copia_seguridad.sql

Observa cómo en este caso se ejecuta el comando mysql y no el comando

mysqldump. Utilizando los mismos datos que en el ejemplo anterior, el comando a

ejecutar sería:

$ mysql --user=root --password=root < copia_seguridad.sql

En este comando no hace falta indicar el nombre de la base de datos que se está

recuperando, porque los archivos generados por mysqldump ya contienen esa

información. De hecho, al ejecutar este comando de recuperación se borra la base

de datos original y toda la información de sus tablas, para después insertar toda la

información contenida en el archivo copia_seguridad.sql.

Si la copia de seguridad la haces en una versión de MySQL moderna y la

recuperación de la información se realiza en una versión un poco antigua, es

mejor que añadas la opción --skip-opt al realizar la copia de seguridad, para

desactivar algunas opciones modernas e incompatibles:

$ mysqldump --user=TU_USUARIO --password=TU_CONTRASEÑA

--skip-opt NOMBRE_BASE_DE_DATOS > copia_seguridad.sql

Copias de seguridad de más de una base de datos

Normalmente el comando mysqldump se utiliza para realizar la copia de seguridad

de una única base de datos. No obstante, en ocasiones es necesario copiar varias

bases de datos. Para ello, utiliza la opción --databases e indica el nombre de todas

las bases de datos separados por un espacio en blanco:

$ mysqldump --user=TU_USUARIO --password=TU_CONTRASEÑA

--databases NOMBRE_BASE_DE_DATOS_1 NOMBRE_BASE_DE_DATOS_2

NOMBRE_BASE_DE_DATOS_3 > copia_seguridad.sql

Si lo que quieres es realizar una copia de seguridad de todas las bases de datos,

utiliza en su lugar la opción --all-databases:

$ mysqldump --user=TU_USUARIO --password=TU_CONTRASEÑA

--all-databases > copia_seguridad.sql

RESPALDO Y RECUPERACIÓN EN ORACLE

El RMAN (Recovery Manager) es una herramienta de Oracle que sirve para realizar las tareas que están relacionadas con la seguridad de los datos como por

ejemplo hacer copias de seguridad, restauraciones, recuperaciones y muchas otras cosas más.El RMAN tiene una interfaz de línea de comandos y también hay herramientas gráficas que permiten utilizarlo.Para acceder a RMAN por línea de comandos se utiliza el comando rman.Para salir de la herramienta se utiliza el comando quit o exit. 

Ahora estamos conectados al catálogo de recuperación, al Recovery Manager, pero en éste momento no estamos conectados a ninguna base de datos.

Ventajas de realizar copias con RMAN: Control sobre las copias: siempre el RMAN guarda información sobre qué copias

de seguridad se han hecho y de qué se han hecho las copias de seguridad, donde

están ubicadas esas copias y esa información es muy útil para luego hacer

restauraciones. Es decir RMAN sabe dónde está ubicada cada copia de la base de

datos, archivo dañado, etc.

Lo necesario para recuperar: RMAN posee toda la información necesaria para

realizar la recuperación tanto de la base de datos como de archivos dañados, etc.

Restauraciones Directas: RMAN se encarga de ir a buscar la copia de seguridad

que corresponde para ser recuperada y restaurarla en el sitio que le corresponde.

Politicas de Seguridad: nos permite ingresar la frecuencia con que tenemos que

hacer el backup, cuándo se considera que un backup ya no es necesario

guardarlo, etc.

Todas estas funcionalidades que vemos de RMAN tienen que hacerse en base a

algún repositorio de información.

Toda ésta información que tiene RMAN debe ser guardada en algún sitio, para ello

RMAN puede guardar dicha información en 2 sitios:

1) En el ControlFile de la base de datos al cual se está haciendo la copia: una desventaja de utilizar ésta estrategia es que estamos utilizando mucho espacio del ControlFile, además si perdemos el controlfile, RMAN no podría acceder a la información necesaria para saber dónde está lo que tiene que restaurar.

2) Crear Catalogo de RMAN (Recovery Catalog) ésta estrategia se basa en crear un repositorio de información, un tablespace con un usuario y hacer que allí se guarde toda la información para gestionar las copias de seguridad de una base de datos.

Si RMAN no dispone de un catálogo de recuperación, toda la información será guardada en el ControlFile de la base de datos a la cual se conecta.

Cuando iniciamos una sesión con RMAN tenemos que informarle a qué nos conectamos:Como mínimo tenemos que informar el Target.El Target es un parámetro que describe cuál es la base de datos sobre la cual vamos a hacer copias de seguridad, siempre hay que especificar una base de datos como target.

Conexión a RMAN:

$ rman target catalog/nocatalog

Por defecto es catalog, si colocamos nocatalog RMAN debe obtener la información del ControlFile de la base de datos Target.

Al conectarnos a RMAN nos muestra la información de que ha encontrado la base de datos Target.

Crear un Catálogo para RMAN

Pasos para crear un catálogo de una BBDD para RMAN

1) En una base de datos distinta, crear el repositorio.

Para este ejemplo creamos una base de datos llamada seg utilizando el asistente de creación de base de datos DBCA, como usuario oracle lanzamos este comando:

[oracle@curso ~]$ dbca

Se nos presenta la primera pantalla, escogemos crear base de datos.

Click en Next

Escogemos la plantilla de propósito general

Establecemos el nombre global de la base (el nombre del servicio principal) y el nombre de la instancia (SID).

Establecemos que queremos una consola de gestión.

  

Ponemos la misma contraseña para todos los usuarios, recordar esta contraseña.

 

Utilizamos la plantilla para la ubicación de los archivos de la base de datos.

Especificamos la Flash Recovery Area.

Añadimos los schemas de ejemplo.

Establecemos el uso de memoria

Escogemos Unicode como juego de caracteres.

Revisamos la instalación a realizarse.

  

Le damos a finalizar

Se nos presenta un pequeño resumen, lo aceptamos.

  

Se inicia la creación de la base de datos.

Esperamos a la finalización de la instalación, en este mensaje final se muestra el puerto de acceso a la consola de gestión.

Ya tenemos creada nuestra base de datos para poder crear el repositorio para RMAN, para ello creamos un tablespace y un usuario.Iniciamos una sesión en sqlPlus$ sqlplus sys/seg@ as sysdba

A modo de ejemplo creamos el tablespace tb_cat que contendrá un único datafiletb_cat_1.dbf

Creamos el schema, es decir crear el usuario, éste usuario se llamará rman y estará identificado por rman.

Debemos otorgarle al usuario los privilegios correspondientes:

$ grant recovery_catalog_owner to rman;

2) Conectar rman Catalog

Nos conectamos al catálogo:

$ rman catalog rman/rman@seg

  

Estamos conectados pero aún no tenemos creado el catálogo

3) Crear el catalogo (create catalog)$ create catalogSe crean las tablas en la base de datos, concretamente en el tablespace en el schema que hemos definido, en el cual estará la información del catálogo de recuperación.

Para probar que se hayan creado todas las tablas, nos conectamos a sqlplus:

$ sqlplus sys / seg @ seg as sysdba

Todas las tablas se crearon y son parte del repositorio, o sea del catálogo de recuperación.Aquí es donde internamente RMAN guardará la información de qué copias se ha realizado, donde están esas copias, la antigüedad de cada copia, las políticas de seguridad que hemos aplicado, etc...

4) Conectar a rman target catalog

Ahora hay que llenar el catálogo con la información de la base de datos Target, para ellos nos conectamos a RMAN especificando el Target y el Catalog

$ rman target usuario/password@bd catalog usuario/password@bd

5) Registrar la Base de Datos (register database)

$ register database;

Este comando lo que hace es leer toda la información de la base de datos por medio del controlfile de la base de datos target y lo coloca dentro del catálogo que acabamos de crear.

6) Ejecutar report schema;

$ report schema;

Nos devuelve los contenidos físicos de la base de datos que actúa como target.

Ya tenemos creado el catálogo de recuperación para realizar las tareas de seguridad por medio de RMAN.

BIBLIOGRAFÍA

http://sqlserverlatino.com/respaldo-y-recuperacion-en-sql-server/

http://descubriendooracle.blogspot.mx/2011/08/crear-el-catalogo-de-recuperacion-de.html