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).
fuente
Respuestas:
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
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.
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.
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
fuente
TSQLen lugar deGUI(planes de mantenimiento) para que pueda aprovechar la flexibilidad y adaptarla con las manos abiertas. Al igual que para su información ... los planes de mantenimiento se han mejorado en SQL Server 2016,CTP 2.4que MS llama planes de mantenimiento inteligente de SQL Server , integra las mejores prácticas y puede identificar estrategias óptimas sobre la marcha. Todavía ninguna GUI puede vencer a TSQL :-)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/
fuente
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%.
fuente