¿Por qué es tan importante hacer una copia de seguridad de su registro de transacciones?

Actualmente estamos implementando una solución de respaldo para un cliente y su solución ERP utiliza SQL Server.

La solución ERP fue creada por una compañía diferente. Y que me dicen que es muy importante para copia de seguridad y truncar el registro de transacciones.

He estado leyendo un poco sobre este registro de transacciones y no entiendo por qué esto es tan importante cuando ya estoy haciendo una copia de seguridad de toda la máquina de todos modos (estamos usando ArcServe UDP, que conoce SQL Server y utiliza VSS). Tengo entendido que las tareas de limpieza en la VM de SQL Server ya se están encargando de truncar el registro, sin embargo, UDP también permite el truncamiento del registro de SQL Server.

Entiendo que el registro de transacciones se puede usar para restaurar bases de datos corruptas, porque, bueno, es un registro de todas las transacciones. Pero ya tengo una copia de seguridad por hora de toda la base de datos, entonces, ¿por qué me importaría?

Solo tiene que hacer esto si su Modo de recuperación de base de datos está configurado como "lleno". Si está configurado en "simple", no tiene que hacer una copia de seguridad del registro de transacciones. ¡Pero ten cuidado con la diferencia entre estas dos opciones!

En primer lugar: si desea poder restaurar la base de datos a un punto específico de tiempo , debe usar el modo "completo". (Creo que puede ajustar el tiempo de manera tan precisa que incluso puede especificar los milisegundos para el punto de restauración) En el modo "simple" solo puede volver a la última copia de seguridad completa .

Si no hace una copia de seguridad / trunca su registro de transacciones, crecerá todo el tiempo (en modo completo). Vi bases de datos donde el archivo .trn era más del doble de grande que la base de datos en sí. Esto depende de con qué frecuencia se realizaron cambios en la base de datos.

Otro punto es que una copia de seguridad de registro es normalmente más rápida que una copia de seguridad completa.

Así que creo que su plan de respaldo para hacer un respaldo completo cada hora no es óptimo. Pero depende de tu situación:

Si dice: De acuerdo, si puedo restaurar el DB a la última hora completa, todo está bien. -> También puede pensar en configurar el modo de recuperación en "simple" si desea mantener la copia de seguridad completa cada hora.

En mi opinión, una mejor idea sería hacer una copia de seguridad completa temprano en la mañana y luego hacer una copia de seguridad del registro de transacciones cada hora. Debería ser mucho más rápido y puede restaurar en cualquier momento que desee. Y también su archivo .trn no crecerá demasiado ...

Espero que esto ayude.

Bien. Le importa porque si tiene su modelo de recuperación configurado en su totalidad y no realiza una copia de seguridad del Registro de transacciones utilizando la copia de seguridad de SQL (y no la copia de seguridad del servidor), el registro de transacciones continúa creciendo hasta que consume todo el espacio disponible en el disco. (Una vez vi a un colega menor instalar SQL Server en la unidad del sistema y nunca hacer una copia de seguridad del registro de transacciones. Se comió Windows ).

Sí, también se restaurará a un punto específico en el tiempo. Hasta el minuto. Como Twinkles dice, sí, gente tirando mesas y cosas así.

No sé qué está utilizando para su copia de seguridad por hora de toda la base de datos, y si es el mismo producto que está utilizando para toda la máquina. Si es así, no se admite una solución de copia de seguridad que no sea compatible con SQL para las restauraciones. La cantidad de tiempo que le lleva a VSS copiar los archivos MDF y LDF puede causar una discrepancia de marca de tiempo interna, por ejemplo.

También gestionamos varios sistemas ERP. Y el problema a menudo es que por la noche a menudo hay trabajos por lotes de larga ejecución que sincronizan datos con otros sistemas. Y a veces tardan una hora o más. Entonces, lo que desea hacer en caso de un choque es saltar a un punto donde tenga datos consistentes. (Lo que significa justo entre dos trabajos por lotes). Si solo mira la hora, es posible que no siempre sepa exactamente cuál era el estado de la base de datos en este momento.

Pero, por supuesto, depende de la situación. Si no tiene ningún trabajo automatizado, etc., puede estar totalmente bien con una copia de seguridad por hora.

Hay varias razones por las que quieres hacer eso:

1. Un sistema de base de datos generalmente está ocupado, tal vez haciendo miles de transacciones por segundo. Los datos podrían distribuirse en varios archivos en diferentes sistemas de archivos. No es trivial asegurarse de que la base de datos esté en un estado consistente (también conocido como utilizable) después de la restauración. Si su solución de respaldo está a la altura, excelente, pero es mejor estar seguro de esto antes de apostar su trabajo.
2. Un ejemplo: alguien deja caer una tabla con datos importantes por error. Si tiene una copia de seguridad de la base de datos con capacidad de recuperación en un punto en el tiempo, puede restaurar los datos rápidamente, sin tener que restaurar todo el sistema.
3. Si la base de datos está en modo de recuperación completa, el registro de transacciones de SQL Server crecerá. El espacio de almacenamiento en el registro de transacciones solo se reutiliza si se ha realizado una copia de seguridad del registro de transacciones. Si no realiza una copia de seguridad del registro de transacciones regularmente, su sistema de archivos se llenará hasta que no quede espacio. En ese momento, todo se detendrá de inmediato , ya que no se pueden iniciar nuevas transacciones.

Cuando su base de datos crece más allá de lo que puede respaldar en una hora, necesita un modelo diferente.

Una copia de seguridad completa de su base de datos truncará sus registros, pero debe ser "consciente de SQL", porque en ese escenario, es el software de copia de seguridad el que le dice al servidor SQL qué ha copiado y qué debe truncar.

Como otros mencionan, si tiene una base de datos en el modelo de recuperación "Completo", su registro de transacciones crecerá indefinidamente, hasta que realice una copia de seguridad completa compatible con SQL.

La recuperación es realmente el problema aquí, no la copia de seguridad. ¡Y no es una decisión técnica, es una decisión comercial!

Si los dueños de su negocio están de acuerdo con perder una hora o más de sus transacciones de la base de datos (¡lo cual puede ser MUY difícil o imposible de rehacer!), Entonces su modelo funciona. Si están de acuerdo con que el sistema esté inactivo durante horas mientras restaura toda la base de datos desde la copia de seguridad, entonces su modelo funciona.

Sin embargo, si su empresa considera su sistema ERP como un activo crítico para su operación (¿no lo hacen todos?), Establecer un tiempo de recuperación máximo aceptable (también conocido como RTO, objetivo del tiempo de recuperación) para sus servicios críticos será una decisión comercial.

Además, los propietarios de negocios o partes interesadas del sistema deben definir la cantidad de datos que están dispuestos a arriesgarse a perder en un incidente, también conocido como RPO (Objetivo del punto de recuperación).

La respuesta si los pregunta podría ser "¡NO se pueden perder datos! ¡El sistema ERP debe estar disponible las 24 horas, los 7 días de la semana, los 365 días del año!" ... lo cual todos sabemos es muy poco probable que sea rentable. Si les presenta el costo asociado con la construcción de un sistema tan redundante y sin interrupciones, obtendrán una cifra más razonable ...;)

El punto es que si puede evitar perder cualquier transacción, está ahorrando a su negocio potencialmente cientos o miles de horas de trabajo perdidas. Se trata de enormes ahorros en cualquier empresa, y crece con el tamaño de su empresa ...

Todos tuvieron excelentes respuestas a esto, pero me gustaría agregar otra nota importante ... o dos.

Conocer los detalles de los modelos de recuperación de SQL Server y sus requisitos comerciales para la pérdida de datos son muy importantes; sin embargo, en este caso es imperativo que comprenda cómo funciona su producto de respaldo con SQL Server. (Según los comentarios anteriores, parece que está haciendo una copia de seguridad de los volúmenes de disco a través de la copia VSS, lo que significa que las copias de seguridad de SQL Server pueden o no ser necesarias).

Después de evaluar recientemente un producto similar, algunos de los puntos importantes sobre los que puede tener que preguntar son:

• ¿Cómo se realizan las restauraciones a un punto en el tiempo para una base de datos en recuperación completa?
• ¿Cómo se maneja la copia de seguridad inicial para una nueva base de datos en recuperación completa?
• ¿El producto de copia de seguridad requiere copias de seguridad del registro de SQL Server para restaurar a un punto en el tiempo? (En mi caso, la respuesta fue sí).
• ¿Puede su infraestructura de almacenamiento manejar el volumen de datos para las copias / diferenciales de VSS (en un intervalo dado) además de la carga SQL normal?

Espero que esto sea útil.

La experiencia que mi equipo tuvo con nuestra evaluación reciente proporcionó algunas respuestas muy interesantes a las preguntas anteriores. Una cosa es segura, las copias de seguridad son más complejas para nosotros con un producto de copia de seguridad VSS.

Como muchos otros ya han dicho, si está utilizando una herramienta de terceros para hacer una copia de seguridad / instantánea de la VM o el almacenamiento, aún corre el riesgo de no tener una copia de seguridad válida. Todas las herramientas de terceros que administran las copias de seguridad de SQL Server se implementarán y se conectarán a SQL Server mediante VSS. Hace esto para solicitar que SQL Server inmovilice todas las E / S en los archivos de datos para que se pueda tomar una instantánea consistente. Si no es así, puede tener muchas transacciones en varios estados y una restauración no sabrá si esas transacciones pueden avanzar o retroceder.

No he trabajado con herramientas de instantáneas de VM / Storage de terceros, pero las que he trabajado nunca pudieron almacenar instantáneas donde se encontraban las bases de datos del sistema; SQL Server no puede detener esas bases de datos. TODOS hicieron una copia de seguridad de esas bases de datos de manera fluida, es decir ... emitieron los comandos BACKUP DATABASE y luego tomaron el archivo de copia de seguridad.

Además de todo eso, como muchos también han dicho, si está en el modelo de recuperación COMPLETO y no emite sentencias BACKUP LOG regularmente, el registro de transacciones continuará creciendo hasta que no quede espacio en el disco.

La verdadera pregunta que debe hacerse, y podría haberla pasado por alto ... ¿ha recuperado con éxito de estas copias de seguridad varias veces y está satisfecho con la coherencia de los datos en esas restauraciones? Personalmente, incluso eso no sería suficiente para mí, todavía se siente como un tiro de dados, y eso es algo que un buen DBA nunca toma cuando se trata de respaldo y recuperación.

Reconozca que los registros de transacciones no son simplemente un mecanismo de recuperación. El mantenimiento adecuado del registro también puede desempeñar un papel fundamental en el rendimiento general de la base de datos (es decir, el rendimiento de la transacción).

Hacer copias de seguridad de sus archivos de registro con frecuencia hace un par de cosas:

1. Reduce el recuento de VLF en los archivos de registro físicos, lo que es bueno para el rendimiento.
2. Está mejor preparado para usar las copias de seguridad de registros en caso de que necesite recuperar una base de datos.
3. Es bastante más rápido que una copia de seguridad completa

Si puede salirse con la suya haciendo una copia de seguridad completa cada hora, entonces no estoy seguro de cuánto se beneficiaría de las copias de seguridad de registros más frecuentes. Después de todo, según tengo entendido, una copia de seguridad completa también hará una copia de seguridad de la mayor parte del registro que sea necesario para garantizar una restauración completa.

Por otro lado, si su aplicación genera toneladas de transacciones entre sus copias de seguridad completas por hora, eso podría explicar por qué los desarrolladores originales sugirieron un mantenimiento de registro más granular. Muchas transacciones podrían aumentar el recuento de VLF en sus registros, lo que puede incurrir en una penalización de rendimiento hasta que el registro se trunca. He visto esto expresado como un error de 'tiempo de espera de consulta caducado' dentro de una aplicación (poco antes de que se cuelgue).

Las recomendaciones relacionadas con el mantenimiento del registro de transacciones se describen muy bien en este artículo 8 Pasos para mejorar el rendimiento del registro de transacciones . Además, este artículo, Sugerencias principales para un mantenimiento eficaz de la base de datos, menciona un recuento de VLF algo arbitrario para alcanzar (<200), que me ha funcionado muy bien.

Otras personas ya han dado la mayoría de las razones para una copia de seguridad de translog, etc. Parece haber algunas dudas sobre por qué esta es una buena estrategia cuando ya hace una copia de seguridad del servidor.

Me han surgido un par de buenas razones que no están arriba. ¿Qué sucede si su aplicación de terceros no puede realizar una copia de seguridad que pueda restaurar? ¿Has intentado restaurar tu copia de seguridad? ¿Qué pasa con un nuevo servidor que acaba de construir a partir de sus plantillas (piense en DR)? ¿Qué pasa con otro servidor en su dominio que tiene una clasificación diferente? o instancia de SQL?

Tomo copias de seguridad redundantes sin otro motivo que a veces su aplicación de terceros no es la forma más rápida de restaurar. A veces, el almacenamiento en el que está guardando su aplicación de terceros también se ve afectado o está dañado por sus propios motivos.