Para prevenir pérdidas accidentales de datos, siempre es bueno asegurarse de que hay una solución de recuperación de desastres disponible. Esto puede ser fácilmente logrado teniendo una copia fija de la base de datos primaria en otra instancia de SQL Server, lo cual puede ser logrado vía el transvase de registros.

El transvase de registros es una solución que provee una protección de recuperación de desastre al nivel de la base de datos. Una configuración de transvase de registros incluye un servidor primario hospedando a una base de datos en línea, y uno o más servidores secundarios que hospedan copias de la base de datos. El proceso es bastante simple – una base de datos es respaldada y restaurada desde un servidor primario a un servidor secundario. En intervalos programados regularmente, una copia de seguridad de registros de transacciones es realizada en los servidores primario y secundario para mantener las bases de datos en sincronización.

Introducción

Correr y mantener múltiples instancias de SQL Server puede ser a menudo un desafío formidable, especialmente si estas instancias corren e múltiples servidores. Es suficientemente fácil configurar un trabajo de SQL Server Agent para cada servidor para automatizar las copias de seguridad, pero ¿qué pasa si hay 20, 30 o 100 servidores que necesitan mantenimiento? En este escenario, configurar agentes en cada servidor tomaría demasiado tiempo, y monitorear la configuración entera sería una pesadilla para cualquier administrador. Por supuesto, Hay muchas soluciones para este escenario:

Introducción

Una de las principales tareas de cada administrador de base de datos es crear un plan de recuperación de desastres confiable. El plan siempre incluye varias operaciones de copia de seguridad y restauración. Por lo general, optar sólo por copias de seguridad convencionales de archivos debería ser suficiente, pero en algunos casos, los recursos como el espacio en disco, tiempo de copia de seguridad, o ambos podrían ser el problema. Este suele ser el caso cuando se trabaja con grandes bases de datos.

Una de las tareas más importantes para cualquier administrador de bases de datos es crear un plan de recuperación de desastres a prueba de tontos. Este plan usualmente incluye múltiples operaciones de restauración y respaldo. La mayor parte del tiempo, optar por copias de seguridad convencionales debería ser suficiente, pero en algunos casos, almacenar todas las copias de seguridad en un solo dispositivo puede ser una mala idea. A medida que las bases de datos crecen en el tiempo, las copias de seguridad de vuelven más grandes y los dispositivos de respaldo menos estables debido a las frecuentes operaciones de lectura/escritura. Si el dispositivo de respaldo falla, todo los datos respaldados pueden ser perdidos. Para evitar este escenario, algunos administradores toman múltiples copias de sus archivos de respaldo, y los almacenan en diferentes dispositivos de respaldo. Hay unas cuantas maneras de hacer esto:

Introducción

Al trabajar con un gran número de bases de datos en varios servidores SQL, la creación de un plan de recuperación ante desastres imbatible puede ser un reto. Estrategias bien organizadas de copia de seguridad y restauración definitivamente ayudarán con esto. Con el fin de implementar estas estrategias con éxito en un entorno más amplio, establecer copias de seguridad y procesos de restauración automatizados es una necesidad. Algunos administradores de bases de datos utilizan los scripts de lotes o de PowerShell para la automatización, mientras que otros prefieren utilizar diversas soluciones de terceros. En ambos casos, es necesario dar formato a los nombres de las copias de seguridad de la base de datos correctamente. Los nombres de copia de seguridad correctamente formateados facilitan mucho el trabajo de organización y mantenimiento de los conjuntos de copias de seguridad. Los archivos de copia de seguridad antiguos suelen ser obsoletos y se pueden identificar y eliminar fácilmente de la unidad de forma manual o mediante un script.

¿Qué es una restauración por etapas?

Las restauraciones por etapas le permiten al usuario restaurar sólo grupos de archivos específicos de una base de datos en lugar de restaurar una base de datos completa. En casos de emergencia lo importante es obtener los datos necesarios tan pronto como sea posible, y restaurar el resto de los datos más tarde, mientras se dispone de los datos más importantes en línea. Este enfoque minimiza el tiempo de inactividad cuando ocurre un desastre.

SQL Server almacena un historial completo de todas las operaciones de restauración y respaldo de SQL, y otras actividades históricas como Correo Electrónico de la Base de Datos, Trabajos, Transvase del Registro, Políticas, Planes de Mantenimiento, etc. en una instancia de servidor en la base de datos msdb.

De tiempo en tiempo, los DBAs se encuentran en una situación donde una base de datos SQL Server se vuelve muy grande para su ambiente de producción y necesita ser reducida en tamaño para liberar espacio y asignarlo de vuelta al sistema.

Antes de reducir una base de datos SQL Server o archivos de bases de datos, es muy importante entender cómo funciona el proceso y cuáles son las consecuencias inmediatas del proceso de reducción.

Las copias de seguridad son un punto de partida para cualquier estrategia seria de recuperación de desastres. Crear copias de seguridad de la base de datos SQL regularmente es sólo el primer paso. Igualmente importante es asegurarse de que también son confiables y restaurables. Esta es la única manera de evadir sorpresas desagradables en el caso de un desastre.

El propósito del índice de SQL Server es básicamente el mismo que su pariente lejano – el índice de libros – le permite llegar a la información rápidamente, pero en lugar de navegar en un libro, indexa una base de datos SQL Server.

Una base de datos es una de las partes más importantes de cada sistema de información y, por tanto, frecuentemente es un objetivo de los hackers. La encriptación es un proceso de ofuscar los datos con el uso de una clave y/o contraseña haciendo los datos ininteligibles a cualquiera sin la clave de des encriptación correspondiente o la contraseña.

Cuando un desastre ocurre, la única cosa más frustrante que no tener una copia de seguridad actualizada y relevante de la base de datos, es tener una copia de seguridad corrupta. Cuando usted crea el archivo de copia de seguridad al principio, este debería ser bueno, con ‘debería’ siendo la palabra clave. Cada vez que un archivo es copiado a otra localización, hay un riesgo de corrupción del archivo. Una manera de asegurar que el archivo es aún usable es restaurar la copia de seguridad en sí misma, y correr DBCC CHECKDB inmediatamente contra la base de datos SQL restaurada recientemente.

Tener un buen plan de respaldo y restauración es una parte importante de una estrategia de recuperación de desastres. Este artículo describirá 3 diferentes soluciones/enfoques para crear una copia de seguridad programada en SQL Server.

Como una parte de la estrategia de respaldos, muchos tipos de copias de seguridad pueden ser usadas juntas.

Cuando se está recuperando de una falla de base de datos SQL Server, un administrador de base de datos necesita restaurar un conjunto de copias de seguridad SQL Server en una secuencia correcta y significativa. Con esto en mente, el objetivo es diseñar una estrategia de recuperación de desastres creando un plan de copias de seguridad sólido, así como un plan apropiado de restauración de bases de datos en SQL Server. Este artículo describirá 2 diferentes soluciones para creat y programar una restauración de base de datos en SQL Server.

Este artículo explica cómo crear grupos de archivos y mover índices a un diferente grupo de archivos, y cómo crear una copia de seguridad de base de datos sin índices con el propósito de reducir la cantidad de datos requeridos para realizar copias de seguridad, por tanto reduciendo el tiempo de la creación del respaldo y el espacio requerido.

Una de las maneras más comunes de asegurar que una recuperación será posible si ocurre una corrupción de datos o cualquier otro desastre es crear un plan de recuperación para este escenario. Los planes de recuperación más populares incluyen la creación regular de copias de seguridad de bases de datos, las cuales pueden ser usadas posteriormente para restaurar una base de datos al punto de tiempo más cercano, previo al desastre.

Para crear y aplicar un plan de recuperación exitoso, es importante crear un programa de copias de seguridad sólido y administrar copias de seguridad de múltiples bases de datos a través de diferentes instancias SQL Server.

¿Por qué correr DBCC CHECKDB?

DBCC CHECKDB revisa la integridad lógica y física de todos los objetos en una base de datos y provee información de cualquier corrupción.

Como correr DBCC CHECKDB es una tarea exhaustiva en recursos es recomendado correrlo en un servidor de producción cuando haya tan poco tráfico como sea posible, o incluso mejor, una de las maneras de acelerar el proceso DBCC CHECKDB es transferir el trabajo a un servidor diferente automatizando un proceso y corriendo CHECKDB después de una restauración de base de datos. Como el proceso de respaldo es una copia de una base de datos y una base de datos restaurada será exactamente la misma que una base de datos en línea y una base de datos restaurada será exactamente la misma que una en línea, por lo tanto si hubiera alguna inconsistencia o problema, estará en la copia de seguridad, y será encontrado en una restauración. Usando este enfoque ambas restauraciones serán probadas y las copias de seguridad verificadas sin ningún impacto en una base de datos de producción.

Si la restauración de una base de datos original a un estado previo no es una opción, en el caso de datos accidentalmente actualizados, eliminados, borrados o dañados, aún es posible restaurar estas tablas si la copia de seguridad de la base de datos fue creada previamente al accidente.