Recuperación ante desastres de SQL Server

  • Artículo

SQL Server: Recuperación ante desastres mediante copias de seguridad

Paul S. Randal

T aquí no es mucho sentido tomar las copias de seguridad de SQL Server a menos que sepa cómo restaurarlos. Si tiene algo más complicado que sólo una copia de seguridad completa de la base de datos, va a necesitar conocer algunas opciones RESTORE para poder restaurar correctamente la base de datos para el punto deseado en el tiempo.

Esto es aún más el caso si tiene un diseño de base de datos complicados o una estrategia de copia de seguridad compleja y desea ser capaz de restaurar, por ejemplo, un único archivo o grupo de archivos, o aprovechar las ventajas de disponibilidad parcial de la base de datos.
Mientras tiene una estrategia eficaz de copia de seguridad y las copias de seguridad son válidos, debe ser capaz de recuperarse de un desastre dentro de su objetivo de tiempo de recuperación (RTO) y a su objetivo de punto de recuperación (RPO). En el primer artículo de esta serie de tres partes, hablé los distintos tipos de copias de seguridad y cómo formular una estrategia de copia de seguridad (consulte "Understanding copias de seguridad SQL Server" en el número de julio de 2009).

En este artículo, explicaré cómo funciona la restauración y cómo realizar algunas de las operaciones de restauración más comunes. Será útil si ha leído el artículo de copia de seguridad y el material de fondo que mencioné en la introducción del ese artículo. También voy a explicar algunas más complicadas operaciones, como, por ejemplo, realizando una restauración en un momento y una restauración por etapas en línea con disponibilidad parcial de la base de datos.

Al igual que en el artículo anterior en BACKUP, no voy a explicar cómo funciona la sintaxis de RESTORE o siga los pasos específicos de todas las operaciones de restauración. Libros en pantalla, no un trabajo excelente de. Consulte"RESTORE (Transact-SQL)"para obtener más información, especialmente en los ejemplos repartidos en todo el tema. Hay tantas opciones como realmente a RESTORE que es un tema para explicar ellos otro todo! " Copia de seguridad y restauración de temas sobre cómo (SQL Server Management Studio)"se explica cómo utilizar las herramientas para realizar restauraciones.

Las cuatro fases de restauración

Comencemos con cómo funciona realmente restauración. Una operación de restauración tiene hasta cuatro fases:

  1. Creación de archivo e inicialización
  2. Copia del registro de datos o de transacción
  3. REHACER la fase de recuperación
  4. UNDO fase de recuperación

Uno de los objetivos principales de recuperación de desastres es poner en línea la base de datos tan rápidamente como sea posible. Si su plan de recuperación de desastres implica la restauración de copias de seguridad (en lugar de, digamos, incapacidad a través de un reflejo de base de datos), que se va a desea ser tan rápido como sea posible el proceso de restauración. ¿Con cada uno de los cuatro pasos de restauración en mente, hay algo que puede hacer para ellos acelerar?

El primer paso puede omitirse esencialmente si ya existen los archivos de datos y registro. Esto significa que si va a sobrescribir una base de datos existente, no quite la base de datos antes de realizar la restauración. En su lugar, utilice la opción WITH REPLACE en la primera operación de restauración para indicar a SQL Server para utilizar los archivos existentes. Si no existen los archivos, se creará y, a continuación, se inicializan. Creación de los archivos es muy rápido, pero el proceso de cero-inicialización ellos puede ser muy lento.

Por motivos de seguridad y de forma predeterminada, todos los archivos de base de datos son inicializarse en cero. Puede habilitar la inicialización instantánea de archivos para la instancia de SQL Server, que omite el proceso zeroing para archivo de datos crear y crecer operaciones, los necesarios durante una restauración--lo que se ahorra horas de tiempo de inactividad, incluso si los archivos de datos son sólo gigabytes de tamaño incluidos. Archivos de registro de transacciones son siempre inicializarse en cero debido a la naturaleza circular del registro de transacciones propio.

Puede leer más acerca de todo esto, con referencias a libros en línea, en mi "Inicialización instantánea" categoría de correos de blog.

Quizás se pregunte acerca de la segunda fase--¿por qué el elemento diga "y/o registro de transacciones"? Si lee el artículo anterior, recordará que todas las copias de seguridad completas y diferenciales también incluyen algunos registros de transacciones, para habilitar la base de datos puede restaurarse a un punto transaccionalmente coherente a tiempo. Fase dos es una operación de copia puro: no se realiza ningún procesamiento de datos--por lo que la principal para acelerar esto consiste en tener un subsistema de E/s better-performing. Ésta es una de la pocas veces resulta aceptable "iniciar el hardware en el problema."

La otra forma de acelerar la fase de copia es utilizar algún tipo de tecnología de compresión de copia de seguridad, bien nativo a SQL Server 2008 o a través de una de las distintas soluciones de terceros. Las dos partes de la fase de copia son leer desde el medio de copia de seguridad y escribir a los archivos de datos o registro. Si se pueden hacer menos lecturas (mediante medios de copia de seguridad comprimidos), puede acelerar el proceso general, a costa de una pequeña cantidad de recursos de CPU.

Fases de tres y cuatro son acerca de cómo ejecutar la recuperación en el registro de transacciones para poner la base de datos a un punto transaccionalmente coherente de tiempo. Expliqué los detalles de recuperación en el artículo de febrero de 2009"Registro de comprensión y recuperación en SQL Server". Tenga en cuenta que la fase cuatro es opcional, como explicaré más adelante.

Es suficiente decir que el registro de transacciones más que necesita para recuperarse durante una restauración, tardará más tiempo la restauración. Esto significa que si, por ejemplo, tiene una copia de seguridad completa de la base de datos desde hace una semana y cada hora copias de seguridad del registro de transacciones desde entonces, el proceso de restauración esencialmente reproducir todas las transacciones desde la última semana antes de completar. Hablé una solución para esto en el artículo anterior--agregando las copias de seguridad diferenciales en una estrategia de copia de seguridad dedicada y registro.

Una copia de seguridad diferencial de base de datos contiene todas las páginas de archivo de datos que han cambiado desde la última copia de seguridad completa de la base de datos y pueden utilizarse en una operación de restauración para evitar tener que reproducir todas las transacciones que se produjo en el período entre la copia de seguridad completa de la base de datos y la copia de seguridad diferencial de la base de datos. Esto puede reducir enormemente el tiempo necesario para restaurar la base de datos, pero a costa de una estrategia de copia de seguridad ligeramente más complicada.

Puede encontrar más información en el tema de los libros en pantalla"Optimizar el rendimiento de la restauración en SQL Server y Backup".

¿Lo que necesita para restaurar?

Cuando se produce un desastre, lo primero que debe hacer es averiguar qué está dañado, como esto va a dictar las acciones que debe realizar para recuperarse del desastre. Error de medios de almacenamiento, las posibilidades incluyen:

  • Daño a toda la base de datos (por ejemplo, lo que era almacenar la base de datos se ha destruido, o la base de datos era un único archivo de datos y que se dañara).
  • Daño a un grupo de archivos de una base de datos multi-grupo de archivos.
  • Daño a un único archivo de un grupo de archivos varios archivos.
  • Dañar a una sola página en la base de datos.
  • Daños se propagan a través de la base de datos.

Puede averiguar el daño busca el registro de errores de SQL Server para las notificaciones de archivos son inaccesibles, página-lectura se han producido errores (de instancia, errores de suma de comprobación de página o un error de detección de páginas rasgadas), o que se ha encontrado daños generales. Si se han producido los daños, es práctica habitual para ejecutar la operación de comprobación de coherencia de DBCC CHECKDB para hacerse una idea de cómo pervasive el daño es.

Una explicación de la comprobación de coherencia está fuera del ámbito de este artículo, pero puede ver un vídeo de una presentación realizados en el Tech-Ed IT Forum en noviembre de 2008 titulada"Daños Survival técnicas"y escuchar una entrevista de TechNet Radio desde anteriormente este año donde trataré daños en la base de datos (descarga directa son vínculos here).

No se limitan a errores de servidor o de subsistema de E/s desastres--también hay error humano a considerar. Tablas de base de datos (o datos de ellos) se eliminan accidentalmente a menudo por aplicaciones mal programadas o descuidadas instrucciones de Transact-SQL (el escenario "Me doy no cuenta que estaba en el servidor de producción"). En tales casos, puede ser muy difícil figura fuera lo que debe restaurarse y desde qué punto en el tiempo, especialmente si nadie posee para cometer el error. Es posible que obtenga suerte mediante informes estándar de la traza predeterminada donde la operación DDL todavía está disponible o la instrucción DELETE fue interceptada por su propio registro--pero a menudo no hay ningún registro de quién lo hizo en la base de datos. Trataré la recuperación de esta situación con más detalle más adelante. Independientemente de quién ha realizado la eliminación accidental de datos o cuando ha ocurrido, más espere recuperar--o más tiempo que pasa antes de que es conscientes del problema--el más complejo que se puede recuperar.

Así, como primer paso si la base de datos se está ejecutando en el modelo de recuperación FULL y el registro de transacciones no dañado, realice una copia de seguridad del registro cola para garantizar que todas las transacciones hasta el punto del desastre se realiza una copia de seguridad. Esta copia de seguridad del registro de transacciones "final" tendrá todo hasta el momento del desastre y puede utilizarse para poner la base de datos que se va a restaurar hasta donde sea posible, posiblemente actualizada.

En pocas palabras, debe averiguar qué tiene que restaurar. A continuación, se convierte en una pregunta de lo que va capaz de restaurar.

¿Qué ¿es capaz de restaurar?

Es el objetivo de cualquier operación de restauración restaurar las copias de seguridad menor número posibles, por lo que la operación de restauración es tan rápida como sea posible y se lleva a cabo en su RTO, mientras que también permite que cumpla su RPO.

La principal pregunta aquí es "Qué copias de seguridad ¿tengo?" Si la copia de seguridad sólo que tiene es una copia de seguridad completa de la base de datos desde hace una semana y se ha perdido toda la base de datos, no hay opción de sólo una restauración--hasta un momento hace una semana, perder todo el trabajo desde luego. En pocas palabras, la estrategia de copia de seguridad debe siempre asegurarse de que puedan restaurar lo que necesita en caso de un desastre, como se analizó en el artículo anterior.

¿Cómo puede determinar qué copias de seguridad tiene disponible? En primer lugar, puede consultar que diversas características de copia de seguridad tablas de historial en la base de datos msdb. Estas tablas contienen un registro de todas las copias de seguridad que se han tomado en la instancia de SQL Server desde la última vez que se borraron las tablas de historial de copia de seguridad.

Lo que respecta a las copias de seguridad propios, es una práctica recomendada para asignar un nombre a archivos de copia de seguridad para incluir la base de datos, escriba de copia de seguridad, fecha y hora para que la copia de seguridad se puede identificar un vistazo. Si no lo ha hecho, puede averiguar qué archivo de copia de seguridad contiene mediante el comando RESTORE HEADERONLY. Se mostrará el contenido del encabezado del archivo de copia de seguridad, esencialmente los metadatos que describen la copia de seguridad. Puede leer más en el tema de los libros en pantalla "Ver información acerca de copias de seguridad".

Utilizando cualquiera de los métodos, que intenta averiguar la secuencia de restauración que se va a utilizar para restaurar los datos dañados o eliminados. Una secuencia de restauración es un conjunto de copias de seguridad que deben restaurarse y el orden apropiado en la que restaurarlos. La secuencia de restauración puede ser tan simple como una sola copia de seguridad completa (de base de datos, grupo de archivos o archivo), o un conjunto complicado de completa, diferencial y copias de seguridad del registro de transacciones.

Por ejemplo, imagine un escenario donde implica la estrategia de copia de seguridad completa de la base de datos, diferencial y copias de seguridad del registro de transacciones. Si se produce un bloqueo del sistema y los archivos de datos están dañados, ¿cuál es la secuencia de restauración? Figura 1 ilustra este ejemplo.

En este caso, la secuencia de restauración más rápido y más corta es la copia de seguridad completa de la base de datos más reciente (F), la copia de seguridad diferencial más reciente (D2) y, a continuación, las posteriores copias de seguridad del registro de transacciones, hasta e incluyendo la copia de seguridad del registro cola (L7 y L8).

Uno de los problemas de difícil al planear una secuencia de restauración es encontrar la copia de seguridad del registro más temprana requerido de transacciones para restaurar (a veces se denomina encontrar la "LSN mínimo" o "mínimo-Log Sequence Number"). En el ejemplo en de figura 1, las copias de sólo seguridad del registro de transacciones L7 y L8 son necesarios, porque la copia de seguridad diferencial de la base de datos D2 aporta la base de datos a un punto más reciente en el tiempo a la transacción anterior copias de seguridad del registro.

Figura 1: Secuencia de restauración de ejemplo

SQL Server permitirá anterior, que no sean necesarias las copias de seguridad que se va a restaurar, del registro de transacciones pero no se utilizarán y recuperación de desastres sólo esencialmente residuos time.Continuing mi ejemplo, ¿qué sucedería si D2 de copia de seguridad diferencial de base de datos se ha perdido o dañado? Figura 2 muestra este caso.

Figura 2: Restaurar la secuencia con una copia de seguridad de la base de datos diferencial de daños

En este escenario, la secuencia de restauración más rápido y más corta es la copia de seguridad completa de la base de datos más reciente (F), la siguiente más reciente diferencial copia de seguridad de la base de datos (D1) y, a continuación, las posteriores copias de seguridad del registro de transacciones (L4, L5, L6, L7 y L8). Esto es posible sólo mientras las copias de seguridad D1, L4, L5 y L6 siguen estando disponibles. Es importante que no elimine las copias de seguridad demasiado pronto; de lo contrario podría experimenta problemas durante un desastre.

Por ejemplo, si la copia de seguridad completa de la base de datos F está dañado, a menos que la copia de seguridad completa de la base de datos anterior todavía está disponible, la base de datos no ser recuperable. Si se elimina la copia de seguridad diferencial de la base de datos D1 tan pronto como finaliza D2, a continuación, el escenario en de figura 2 no será posible y la secuencia de restauración implicarán todas las copias de seguridad del registro de transacciones desde la copia de seguridad completa de la base de datos--una secuencia de restauración potencialmente muy larga.

Esto provoca la pregunta de "Al debe eliminar las copias anteriores?" La respuesta es definitivamente "IT depende!" Si no tiene una obligación legal para mantener las copias de seguridad alrededor en un cierto período de tiempo, quiera y se depende de la estrategia de copia de seguridad que tiene y cuánto espacio en disco es necesario. No obstante, no eliminar inmediatamente las copias de seguridad anteriores en cuanto se toma una nueva; es mejor mantener al menos uno o dos completos ciclos de copias de seguridad antes de deshacerse de las copias de seguridad anteriores. Idealmente, debe probar las copias de seguridad antes de quitar los más antiguos.

Para las copias de seguridad del registro de transacciones, en general debe tener todas ellas desde que se realizó la última copia de seguridad completa de la base de datos, ya es la secuencia de restauración de servicios-Otoño final. Si una transacción única copia de seguridad del registro desde el registro de transacciones copia de seguridad "cadena" falta o está dañada, no puede continuar la operación de restauración más allá de la separación. Como he mencionado en el artículo anterior, comprobar la integridad de las copias de seguridad es una parte clave de poder restaurar correctamente.

Puede encontrar más detalles en averiguar lo que estás capaz de restaurar en el tema de los libros en pantalla completo"Trabajar con secuencias de restauración para bases de datos de SQL Server".

Escenarios de restauración de ejemplo

El escenario de restauración más común implica copias de una copia de seguridad completa de la base de datos, a continuación, uno o más seguridad y del registro de transacciones para poner la base de datos en tiempo. Puede hacerlo a través de SQL Server Management Studio (SSMS) o a través de Transact-SQL, aunque hay algo que debe tener en cuenta si va a utilizar RESTORE comandos directamente.

Cuando se restaura una copia de seguridad, existen tres opciones para cómo finaliza la operación de restauración y todas se relacionan con la fase UNDO de la recuperación. Como se restaura cada copia de seguridad sucesiva en la secuencia de restauración, siempre se realiza la fase REDO de la recuperación, pero no se puede realizar la fase UNDO hasta que se ha restaurado la copia de seguridad muy última en la cadena de copia de seguridad del registro de transacción. Esto es porque tan pronto como se complete la recuperación, no se pueden aplicar ninguna más copias de seguridad del registro de transacción, por lo que todos se restaura en la secuencia de restauración debe especificar que no se ejecute la fase UNDO de la recuperación.

Desgraciadamente, es el valor predeterminado ejecutar la fase UNDO de la recuperación--el equivalente de utilizar la opción WITH RECOVERY en la instrucción RESTORE. Al restaurar varias copias de seguridad, debe procurar que cada uno especifica WITH NORECOVERY. De hecho, la forma más segura es utilizar la opción WITH NORECOVERY en todas las restauraciones en la secuencia de restauración y, a continuación, completar manualmente recuperación posteriormente. Aquí es código de Transact-SQL de ejemplo para restaurar una copia de seguridad completa de la base de datos y dos copias de seguridad del registro de transacciones y, a continuación, completar manualmente la recuperación para poner la base de datos en línea:

RESTORE DATABASE DBMaint2008 FROM
DISK = 'C:\SQLskills\DBMaint2008_Full_051709_0000.bak'
CON REEMPLAZAR, SUMA DE COMPROBACIÓN, NORECOVERY;
IR

RESTORE LOG DBMaint2008 FROM
DISK = 'C:\SQLskills\DBMaint2008_Log_051709_0100.bak'
CON NORECOVERY;
IR

RESTORE LOG DBMaint2008 FROM
DISK = 'C:\SQLskills\DBMaint2008_Log_051709_0200.bak'
CON NORECOVERY;
IR

RESTORE DATABASE DBMaint2008 WITH RECOVERY;
IR

Observe que también utiliza la opción de CHECKSUM en la restauración de la copia de seguridad completa de la base de datos para asegurarse de que se comprueban las sumas de cualquier comprobación de página presentes en la base de datos que se restaura tal como se restauran.

Si no se especificó WITH NORECOVERY en la primera instrucción RESTORE, se devuelve el error siguiente:

Msj 3117, nivel 16, estado 1, línea 1
No se puede restaurar el registro o copia de seguridad diferencial porque no hay archivos están listos para la puesta al día.
Msj 3013, nivel 16, estado 1, línea 1
RESTORE LOG está finalizando anormalmente.

Debe ser muy cuidadoso al utilizar la opción de derecha, en caso contrario, corre el riesgo de tener que volver a iniciar una secuencia larga de restauración: no hay ninguna forma para deshacer recuperación una vez completada.

Sin embargo, hay una opción interesante que tipo de hace que--la opción WITH STANDBY. Éste es el último de tres opciones que he mencionado anteriormente. Funciona mediante la ejecución de la fase UNDO de la recuperación, pero mantiene una nota de lo que hizo (en un archivo cuyo nombre y ruta de acceso que especifique para "deshacer") y, a continuación, permite el acceso de sólo lectura a la base de datos. La base de datos es transaccionalmente coherente, pero tiene la posibilidad de continuar con la secuencia de restauración. Si decide continuar, se invierte el UNDO (utilizando el contenido del archivo deshacer) y, a continuación, se restaura el siguiente archivo de registro de transacciones. Esto resulta útil en dos escenarios: Para permitir el acceso de sólo lectura para una base de datos secundaria de trasvase y para consultar el contenido de la base de datos durante la secuencia de restauración.

Si la está recuperarse de desastres implica la eliminación accidental de una tabla, por ejemplo, puede que desee hacer una restauración en un momento. Hay varias maneras de hacerlo, pero el más común es donde desea restaurar la base de datos, pero asegúrese de que la recuperación no continúa más allá de un momento determinado. En ese caso puede utilizar la opción WITH STOPAT para impedir la restauración del registro de transacciones desde va pasado el tiempo que se sabe que la tabla se ha eliminado. Por ejemplo, utilizando el ejemplo de Transact-SQL anterior, si deseaba evitar que la base de datos que se va a restaurar más allá de 1: 45 a.m., podría usar la siguiente sintaxis en la segunda instrucción RESTORE LOG:

RESTORE LOG DBMaint2008 FROM
DISK = 'C:\SQLskills\DBMaint2008_Log_051709_0200.bak'
CON NORECOVERY, STOPAT = ' 2009 - 05 - 17 01:45:00.000 ';
IR

Incluso se podría combinar STOPAT y STANDBY para ver si el punto correcto que estaba en tiempo y, a continuación, si no, restaurar la misma copia de seguridad del registro de transacciones con un tiempo de unos segundos más tarde y así sucesivamente. Este tipo de operación se convierte en muy tedioso, pero puede ser la única solución si no sabe qué hora tuvo lugar una operación.

Una explicación completa de estas y otras opciones para la instrucción RESTORE puede encontrarse en el tema de los libros en pantalla"RESTORE argumentos (Transact-SQL)".

Uno de los más interesantes y nuevas características introducidas en SQL Server 2005 Enterprise Edition fue disponibilidad parcial de la base de datos. Esta característica permite una base de datos de multi-grupo de archivos estén en línea y disponible como long como al menos el grupo de archivos principal es en línea. Obviamente, no se puede tener acceso a datos en los grupos de archivos sin conexión, pero esta característica permite una base de datos muy grande para dividirse en grupos de archivos independiente de capacidad de recuperación más fácil y rápido. Otra característica de sólo Enterprise que se ha agregado es la capacidad de realizar restauraciones por etapas (por ejemplo, un solo grupo de archivos de una base de datos multi-grupo de archivos) en línea mientras se utiliza el resto de la base de datos para su procesamiento.

Estas dos características combinadas permiten algunos escenarios de restauración bastante sofisticados y eficaz, siempre que se ha creado la base de datos de ese modo y existen las copias de seguridad correctas.

Encontrará una excelente, exhaustiva SQL Server artículo técnico titulado "Microsoft SQL Server 2005 parcial Database disponibilidad" con algunos amplios ejemplos disponibles en tinyurl.com/mbpa65. También hay una grabación de 75 minutos de Kimberly l. Tripp entregar una sesión de TechEd EMEA titulada"Estrategias de recuperación y disponibilidad SQL Server 2005 VLDB"que merece la pena inspeccionando.

Consideraciones al restaurar a una ubicación diferente

El escenario de restauración más sencillo es cuando se restaura la base de datos en la misma instancia de SQL Server para que está normalmente conectada y con el mismo nombre. A medida que mueve aún más lejos de ese escenario, el aftermath de la operación de restauración se complica.

Si se restaura la base de datos en la misma instancia pero con un nombre diferente, tiene que realizar cambios en elementos como DTS y SSIS paquetes, los planes de mantenimiento de bases de datos, cadenas de aplicación y todo lo que se basa en un nombre de base de datos.

Si se restaura la base de datos en una instancia diferente en el mismo servidor, puede ser mucho más complicado:

  • Los inicios de sesión de SQL Server serán diferentes o no exista.
  • Trabajos del Agente SQL y paquetes DTS y SSIS serán diferentes o no exista.
  • La base de datos master es diferente, por lo que puede faltar ningún procedimiento almacenado definido por el usuario.
  • El nombre de instancia de SQL será diferente, por lo que puede haber problemas de conectividad de cliente.
  • Si se restaura la base de datos en una instancia en un servidor diferente, todo lo que aparece lista se aplica, pero existe se puede agregar problemas de seguridad como cuentas de Windows pueden ser diferentes y pueden estar en un dominio de Windows diferente.
  • Una otra consideración es la edición de SQL Server se restaura en la base de datos. Hay algunas características que, si se utiliza en la base de datos, que hacen que la base de datos "Enterprise-only"--no puede ser restaurada en una Standard (o inferior) instancia de SQL Server.
  • En SQL Server 2000 y versiones anteriores, no es un problema. En SQL Server 2005, si se utilizan la tabla o índice de particiones, la base de datos es "Enterprise-only." En SQL Server 2008, la lista de características es:
  • Captura de datos de cambio
  • Cifrado de datos transparente
  • Compresión de datos
  • Partición

Todas estas requieren privilegios de sysadmin para habilitar excepto compresión de datos, que puede habilitarse por el propietario de una tabla, por tanto potencialmente interrumpir un plan de recuperación de desastres que implique la restauración de una instancia de Standard Edition. Puede saber si cualquiera de estas características se utilizan en la base de datos mediante la DMV sys.dm_db_persisted_sku_features y ajustar su plan de recuperación de desastres en consecuencia.

Cavar Deeper

Igual que con el primer artículo de la serie de copias de seguridad, hay muchos aspectos de las operaciones de restauración que no disponía de espacio para tratar. Ahora que conoce los conceptos básicos, sin embargo, puede profundizar en algunos de los vínculos de los libros en pantalla y blog para obtener información más profunda. El mejor lugar para iniciar en los libros en pantalla es el tema"Restauración y recuperación Overview (SQL Server)". También puede encontrar una gran cantidad de información en mi blog, comenzando con la categoría Backup/Restore.

La principal recordar que me gustaría tener desde este artículo es que para recuperar correctamente una base de datos mediante copias de seguridad, es necesario para la práctica para asegurarse de que sabe qué hacer. No desea ser aprender la sintaxis del comando RESTORE durante una situación de recuperación de desastres high-pressure. También es posible que su estrategia de copia de seguridad no permite recuperar dentro de los requisitos empresariales. Quizá tardan mucho tiempo para restaurar las copias de seguridad, quizá las copias de seguridad del registro sobrescriban accidentalmente entre sí, o quizá ha olvidado hacer una copia de seguridad del certificado de servidor utilizado para habilitar el cifrado transparente de la base de datos en SQL Server 2008.

Con diferencia la mejor forma de prepararse para un desastre es contar con un plan de restauración que enumera los pasos para ir a través y disponer de un conjunto de secuencias de comandos que ayudará a identificar qué copias de seguridad existen y el orden en que restaurarlos. Siempre como decir que esto se debe escrito por el DBA más senior del equipo y probado el DBA más junior--para asegurarse de que todos los usuarios puedan seguir los pasos de forma segura. Sin embargo, si eres un administrador de bases de datos de un movimiento involuntario, va a necesitar elaborar un plan usted mismo y asegúrese de que puede seguir.

En el siguiente artículo, explicaré cómo recuperarse de daños en la base de datos si no dispone de las copias de seguridad y por qué puede elegir ejecutar una operación de reparación, incluso si tiene copias de seguridad.
En el tiempo medio y como siempre, si tiene cualquier comentario o pregunta, colocar me una línea-- Paul@SQLskills.com.

Gracias a Kimberly l. Tripp para proporcionar una revisión técnica de este artículo.

Paul S. Randal es el director de administración de director regional de SQLskills.com, un MVP de SQL Server y Microsoft. Trabajó en el equipo de motor de almacenamiento de SQL Server de Microsoft de 1999 a 2007. Randal escribió DBCC CHECKDB/reparación para SQL Server 2005 y fue responsable del motor de almacenamiento del núcleo durante el desarrollo de SQL Server 2008. Randal es un experto en recuperación de desastres, alta disponibilidad y mantenimiento de base de datos y un regular moderador en congresos todo el mundo. Blogs en SQLskills.com/blogs/paul y es en Twitter como @ PaulRandal.