Comprender el impacto / riesgo de desactivar "verificar la integridad de la copia de seguridad" en la copia de seguridad SQL

Actualmente utilizamos planes de mantenimiento estándar para las copias de seguridad en los servidores SQL Server 2005/2008 / 2008R2 / 2012 en nuestro entorno, y la casilla "Verificar integridad de la copia de seguridad" siempre se ha marcado.

Algunas de las copias de seguridad duran mucho tiempo, por lo que he recomendado desactivar esa opción, pero la administración necesita que documente el impacto y los riesgos de este cambio.

Entiendo el uso y el historial de esta opción, simplemente me parece innecesario duplicar el tiempo para la tarea de respaldo cuando (en mi opinión), cualquier error que pueda ocurrir ocurriría durante el paso de respaldo , no durante la verificación.

¿Me equivoco? ¿Es un riesgo mínimo desactivar esto si estoy haciendo una copia de seguridad en el disco y no en una cinta de transmisión o algo así? (Realizamos una copia de seguridad a través de la red en un dispositivo de respaldo EMC DD-800, si es relevante).

¿Hay alguna recomendación oficial de MS sobre cuándo es seguro desactivar esto?

¿Ejecutas "verificar" en cada copia de seguridad de tu entorno? ¿Los revisas al azar?

EDITAR : Para aclarar, cuando marca "verificar integridad de copia de seguridad" en el plan de mantenimiento, SQL realizará una RESTAURACIÓN VERIFICA completa en cada base de datos inmediatamente después de cada copia de seguridad. Esto es tan intensivo en datos / IO como la copia de seguridad original, y (básicamente) duplica el tiempo total del trabajo de copia de seguridad. Esto no es lo mismo que habilitar la opción de "suma de comprobación" en la copia de seguridad (que no puedo hacer en el asistente, que yo sepa).

¿Me equivoco? ¿Es un riesgo mínimo desactivar esto si estoy haciendo una copia de seguridad en el disco y no en una cinta de transmisión o algo así?

No, tienes razón :-)

RESTORE VERIFYONLYsolo no se asegurará de que pueda recuperar su base de datos en caso de corrupción. Por naturaleza, no realizará ninguna verificación de integridad.

Una mejor manera será tomar periódicamente sus copias de seguridad y hacer una restauración válida en un servidor diferente y realizar DBCC CHECKDB en él.

Esta es una de las razones por las que no soy un gran admirador de los planes de mantenimiento, ya que la GUI no expone muchas opciones como backup .. with CHECKSUMesa que T-SQL puede lograr.

Del blog del mito de Paul Randal

24p) usando RESTORE ... WITH VERIFYONLY valida toda la copia de seguridad

No. El uso de VERIFYONLY solo valida que el encabezado de respaldo se vea como un encabezado de respaldo. Solo cuando realiza la copia de seguridad con WITH CHECKSUM y RESTAURA ... WITH VERIFYONLY y con WITH CHECKSUM, la restauración realiza comprobaciones más exhaustivas, incluida la suma de comprobación de toda la copia de seguridad.

¿Ejecutas "verificar" en cada copia de seguridad de tu entorno? ¿Los revisas al azar?

No ejecuto el VERIFYONLY. En su lugar, realizo una copia de seguridad con CHECKSUM y luego los restauro + CHECKDB'ed en un servidor diferente. Puede seguir el enfoque de Muestreo estadístico para verificar las copias de seguridad de la base de datos si desea ser creativo.

Esto no es lo mismo que habilitar la opción de "suma de comprobación" en la copia de seguridad (que no puedo hacer en el asistente, que yo sepa).

Puede habilitar Trace Flag 3023 para que la CHECKSUMopción se habilite automáticamente para el comando BACKUP. Como siempre, pruebe el comportamiento de cualquier indicador de rastreo en su entorno.

La conclusión es: deshacerse de los planes de mantenimiento y utilizar una solución de respaldo más sensata (pista: la solución de respaldo de Ola) que le permitirá personalizarla según sus necesidades.

(Realizamos una copia de seguridad a través de la red en un dispositivo de respaldo EMC DD-800, si es relevante).

Haga una copia de seguridad local en el disco y luego tenga un trabajo de transferencia de PowerShell que copiará la copia de seguridad localmente desde el servidor a un recurso compartido de red (servidor de copia de seguridad). Eso será más rápido que copiar directamente a un recurso compartido de red.

Además, habilite la inicialización instantánea de archivos, lo que ayudará con el crecimiento automático de los archivos de datos y ayudará a reducir el tiempo de restauración (en caso de que tenga que restaurar sus bases de datos). Siempre es bueno tener opciones a mano.

Una buena lectura será: Copias de seguridad: planificación de una estrategia de recuperación

La conclusión es que, a menos que realice una restauración de la base de datos en algún lugar, no puede estar completamente seguro de que un archivo de copia de seguridad dado sea bueno.

La prueba ideal para verificar sus copias de seguridad es configurar un entorno donde las copias de seguridad de la base de datos y las copias de seguridad del registro de la base de datos se restablezcan todo el tiempo como parte de su proceso diario. Esta es una de las ventajas de usar log-shipping ...

Si todavía desea seguir solo con la verificación, puede configurar un entorno específicamente solo para hacer esto. Esto descargaría el trabajo de su (presumiblemente) servidor de producción y reduciría el tiempo de trabajo.

Finalmente, ¿ha considerado alejarse de los planes de mantenimiento? Los guiones como los guiones de Ola son excepto copias de seguridad y mantenimiento: https://ola.hallengren.com/

Técnicamente, la restauración verfyonly es como realizar una restauración, sin embargo, no hay mejor verificación que restaurar la base de datos para verificar que sea una copia de seguridad válida. Hemos tenido una instancia en la que solo se aprobó la verificación, sin embargo, la base de datos no se restableció debido a la corrupción, mi punto es no contar con esto como una verificación de que la copia de seguridad está bien. Ahora hemos desarrollado un sistema que restaura todas nuestras bases de datos en una instancia separada para verificar su validez, claramente eso no siempre es posible, así que intente muestrear cierta base de datos por semana. Lo largo y lo corto no confían en verificar solo al 100%.