Tener un buen plan de recuperación que asegure que los respaldos de la base de datos están siendo tomados en cuenta de manera regular y almacenados de forma segura en dispositivos de almacenamiento específicos o múltiples, incrementa grandemente la seguridad de la base de datos y las opciones de recuperación cuando un desastre o un accidente ocurren. Sin embargo, crear respaldos completos de la base de datos regularmente no provee una recuperación completa a un punto de tiempo, ya que restaurar el último respaldo completo restaurará la base de datos a un estado apropiado en el tiempo en que el respaldo fue creado, pero todos los cambios, tanto de esquema como de datos, que han ocurrido después del último respaldo completo estarán prácticamente perdidos.

Recuperación de una base de datos SQL Server con copias de seguridad del registro de transacciones

El peor escenario que un DBA puede encontrar es una corrupción del archivo de datos de la base de datos SQL Server (debido a una ocurrencia física o de otro tipo, los archivos de datos pueden ser dañados y se pueden volver inaccesibles).

En varios escenarios, una restauración a un punto de tiempo de la base de datos puede requerirse. Típicamente, las siguientes situaciones requieren este tipo de recuperación:

• Una corrupción de datos ocurrió por una acción de un usuario malicioso. Por ejemplo, un usuario o un DBA puede eliminar o actualizar el contenido de una o más tablas por error, eliminar objetos de la base de datos que aún son requeridos durante una actualización a una aplicación, o realizar un gran proceso de actualización en lote que falla.
• Un proceso de actualización de la base de datos puede ir mal o un script de actualización de la base de datos falla.
• Una recuperación completa después de un fallo de medios no puede ser realizada porque el registro de transacciones requerido y las copias de seguridad de la base de datos están perdidos.

Si alguna vez usted necesitó revertir rápidamente un cambio inadvertido como un UPDATE sin una cláusula WHERE, para recuperar los datos perdidos o corruptos, para mover los datos a través de su ambiente de desarrollo, pruebas, integración y producción o incluso sólo evitar generar un reporte usando una base de datos de SQL Server ocupada como fuente de datos, usted se ha debido preguntar si hay una manera fácil de restaurar sólo filas específicas en lugar de restaurar la copia de seguridad completa de la base de datos.

Rastrear cambios es una tarea de seguridad esencial de SQL Server. Aparte del historial de cambios, que incluye las operaciones DML (por ejemplo, INSERT, UPDATE y DELETE), el rastreo de cambios DDL en SQL Server, cambios que afectan los objetos de la base de datos, es de gran importancia también. Respecto de esto, varias técnicas pueden ser usadas como una solución de auditoría de cambios de esquema. Uno de los métodos más comunes es el de Desencadenadores DDL.

Si usted accidentalmente ejecutó una sentencia TRUNCATE y tiene una copia de seguridad completa de la base de datos, dado que ningún cambio ocurrió después de que la tabla fue truncada, usted simplemente puede recuperar los datos sobrescribiendo la base de datos original con la copia de seguridad. Sin embargo, si ese no es el caso, ya sea porque los objetos de la base de datos y los datos han sido cambiados después de que la sentencia SQL TRUNCATE.

Usted ha ejecutado accidentalmente (o ha experimentado otros escenarios de pérdida de datos que involucran) una sentencia DELETE, TRUNCATE o DROP contra una base de datos y ha perdido registros valiosos.

Cuando usted pregunta a un Administrador de Base de Datos (DBA, por sus siglas en inglés) qué característica le gustaría ver que se añada a la funcionalidad de recuperación de SQL Server, él indudablemente dirá: “La habilidad de recuperar una tabla individual de una copia de seguridad de base de datos”.

Por supuesto, es posible recuperar datos de una tabla específica de una copia de seguridad, pero usted no puede hacerlo sin restaurar la copia de seguridad entera.

¿Por qué los DBAs quieren esto? Bien, las razones son simples:

Introducción

Hay ciertas circunstancias en las que usted puede necesitar retrotraer su base de datos a un punto específico del tiempo. Pueden haber varias razones para que esto sea necesario, pero usualmente está relacionado a la ejecución accidental o maliciosa de sentencias DML o DDL. Por ejemplo:

Recuperar registros ELIMINADOS es algo que todo quisiéramos evadir, pero no importa cuán cuidadosos somos, puede suceder. Tener copias regulares de seguridad de bases de datos y registros de transacciones es una práctica necesaria y una gran ventaja en esta situación, pero incluso entonces, recuperar los registros eliminados puede no ser fácil.

¿Cómo recuperar una base de datos SQL Server usando una copia de seguridad antigua y el archivo del registro de transacciones actual? Los Administradores de Bases de Datos tienen varios planes de recuperación de desastres. Una de las preguntas que deben responder antes de establecer un plan correcto es cuántos datos pueden permitirse perder. Muchos de los “Administradores de Bases de Datos accidentales” cobran consciencia de que crear copias de seguridad completas regularmente puede no ser suficiente, sólo después de que es demasiado tarde.

Incluso tomando todas las precauciones, percances con su base de datos aún son una posibilidad. Aunque usted esté preparado para un desastre – su base de datos está en un modelo de recuperación completo y usted crea copias de seguridad del registro de transacciones y la base de datos regularmente, aún hay algunas situaciones cuando un problema no puede ser resuelto usando una solución ya disponible por defecto.

Uno de estos problemas es restaurar un solo objeto. No es inusual eliminar un objeto de base de datos SQL (por ejemplo, un procedimiento almacenado) que aún es necesitado, o modificarlo cuando la versión antigua pueda ser requerida después.

¿Qué es una inyección SQL?

Un ataque de inyección SQL es un ataque en el cual un código que ataca la base de datos es insertado en el sitio web. Es uno de los tipos más comunes de vulnerabilidades de seguridad de aplicaciones web. Así que es mejor estar preparado, o al menos informado. Las inyecciones SQL pueden tener un efecto inmediato (ataques de primer orden) o retardado (ataques de segundo orden).

“Borré/actualicé registros importantes por error en una tabla de SQL Server. ¿Hay alguna forma de recuperar esto registros?”

Esta es una pregunta frecuente, y muy a menudo un dolor de cabeza para los Administradores de Bases de Datos. SI ellos son cuidadosos y hacen copias de seguridad de la base de datos regularmente, ellos pueden recuperar los datos perdidos de la base de datos incluso donde el modelo de recuperación SIMPLE es usado.

SI ese es el caso, entonces las copias de seguridad de la base de datos son la única solución para recuperar los datos perdidos de la base de datos. Los datos eliminados tienen que ser de un periodo previo a la creación de la copia de seguridad de la base de datos.

Independientemente de las precauciones tomadas para proteger su Servidor SQL, los accidentes aún pueden suceder, causando serias consecuencias como pérdida de datos y objetos. Ahora analizaremos dos posibles maneras de recuperar objetos SQL – vistas, procedimientos almacenados y desencadenadores, perdidos debido al uso accidental de una sentencia DROP.

Una tabla accidentalmente borrada puede ser recuperada de muchas maneras. La elección de la técnica depende de los recursos disponibles para la recuperación. La primera elección es usualmente una copia de seguridad de la base de datos. Pero incluso si usted tiene una, la tabla borrada puede ser aún recuperada (en algunos casos incluso más rápidamente que con una copia de seguridad).

Si usted accidentalmente ejecutó una declaración DROP y tiene una copia de seguridad completa de la base de datos, dado que no ocurrieron cambios después de que la tabla fuera eliminada, usted simplemente puede recuperar los datos sobrescribiendo la base de datos original con la copia de seguridad. De todas maneras, si ese no es el caso, ya sea porque los objetos de la base de datos han sido cambiados después de la declaración DROP fuera ejecutada o porque no tiene una copia de seguridad válida de la base de datos, aún hay una manera de recuperar todos los datos perdidos.

Los registros de transacciones de SQL Server contienen entradas que describen los cambios hechos a la base de datos. Ellos guardan suficiente información para recuperar la base de datos a un punto de tiempo específico, para reproducir o deshacer un cambio. Pero, ¿cómo ver qué hay en ellos, encontrar una transacción específica, ver qué ha pasado y revertir los cambios como recuperar accidentalmente entradas eliminadas?

Cada base de datos SQL Server está mapeada sobre un conjunto de archivos del sistema operativo. Estos archivos guardan datos e información de registro. Archivos individuales son usados sólo por una base de datos, y los datos y la información de registro nunca son mezclados en el mismo archivo. Mientras los datos son almacenados en un archivo MDF, todas las transacciones y las modificaciones a la base de datos SQL Server hechos por cada transacción son almacenadas en un archivo LDF – un archivo de registro de transacciones que es un componente esencial de la base de datos. Conceptualmente, el archivo de registro es una cadena de entradas de registro. Físicamente, las entradas de registro son almacenadas en uno o el conjunto de archivos LDF físicos que implementan el registro de transacciones.