• Author / Uploaded
• Jeff Tenelema

Citation preview

RECUPERACION EN SQL SERVER R2 2008 INTEGRANTES:

 JEFFERSON TENELEMA  VICTOR MALDONADO

RECUPERACION EN SQL SERVER R2 2008 Contenido 1. INTRODUCCION A LA RECUPERACION EN SQL SERVER 2008 ...........................................................................3 1.1. Recuperación y Copia de seguridad de la base de datos ..........................................................................3 1.1.1 Estrategias de De Recuperación ..........................................................................................................3 1.2. Copias de seguridad y Modelos de Recuperación .....................................................................................4 1.2.1 Copias de Seguridad ............................................................................................................................4 1.2.2 Ventajas ...............................................................................................................................................5 1.3. Tipos de Copias de Seguridad ....................................................................................................................6 1.3.1 Copia de seguridad completa ..............................................................................................................6 1.3.2. Copia de seguridad diferencial: ..........................................................................................................8 1.3.3 Copia de seguridad de grupo de archivos: ..........................................................................................9 1.3.4. Copias de Seguridad del Registro de Transacciones ........................................................................10 Para crear una copia de seguridad del registro de transacciones ..............................................................10 1.4. Modelos de Recuperación .......................................................................................................................11 1.4.1. Modelo de recuperación completa .................................................................................................11 1.4.2. Modelo de recuperación de registro masivo...................................................................................12 1.4.3. Modelo de recuperación simple .......................................................................................................13 1.5 EJERCICIO: .................................................................................................................................................14 1.6 BIBLIOGRAFIA ...............................................................................................................................................19

1. INTRODUCCION A LA RECUPERACION EN SQL SERVER 2008 1.1. Recuperación y Copia de seguridad de la base de datos

Una copia de seguridad de la base de datos es una copia de la base de datos. Esta copia se utiliza para recuperar la base de datos o los Datasets individuales en caso de error o daños en la base de datos. Como en general se invierten mucho tiempo, esfuerzo y dinero en los datos de una organización, es fundamental que tenga un plan de recuperación probado y preparado para la base de datos . Un plan de recuperación incluye copias de seguridad de base de datos y una estrategia de recuperación probada.

1.1.1 Estrategias de Recuperación Las necesidades de la estrategia de recuperación y copia de seguridad varían de acuerdo con su situación específica. El tipo de copias de seguridad que utilice, el lugar donde deben estar almacenadas, el momento en el que deben realizarse, y el momento y la manera en que se puede realizar la recuperación pueden estar afectados por los siguientes factores interrelacionados.



¿Con qué frecuencia cambian los datos? Mientras la Base d datos y su contenido se modifiquen con más frecuencia, con más frecuencia deben realizarse las copias de seguridad.



¿Qué tan importantes son los datos para la organización? ¿La misión de los datos es fundamental? Si es así, el tiempo de recuperación y la divisa de los datos recuperados son importantes. ¿La retención de los datos tiene importancia legal? Si es así, debe considerar la posibilidad de almacenar las copias de seguridad fuera del sitio.



¿Cuánto tiempo es aceptable para la recuperación?

Ciertos datos pueden ser necesarios de inmediato, mientras que la necesidad de otros datos no es tan urgente. Si no existen muchos datos en la base de datos, compare cuánto tiempo tarda realizar una recuperación de la base de datos versus volver a introducir los datos manualmente. 

¿Cuánto tiempo de inactividad se puede tolerar? Esto afecta si puede desconectar la base de datos para realizar copias de seguridad o recuperación de los datos. Si los datos deben estar disponibles las 24 horas del día, asegúrese de programar las copias de seguridad fuera de las horas pico.



¿Qué tan grande es la base de datos? Esto afecta la ubicación y el espacio de almacenamiento, como también la cantidad de tiempo que tarda realizar copias de seguridad y la recuperación de la base de datos.



¿Cuáles son los recursos del sistema con los que debe trabajar? ¿Cuenta con un amplio espacio de almacenamiento (virtual y físico) para las copias de seguridad? ¿Existe la posibilidad de configurar un espejo o copia de su base de datos? ¿La red puede manejar un procedimiento de recuperación o copia de seguridad que ocurre mientras los usuarios aún están conectados a la base de datos? ¿Tiene sentido contar con consultores externos que le proporcionen la administración de la recuperación, el almacenamiento y la copia de seguridad de la base de datos?



¿Qué tipo de sistema de administración de bases de datos (DBMS) utiliza? La mayoría de los DBMS cuentan con su propia utilidad administrativa para realizar la administración de la recuperación y copia de seguridad, pero también hay disponibles muchos productos de software de terceros.

1.2. Copias de seguridad y Modelos de Recuperación 1.2.1 Copias de Seguridad El componente de copias de seguridad y restauración de SQL Server ofrece una protección esencial para los datos críticos almacenados en las bases de datos de SQL Server. Para minimizar el riesgo de pérdida de datos catastrófica, debe realizar copias de seguridad de las bases de datos para conservar las modificaciones en los datos de forma periódica.

Una estrategia de copias de seguridad y restauración correctamente planeada contribuye a la protección de las bases de datos de la pérdida de datos derivada de daños causados por diferentes

errores. Pruebe la estrategia mediante la restauración de las copias de seguridad y la posterior recuperación de la base de datos para estar preparado y poder responder de forma eficaz ante un desastre.

1.2.2 Ventajas La copia de seguridad de las bases de datos de SQL Server, la ejecución de procedimientos de restauración de prueba de las copias de seguridad y el almacenamiento de las copias en una ubicación segura y fuera del sitio contribuyen a protegerse ante una pérdida de datos catastrófica. Con las copias de seguridad válidas de una base de datos puede recuperar los datos en caso de que se produzcan errores, por ejemplo:  Errores de medios.  Errores de usuario, por ejemplo, quitar una tabla por error.  Errores de hardware, por ejemplo, una unidad de disco dañada o la pérdida permanente de un servidor.

 Desastres naturales. El uso de la copia de seguridad de SQL Server en el servicio de almacenamiento Blob de Windows Azure le permite crear una copia de seguridad externa en una región diferente de la ubicación local, con lo que podrá utilizarla en caso de que un desastre natural afecte a su ubicación.

Además, las copias de seguridad de una base de datos son útiles para fines administrativos habituales, como copiar una base de datos de un servidor a otro, configurar Grupos de disponibilidad AlwaysOn o la creación de reflejo de la base de datos y el archivo.

1.3. Tipos de Copias de Seguridad 1.3.1 Copia de seguridad completa Copia de seguridad completa que incluye todos los datos de una base de datos determinada o un conjunto de grupos de archivos o archivos, así como una cantidad suficiente del registro como para permitir la recuperación de datos.

DONDE SE GUARDAN LAS COPIAS DE SEGURIDAD?

Podemos saber la ubicación del directorio de los respaldos de la siguiente forma:

Al ingresar a esta ventana emergente, podemos ver el directorio en donde están nuestras copias de seguridad o respaldos:

1.3.2. Copia de seguridad diferencial: Objetivo: Captura todas las extensiones que han cambiado desde la última copia de seguridad su propósito principal: reduce el número de copias de seguridad de registro de transacciones que necesitan ser restauradas  Una copia de seguridad diferencial tiene que ser aplicada a una copia de seguridad completa

Funcionamiento SQL Server sigue cada extensión que ha sido modificada, siguiendo una copia de seguridad completa usando una página especial en el encabezado de una base de datos llamado “mapa de cambio diferencial” (DCM). Una copia de seguridad completa pondrá a cero el contenido de la DCM. Cuando se realizan cambios en las extensiones dentro de la base de datos, SQL Server establecerá el bit correspondiente para la extensión a 1.Cuando se ejecuta una copia de seguridad diferencial, SQL Server lee el contenido de la DCM para encontrar todas las extensiones que han cambiado desde la última copia de seguridad.

 Pasos para crear una copia de seguridad diferencial de una base de datos



Ejecute la instrucción BACKUP DATABASE para crear la copia de seguridad de base de datos diferencial, especificando: o El nombre de la base de datos de la que se va a realizar una copia de seguridad. o El dispositivo de copia de seguridad en el que se escribe la copia de seguridad de base de datos completa. o La cláusula DIFFERENTIAL, para especificar que solo se realice una copia de seguridad de las partes de la base de datos que han cambiado desde la última copia de seguridad de base de datos completa. La sintaxis necesaria es:

BACKUP DATABASE database_name TO WITH DIFFERENTIAL

1.3.3 Copia de seguridad de grupo de archivos: Objetivo: Permite destinar una porción de una base de datos para ser copiada en una copia de seguridad pueden ser usadas en conjunto con las copias de seguridad diferencial y de registro de transacciones para recuperar una porción de la base de datos en el caso de un fallo solo la parte de la base de datos que se estará restaurando estar a fuera de línea, el resto puede estar accesible para las aplicaciones durante la operación de restauración Sintaxis: BACKUP DATABASE database_name TO

1.3.4. Copias de Seguridad del Registro de Transacciones Objetivo: Contienen los cambios de los registros de transacciones a través de una copia de seguridad completa, es decir, captura cualquier cambio realizado desde la última copia de seguridad del registro de transacciones completa antes del backup del registro de transacción:

Para crear una copia de seguridad del registro de transacciones

Ejecute la instrucción BACKUP LOG para realizar una copia de seguridad del registro de transacciones y especifique: El nombre de la base de datos a la que pertenece el registro de transacciones del que se desea hacer una copia de seguridad.  El dispositivo de copia de seguridad en el que se va a escribir la copia de seguridad del registro de transacciones. 

Sintaxis BACKUP LOG Database TO GO

1.4. Modelos de Recuperación Para Microsoft SQL Server, el modelo de recuperación es una configuración de la base de datos, que se cambió ya sea mediante Management Studio o la declaración ALTER DATABASE. Existen tres modelos de recuperación para SQL Server: completa, de registro masivo y simple. A continuación se resume cada uno.

1.4.1. Modelo de recuperación completa La recuperación completa permite la recuperación de un punto en el tiempo (punto de fallo) si cuenta con las copias de seguridad del registro de transacción en ese punto en el tiempo. La recuperación de un punto en el tiempo significa la posibilidad de recuperar una base de datos en un momento específico, restaurando todas las transacciones confirmadas y deshaciendo todas las transacciones incompletas. La recuperación de un punto de fallo o un punto en el tiempo implica lo siguiente: 

Hacer una copia de seguridad del registro de transacción activo actual



Restaurar la copia de seguridad completa de base de datos más reciente sin recuperación



Restaurar la copia de seguridad diferencial de base de datos más reciente sin recuperación



Restaurar en secuencia cualquier copia de seguridad del registro de transacción sin recuperación



Restaurar la última copia de seguridad del registro de transacción con recuperación Debe usar el modelo de recuperación completa para una base de datos de producción que contenga datos críticos.  Para restaurar una copia de seguridad del registro de transacciones Ejecute la instrucción RESTORE LOG para aplicar la copia de seguridad del registro de transacciones especificando: o El nombre de la base de datos a la que se aplicará el registro de transacciones. o El dispositivo de copia de seguridad desde el que se restaurará la copia de seguridad del registro de transacciones. o La cláusula NORECOVERY. La sintaxis básica de esta instrucción es la siguiente: RESTORE LOG database_name FROM WITH NORECOVERY. Donde database_name es el nombre de la base de datos y es el nombre del dispositivo que contiene la copia de seguridad de registros que se restaura.

Después de restaurar la copia de seguridad más reciente en la secuencia de restauración, use una de las instrucciones siguientes para recuperar la base de datos: Recuperar la base de datos como parte de la última instrucción RESTORE LOG: RESTORE LOG FROM WITH RECOVERY; GO Esperar a recuperar la base de datos utilizando otra instrucción RESTORE DATABASE: RESTORE LOG FROM WITH NORECOVERY; RESTORE DATABASE WITH RECOVERY;  GO

1.4.2. Modelo de recuperación de registro masivo Las bases de datos que utilizan el modelo de recuperación de re gistro masivo, mínimamente registran masivamente las operaciones en el registro de transacción de Microsoft SQL Server. Estas operaciones incluyen CREATE INDEX, SELECT … INTO, writetext, updatetext y BULK INSERT. El registro de transacción no graba la suficiente información para recuperar estos cambios si ocurre un error de medios después de una operación masiva. Puede recuperar la base de datos en el punto de fallo, pero los datos pueden no ser consistentes si se cambiaron mediante una operación masiva. El proceso de restauración es el mismo que el de recuperación de base de datos completa.

Es probable que los sitios que realizan operaciones masivas regularmente cuando otros usuarios no acceden a la base de datos utilicen el modelo de recuperación de Registro masivo. O bien, puede utilizar el modelo de recuperación completa la mayoría de las veces. Pero, cuando realice operaciones masivas, utilice la recuperación de registro masivo para ahorrar espacio en disco que utilizará el registro de transacción cuando realice una recuperación de base de datos completa y mejore el rendimiento de la base de datos durante la operación masiva.

1.4.3. Modelo de recuperación simple El modelo de recuperación simple no utiliza un registro de transacción para la recuperación. Si utiliza el modelo de recuperación simple, sólo puede restaurar copias de seguridad completas de base de datos. Por lo tanto, los datos sólo se recuperan hasta la copia de seguridad más reciente, y no es posible la recuperación de un punto en el tiempo. Los cambios que se realizaron desde la última copia de seguridad de la base de datos se pierden. La ventaja de utilizar el modelo de recuperación simple es que se necesita menos administración del espacio de registro y del registro de transacción. El modelo de recuperación simple se puede utilizar para bases de datos de desarrollo o bases de datos que no se editan con frecuencia.

1.5 EJERCICIO: Recuperación de datos con copia de seguridad completa, registro y copias de seguridad diferenciales en un punto de tiempo

BASE DE DATOS A UTILIZAR SERA VENTAS

Primero crearemos una carpeta que contendrá el backup de nuestra base de datos y a su vez el log de transacciones de la misma.

A continuación procederemos a sacar un BACKUP COMPLETO (FULL) de nuestra base de datos que cuenta con solo 5 registros

Para esto creamos una nueva consulta y colocamos los siguientes comandos.

Con estos comandos preparamos nuestra base de datos Ventas para poder sacar un BACKUP COMPLETO que supondremos que son los backups del día lunes en la mañana. Ahora procedernos a sacar un BACKUP de nuestra base de datos Ventas y lo guardaremos en la Unidad D:

Posteriormente verificamos el contenido de nuestro Backup-ventas

Pero suponemos que para finalizar el día lunes en la noche nos encontramos agregados 3 productos mas Y por motivo de cierre sacamos un Backup-Diferencial de nuestra base de datos

Ejecutamos el Siguiente script y verificamos que se haya generado el backup diferencial y la posición en la que se encuentre ya que su posición definirá el tiempo al que queremos realizar la restauración.

El siguiente paso es sacar el registro de transacciones de todo el Día lunes para lo cual colocamos los siguientes comando

Para el siguiente caso asumimos que las transacciones del día lunes fueron guardadas de manera exitosa Al siguiente día martes en la mañana se agregan 2 productos más.

A Continuación procedemos a sacar un Backup de esta transacción

Ahora se agrega un producto más y por motivo de cierra sacamos otro Backup de todo el día (BackupDiferencial)

Y sacamos otro Backup del Registro de transacciones de ese mismo día

Debemos tomar en cuenta que la posicon en la que se almacenan los Backup y los logs nos serviran para su posterior recupacion

Ahora bien al siguiente día tenemos que nuestra base de datos ha sufrido un fallo en los registros de datos necesitamos restaurar nuestra base de datos con sus transacciones a un punto dado  Sabemos que las transacciones del día lunes fueron las correctas durante todo el día  También sabemos que las transacciones que se realizaron el día martes en la mañana estuvieron correctas.  Pero el fallo sucedió el martes en la noche y se necesitan los datos que se tenían hasta el martes en un punto de tiempo especificado. SOLUCION:  Podemos utilizar nuestro Backup Completo del día lunes y el último registro de transacción del día martes e intentar restaurar a un punto en el que todas las transacciones funcionaron bien y los datos eran correcto, omitiendo los registros corruptos. Eliminamos la BD con los datos corruptos Restauramos nuestro backup full del día lunes Restauramos nuestro Backup full del día lunes al finalizar el día debido a que este punto de tiempo nuestra base es consistente. Recuperamos el log de transacciones del fin Restauramos el log de transacciones del día martes a un cierto punto específico

Recuperamos la base de datos por completo

Ahora seleccionamos la base de datos y comprobamos que los datos hayan vuelto hasta la fecha indicada.

1.6 BIBLIOGRAFIA 1. 2. 3. 4. 5. 6. 7.

http://msdn.microsoft.com/es-ec/library/ms177446.aspx http://microsoftsqlsecret.fullblog.com.ar/log-de-transacciones-ldf.html https://www.simple-talk.com/redgatebooks/shawnmcgehee/sql-backup-restore.pdf http://technet.microsoft.com/es-es/magazine/2009.07.sqlbackup.aspx#id0980008 http://msdn.microsoft.com/es-ec/library/ms179478.aspx http://msdn.microsoft.com/es-es/library/aa337540.aspx http://solutioncenter.apexsql.com/reverting-your-sql-server-database-back-to-a-specific-point-intime/

8. SQL Server 2008/ Microsoft SQL Server 2008: Paso a Paso / Step by Step Paso A Paso, Mike Hotek, Anaya Multimedia-Anaya Interactiva, 2009, ISBN 8441525668, 9788441525665.