INSTITUTO TECNOLGICO SUPERIOR DEL SUR DEL ESTADO DE YUCATN. ADMN. DE BASE DE DATOS.

Nombre de la alumna: Elvia Perlita Ramrez Cel. PROFESOR: I.S.C David Avils.

SEXTO SEMESTRE GRUPO A

INGENIERA EN SISTEMAS COMPUTACIONALES. Investigacin: RESPALDO Y RECUPERACIN DE BD Fecha de entrega: 31/03/14

RESPALDO Y RECUPERACIN EN SQL SERVER Disear un plan de respaldo y recuperacin involucra decidir qu bases de datos respaldar, con qu frecuencia, donde almacenar los respaldos, qu tan frecuentemente sobre-escribirlos y qu tan rpido necesitas recuperar la base de datos. Sin embargo, para disear una estrategia de respaldo, primero hay que pensar en el proceso de recuperacin y en la prdida 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 recuperacin (recovery model) a usar para configurar la base de datos. Las bases de datos en SQL Server soportan tres modelos de recuperacin: Full, Bulk-Logged y Simple y cada uno de estos modelos tiene una influencia muy particular sobre el tamao del Transaction Log y el grado de prdida de datos en caso de falla. Bajo el modelo FULL, SQL Server registra todas las transacciones

realizadas dentro de la bitcora de transacciones (transaction log), incluyendo inserciones masivas (bulk), construcciones de ndices, y las operaciones regulares. A diferencia del modelo simple, la bitcora de transacciones crece progresivamente hasta que la respaldas explcitamente. Este es el modelo que ofrece la mayor flexibilidad en la recuperacin de los datos, atravs de restauraciones a cualquier punto en el tiempo.

Bajo el modelo SIMPLE las transacciones tambin se registran en la bitcora de transacciones aunque a menor detalle y las transacciones no activas se descartan de la bitcora de forma regular en cada checkpoint, en vez de en cada respaldo. Es decir, la bitcora no crece progresivamente si no que se trunca en cada checkpoint, a menos que existan transacciones activas. De ser as, entonces la bitcora crece hasta que las transacciones activas terminen y la bitcora pueda ser truncada sin problema.

En cuanto a los tipos de respaldo se refiere, SQL Server ofrece varias opciones: Completo, Diferencial, Filegroup, Bitcora de Transacciones y Copy-Only. Completo

El respaldo completo no necesita mucha explicacin ya que involucra respaldar todas y cada una las pginas que forman parte de la base de datos y aquellas asociadas con la bitcora 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 pginas 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 pginas que han cambiado desde el ltimo respaldo completo, los respaldos diferenciales generalmente son ms rpidos 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 sealar que aunque es

posible respaldar un archivo en especfico, dicha granularidad no es recomendable ya que el proceso de recuperacin 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 combinacin con los respaldos de la bitcora de transacciones para recuperar secciones de la base de datos. Bitcora de transacciones

El respaldo de la Bitcora de Transacciones o Transaction Log solamente puede hacerse cuando el modelo de recuperacin de la base de datos es FULL o Bulklogged y se realiza principalmente con el fin de reducir la cantidad de datos que pudieran perderse en caso de una falla y reducir el tamao del archivo que almacena la bitcora. Cuando realizas un respaldo de la bitcora, SQL Server respalda todas las pginas nuevas desde el ltimo respaldo completo, diferencial, o desde el ltimo respaldo de la bitcora. Esto significa que cada respaldo de la Bitcora 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 informacin accidentalmente, corrupcin por fallas de hardware y desastres naturales. Las tcnicas o procedimientos que seguirs para restaurar una base de datos dependern de los tipos de respaldos que formen parte de la estrategia de respaldo que diseaste y pusiste en operacin. Cuando restauras una base de datos de usuario sobre una Master Database nueva, la Master Database se actualiza usando la informacin contenida en la base de datos de usuario que ests 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 informacin sobre la estructura de la base de datos, parmetros de configuracin 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 recomendacin comn es respaldar la base de datos Master un da s y un da no y mantener varias respaldos a la mano. SQL Server te permite operar casi normalmente durante los respaldos a excepcin de que no puedes agregar o quitar bases de datos ni tampoco reducirlas de tamao (shrink). Esta funcionalidad es posible gracias a que SQL Server respalda la seccin del Transaction Log que se us mientras la operacin 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 operacin 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 recuperacin 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 parmetros o informacin mnima 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 tambin tienes la opcin de especificar varios dispositivos (hasta un mximo de 64). En SQL Server tienes la opcin de hacer los respaldos usando la interface grfica SQL Server Management Studio (SSMS) o atravs 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 recuperacin

automatizados. Backup Devices

Son un objeto que apunta a un archivo fsico 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 disear scripts para respaldar la base de datos y transportarlos de una regin a otra (de TEST a PROD). Aunque es posible que juntes varios respaldos en un solo archivo, esta prctica no es recomendable y la manera correcta de hacerlo es que cada respaldo resida en sus propios archivos. RESPALDAR Y RECUPERACIN DELA BASE DE DATOS MYSQL El mtodo ms 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 versin 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 bsica 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_CONTRASEA por las credenciales que utilizas para acceder al servidor de base de datos:

mysqldump

--user=TU_USUARIO

--password=TU_CONTRASEA

NOMBRE_BASE_DE_DATOS > copia_seguridad.sql Si por ejemplo el usuario es root, la contrasea tambin 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 contrasea como parte del comando, puedes reemplazar la opcin --password=XX por -p. Al hacerlo, MySQL te pedir que escribas la contrasea 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 slo son tiles si se pueden recuperar fcilmente 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 informacin de la base de datos es el siguiente: $ mysql --user=TU_USUARIO --password=TU_CONTRASEA <

copia_seguridad.sql Observa cmo 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 sera: $ 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 informacin. De hecho, al ejecutar este comando de recuperacin se borra la base

de datos original y toda la informacin de sus tablas, para despus insertar toda la informacin contenida en el archivo copia_seguridad.sql. Si la copia de seguridad la haces en una versin de MySQL moderna y la recuperacin de la informacin se realiza en una versin un poco antigua, es mejor que aadas la opcin --skip-opt al realizar la copia de seguridad, para desactivar algunas opciones modernas e incompatibles: $ mysqldump --user=TU_USUARIO --password=TU_CONTRASEA --skip-opt NOMBRE_BASE_DE_DATOS > copia_seguridad.sql Copias de seguridad de ms 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 opcin --databases e indica el nombre de todas las bases de datos separados por un espacio en blanco: $ mysqldump --user=TU_USUARIO --password=TU_CONTRASEA --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 opcin --all-databases: $ mysqldump --user=TU_USUARIO --password=TU_CONTRASEA --all-databases > copia_seguridad.sql

RESPALDO Y RECUPERACIN EN ORACLE El RMAN (Recovery Manager) es una herramienta de Oracle que sirve para realizar las tareas que estn relacionadas con la seguridad de los datos como por

ejemplo hacer copias de seguridad, restauraciones, recuperaciones y muchas otras cosas ms. El RMAN tiene una interfaz de lnea de comandos y tambin hay herramientas grficas que permiten utilizarlo. Para acceder a RMAN por lnea de comandos se utiliza el comando rman. Para salir de la herramienta se utiliza el comando quit o exit.

Ahora estamos conectados al catlogo de recuperacin, 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 informacin sobre qu copias de seguridad se han hecho y de qu se han hecho las copias de seguridad, donde estn ubicadas esas copias y esa informacin es muy til para luego hacer restauraciones. Es decir RMAN sabe dnde est ubicada cada copia de la base de datos, archivo daado, etc. Lo necesario para recuperar: RMAN posee toda la informacin necesaria para realizar la recuperacin tanto de la base de datos como de archivos daados, 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, cundo se considera que un backup ya no es necesario guardarlo, etc.

Todas estas funcionalidades que vemos de RMAN tienen que hacerse en base a algn repositorio de informacin.

Toda sta informacin que tiene RMAN debe ser guardada en algn sitio, para ello RMAN puede guardar dicha informacin 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, adems si perdemos el controlfile, RMAN no podra acceder a la informacin necesaria para saber dnde est lo que tiene que restaurar. 2) Crear Catalogo de RMAN (Recovery Catalog) sta estrategia se basa en crear un repositorio de informacin, un tablespace con un usuario y hacer que all se guarde toda la informacin para gestionar las copias de seguridad de una base de datos. Si RMAN no dispone de un catlogo de recuperacin, toda la informacin ser guardada en el ControlFile de la base de datos a la cual se conecta. Cuando iniciamos una sesin con RMAN tenemos que informarle a qu nos conectamos: Como mnimo tenemos que informar el Target. El Target es un parmetro que describe cul es la base de datos sobre la cual vamos a hacer copias de seguridad, siempre hay que especificar una base de datos como target. Conexin a RMAN: $ rman target catalog/nocatalog Por defecto es catalog, si colocamos nocatalog RMAN debe obtener la informacin del ControlFile de la base de datos Target.

Al conectarnos a RMAN nos muestra la informacin de que ha encontrado la base de datos Target. Crear un Catlogo para RMAN Pasos para crear un catlogo 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 creacin 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 propsito 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 gestin.

Ponemos la misma contrasea para todos los usuarios, recordar esta contrasea.

Utilizamos la plantilla para la ubicacin de los archivos de la base de datos.

Especificamos la Flash Recovery Area.

Aadimos los schemas de ejemplo.

Establecemos el uso de memoria

Escogemos Unicode como juego de caracteres.

Revisamos la instalacin a realizarse.

Le damos a finalizar

Se nos presenta un pequeo resumen, lo aceptamos.

Se inicia la creacin de la base de datos.

Esperamos a la finalizacin de la instalacin, en este mensaje final se muestra el puerto de acceso a la consola de gestin.

Ya tenemos creada nuestra base de datos para poder crear el repositorio para RMAN, para ello creamos un tablespace y un usuario. Iniciamos una sesin 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 catlogo: $ rman catalog rman/rman@seg

Estamos conectados pero an no tenemos creado el catlogo 3) Crear el catalogo (create catalog) $ create catalog Se crean las tablas en la base de datos, concretamente en el tablespace en el schema que hemos definido, en el cual estar la informacin del catlogo de recuperacin.

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 catlogo de recuperacin. Aqu es donde internamente RMAN guardar la informacin de qu copias se ha realizado, donde estn esas copias, la antigedad de cada copia, las polticas de seguridad que hemos aplicado, etc... 4) Conectar a rman target catalog

Ahora hay que llenar el catlogo con la informacin 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 informacin de la base de datos por medio del controlfile de la base de datos target y lo coloca dentro del catlogo que acabamos de crear.

6) Ejecutar report schema; $ report schema;

Nos devuelve los contenidos fsicos de la base de datos que acta como target.

Ya tenemos creado el catlogo de recuperacin para realizar las tareas de seguridad por medio de RMAN.

BIBLIOGRAFA http://sqlserverlatino.com/respaldo-y-recuperacion-en-sql-server/ http://descubriendooracle.blogspot.mx/2011/08/crear-el-catalogo-de-recuperacionde.html