Basta ya de buscar por todo internet porque estás al espacio adecuado, contamos con la respuesta que necesitas encontrar sin problema.
Solución:
Hay formas de ajustar las copias de seguridad jugando con diferentes perillas como MAXTRANSFERSIZE o BUFFERCOUNT, o fragmentando el archivo (que ha notado que ya está haciendo).
El problema es que tocar esas perillas aún puede resultar en alcanzar los límites de su red y/o almacenamiento, y no tener ningún impacto real en el tiempo de copia de seguridad.
Su primer trabajo debe ser comparar el almacenamiento del que está respaldando usando Crystal Disk Mark o DiskSpd. Eso le dará una idea de qué tan rápido puede esperar que las escrituras sean óptimas.
Lo siguiente que debe probar son las lecturas de las unidades desde las que está realizando la copia de seguridad. Si ejecuta una copia de seguridad en NUL, puede cronometrar el tiempo que tarda solo el leer parte de su copia de seguridad, sin tener que escribirla en el disco.
Con ambos números en mente, puede comenzar a jugar con otras perillas para ver cuáles lo acercan más a ellas, independientemente de si su objetivo de respaldo es local o en red.
La alternativa que mencionas parece ser la mejor opción.
Lo que puedes hacer es un proceso de 2 pasos:
- Realice copias de seguridad nativas del servidor sql con compresión utilizando la solución de copia de seguridad de Ola localmente.
- Utilice Robocopy para realizar las transferencias a un recurso compartido de red. Esto está desacoplado y puede ejecutarse como una tarea programada de Windows.
De esta manera, sus copias de seguridad son locales y serán rápidas. Necesitará más espacio en disco y, obviamente, redundancia (¿y si falla el disco de copia de seguridad? No querrá perder todas sus copias de seguridad).
Como alternativa, según lo recomendado por Max Vernon, realice Robocopy como un paso en el trabajo de copia de seguridad para asegurarse de que la robocopia solo se produzca si la copia de seguridad se completa correctamente y tan pronto como sea posible después de que se complete la copia de seguridad. La copia de seguridad corre el mismo riesgo que los datos, siempre que permanezca local.
Además, pruebe regularmente sus restauraciones, ya que si no puede restaurar una copia de seguridad, ¿para qué sirve?
Además, consulte mi respuesta a SQL Backup tuning bases de datos grandes
Un par de posibles soluciones:
- Pasar de solo completo a un respaldo completo semanal y diferencial nocturno puede ser una solución fácil.
-
Hay una serie de parámetros relacionados con el rendimiento que puede modificar en los scripts de Ola, es posible que pueda modificarlos para obtener el rendimiento que desea:
-
Tamaño de bloque
Especifique el tamaño de bloque físico en bytes.
La opción BlockSize en DatabaseBackup utiliza el
BLOCKSIZEopción en el comando BACKUP de SQL Server. -
Número de búfer
Especifique el número de búferes de E/S que se utilizarán para la operación de copia de seguridad.
La opción BufferCount en DatabaseBackup usa el
BUFFERCOUNTopción en el servidor SQLBACKUPdominio. -
MaxTransferSize
Especifique la unidad de transferencia más grande, en bytes, que se usará entre SQL Server y los medios de copia de seguridad.La opción MaxTransferSize en DatabaseBackup utiliza el
MAXTRANSFERSIZEopción en el servidor SQLBACKUPdominio.
-
Reseñas y calificaciones del post
Al final de la post puedes encontrar las explicaciones de otros gestores de proyectos, tú además tienes la opción de dejar el tuyo si dominas el tema.