SQL Server Transaction Backups vs Logs

Heredé una base de datos SQL Server 2008 crítica para empresas de tamaño moderado y estoy tratando de entender la planificación de copias de seguridad. (Soy un desarrollador, no un DBA).

La forma en que nuestro sistema está configurado en este momento hay dos sistemas de respaldo:

1. Copias de seguridad completas semanales ( .bak) y copias de seguridad de transacciones ( .trn) por hora . Mantenemos varios conjuntos de estas copias de seguridad y se envían regularmente fuera del sitio.
2. Registros de SQL Server ( .ldf), con el modelo de recuperación establecido en Full. Este archivo está en una unidad separada del .mdfarchivo principal , pero por lo demás no tiene copia de seguridad.

En el caso de una restauración de emergencia (o al restaurar copias de seguridad en una máquina de desarrollo), mi procedimiento es usar los .bakarchivos y luego aplicar los archivos .trn. Tenemos un script que hace que este procedimiento sea relativamente sencillo.

Mis preguntas:

1. ¿Es posible restaurar la base de datos del .ldfarchivo? ¿Para qué es eso?
2. ¿Es innecesariamente redundante tener ambos registros de transacciones?
3. ¿Es importante hacer una copia de seguridad del .ldfarchivo?

No, no es posible restaurar una base de datos desde un archivo ldf. El archivo ldf se restauraría junto con los archivos mdf.

No, no es redundante ya que tienen dos propósitos diferentes.

Es importante realizar copias de seguridad completas y copias de seguridad del registro de transacciones. Solo tener una copia del archivo ldf no le ayuda a restaurar la base de datos.

En cuanto a para qué sirve un archivo ldf, el ldf es el registro de transacciones. Piense en ello como un búfer circular que registra los cambios en su base de datos. Cuando actualiza una fila, el cambio se escribe inmediatamente en el ldf. En algún momento en el futuro (generalmente menos de cinco minutos), los datos modificados se escriben en el archivo mdf.

Si el servidor se bloqueó o hubo una falla de energía, cuando se inicia SQL, lee el ldf y vuelve a aplicar (REDO) esos cambios.

Además, si tiene una transacción que no se ha confirmado y el servidor se bloquea, todos los cambios realizados por esa transacción deben deshacerse para que la base de datos sea coherente. El archivo ldf también tiene esa tarea. (DESHACER)

Mencioné anteriormente que el archivo ldf es circular. Al realizar una copia de seguridad del registro de transacciones (.trn), se copia una parte del archivo ldf. Después de crear un archivo trn de forma segura, sql puede reutilizar esa parte del archivo ldf. La serie de copias de seguridad trn crea una cadena que, en conjunto, registra cada modificación realizada en la base de datos. Por supuesto, si nunca realizó una copia de seguridad del registro de transacciones, el archivo ldf crecería y crecería y crecería.

En un escenario de desastre, la restauración de la copia de seguridad completa le proporciona una copia de la base de datos en el momento en que finalizó la copia de seguridad completa. A continuación, puede restaurar los archivos trn en orden y actualizar la base de datos en cualquier momento, incluida la última copia de seguridad trn.

Estoy pasando por alto algunos detalles importantes, pero lo esencial es que ldf es un archivo de trabajo que registra los cambios recientes en la base de datos. Los archivos trn son copias de partes del ldf hechas bajo el supuesto de que las mantendrá a salvo para que sql pueda reutilizar el espacio en el ldf y si ocurre un desastre, los tendrá en una ubicación alternativa.