Compartir vía

Copias de seguridad de registros de transacciones (SQL Server)

  • Artículo

Se aplica a: SQL Server

Este artículo solamente es aplicable a las bases de datos de SQL Server que utilizan el modelo de recuperación optimizado para cargas masivas de registros o el modelo de recuperación completa. En este artículo se describe cómo se realizan copias de seguridad del registro de transacciones de una base de datos de SQL Server.

Como mínimo, debe haber creado al menos una copia de seguridad completa antes de poder generar una copia de seguridad de registros. A continuación, la copia de seguridad del registro de transacciones se podrá crear en cualquier momento, a menos que ya se haya realizado previamente.

Se recomienda realizar copias de seguridad de registros con frecuencia para minimizar el riesgo de pérdida de trabajo y el truncamiento del registro de transacciones.

Un administrador de bases de datos normalmente crea una copia de seguridad completa de la base de datos, por ejemplo, semanalmente; si lo desea, también puede crear una serie de copias de seguridad diferenciales de la base de datos a intervalos más cortos, por ejemplo, a diario. Con independencia de las copias de seguridad de la base de datos, el administrador de la base de datos hace copias de seguridad del registro de transacciones cada poco tiempo. En el caso de un tipo de copia de seguridad concreto, el intervalo óptimo dependerá de diversos factores, como la importancia de los datos, el tamaño de la base de datos y la carga de trabajo del servidor. Para obtener más información sobre cómo implementar una buena estrategia, consulta Recomendaciones en este artículo.

Cómo funciona una secuencia de copias de seguridad de registros

La secuencia de las copias de seguridad del registro de transacciones ( cadena de registros ) es independiente de las copias de seguridad de los datos. Por ejemplo, suponga la siguiente secuencia de eventos.

Time Evento
8:00 a.m. Copia de seguridad de la base de datos.
Mediodía Copia de seguridad del registro de transacciones.
4:00 p.m. Copia de seguridad del registro de transacciones.
18:00 Copia de seguridad de la base de datos.
20:00 Copia de seguridad del registro de transacciones.

La copia de seguridad del registro de transacciones creada a las 8:00 p. m. contiene registros de registro de transacciones de 4:00 p. m. a 8:00 p. m., que abarca el tiempo en que se creó la copia de seguridad completa de la base de datos a las 6:00 p. m. La secuencia de copias de seguridad de registros de transacciones es continua desde la primera copia de seguridad de base de datos completa a la última copia de seguridad de registro de transacciones, creada a las 8:00 a. m. Para más información sobre cómo aplicar estas copias de seguridad de registros, vea el ejemplo de Aplicar copias de seguridad del registro de transacciones (SQL Server).

Recomendaciones

Si el registro de transacciones resulta dañado, perderá el trabajo realizado desde la última copia de seguridad válida. Por tanto, le recomendamos encarecidamente que sitúe los archivos de registro en un almacenamiento con tolerancia a errores.

Si una base de datos se daña o se va a restaurar, se recomienda crear una copia del final del registro para que puedas restaurar la base de datos hasta el momento actual.

Precaución

Problema conocido: en el caso de las bases de datos con tablas optimizadas para memoria, realizar una copia de seguridad del registro transaccional sin recuperación y, posteriormente, ejecutar una restauración del registro de transacciones con recuperación, puede dar lugar a un proceso de restauración de base de datos que no responde. Este problema también puede afectar a la funcionalidad de trasvase de registros. Para solucionar este problema, se puede reiniciar la instancia de SQL Server antes de iniciar el proceso de restauración.

De forma predeterminada, cada operación de copia de seguridad correcta agrega una entrada en el registro de errores de SQL Server y en el registro de eventos del sistema. Si se hace una copia de seguridad del registro de transacciones con frecuencia, estos mensajes que indican la corrección de la operación pueden acumularse rápidamente, con lo que se crean registros de errores muy grandes que pueden dificultar la búsqueda de otros mensajes. En esos casos, puedes suprimir estas entradas de registro usando la marca de seguimiento 3226 si ninguno de los scripts depende de esas entradas. Para obtener más información, vea Marcas de seguimiento (Transact-SQL).

Realice copias de seguridad de registros suficientemente regulares para ajustarse a los requisitos de la empresa, específicamente a la tolerancia a la pérdida de trabajo que un almacenamiento de registro dañado podría provocar.

  • La frecuencia adecuada para realizar copias de seguridad de registros varía en función de la tolerancia al riesgo de pérdida de trabajo y, por otra parte, de la cantidad de copias de seguridad de registros que puede almacenar, administrar y, potencialmente, restaurar. Tenga en cuenta los objetivos de tiempo de recuperación (RTO) y los objetivos de punto de recuperación (RPO) necesarios al implementar la estrategia de recuperación, específicamente el ritmo de realización de copias de seguridad de registros.

  • Una copia de seguridad de registros cada 15 ó 30 minutos puede ser suficiente. Si su empresa necesita minimizar el riesgo de pérdida de trabajo, piense en la posibilidad de realizar copias de seguridad de registros más frecuentemente. La existencia de copias de seguridad más frecuentes de los registros tiene la ventaja añadida de aumentar la frecuencia de truncamiento del registro, lo que genera archivos de registro menores.

Importante

Para limitar el número de copias de seguridad del registro que necesita restaurar, es esencial que realice una copia de seguridad de sus datos periódicamente. Por ejemplo, podría programar una copia de seguridad completa de la base de datos cada semana y copias de seguridad diferenciales de la base de datos a diario.
Una vez más, tenga en cuenta los RTO y RPO necesarios al implementar la estrategia de recuperación, específicamente el ritmo de realización de copias de seguridad de base de datos completas y diferenciales.

Contenido relacionado