Alternativas a la copia de seguridad de red

En nuestro entorno, tenemos algunos servidores que se encuentran en un grupo de disponibilidad Always On y algunos que son independientes.

Normalmente hacemos copias de seguridad en un recurso compartido de red, pero recientemente hemos observado que a medida que las bases de datos crecen, el tiempo que se tarda es más largo, lo que ralentiza toda la red.

El script de Ola hallengren se usa con compresión y también divide los archivos de copia de seguridad. Solo estoy realizando copias de seguridad diarias "completas". Las copias de seguridad van a la unidad compartida de red EMC isilon.

Nunca me siento cómodo con EMC DD Boost. La única alternativa es hacer una copia de seguridad local y luego copiar al mismo recurso compartido de red.

¿Hay alguna manera eficiente que no sea la anterior?

La alternativa que mencionó parece ser la mejor opción.

Lo que puedes hacer es un proceso de 2 pasos:

• Realice copias de seguridad del servidor SQL nativo con compresión utilizando la solución de copia de seguridad de Ola localmente.
• Use Robocopy para hacer 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 (¿qué pasa si falla el disco de copia de seguridad? No desea perder todas sus copias de seguridad).

Alternativamente, según lo recomendado por Max Vernon, realice la Robocopy como un paso en el trabajo de copia de seguridad para asegurarse de que la robocopy solo se produce si la copia de seguridad se completa con éxito y tan pronto como sea posible una vez completada 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 sintonizando grandes bases de datos

Hay formas de ajustar las copias de seguridad jugando con diferentes botones como MAXTRANSFERSIZE o BUFFERCOUNT , o eliminando el archivo (lo que ya notó que ya está haciendo).

El problema es que tocar esas perillas aún puede llegar a alcanzar los límites de su red y / o almacenamiento, y no tener ningún impacto real en el tiempo de respaldo.

Su primer trabajo debe ser comparar el almacenamiento del que está haciendo una copia de seguridad con Crystal Disk Mark o DiskSpd . Eso le dará una idea de cuán rápido puede esperar que las escrituras sean lo mejor posible.

Lo siguiente que debe probar son las lecturas de las unidades desde las que realiza la copia de seguridad. Si ejecuta una copia de seguridad en NUL , puede calcular el tiempo que tarda solo la parte de lectura de su copia de seguridad, sin tener que escribirla en el disco.

Con ambos números en mente, puede comenzar a jugar con otros botones para ver cuáles se acercan más a ellos, independientemente de si su objetivo de respaldo es local o en red.

Un par de posibles soluciones:

1. Pasar de una copia de seguridad completa semanal a una copia de seguridad completa semanal y un diferencial nocturno puede ser una solución fácil.

2. Hay una serie de parámetros relacionados con el rendimiento que puede modificar en los scripts de Ola, puede modificarlos para obtener el rendimiento que desea:

   • BlockSize
     Especifique el tamaño de bloque físico en bytes.

     La opción BlockSize en DatabaseBackup usa la BLOCKSIZEopción en el comando BACKUP de SQL Server.

   • BufferCount
     Especifique el número de buffers de E / S que se utilizarán para la operación de copia de seguridad.

     La opción BufferCount en DatabaseBackup usa la BUFFERCOUNTopción en el BACKUPcomando SQL Server .

   • MaxTransferSize Especifique la unidad de transferencia más grande, en bytes, que se utilizará entre SQL Server y los medios de copia de seguridad.

     La opción MaxTransferSize en DatabaseBackup usa la MAXTRANSFERSIZEopción en el BACKUPcomando SQL Server .

Hay muchas opciones posibles, pero a medida que las bases de datos se hacen más grandes y las copias de seguridad completas tardan más, es probable que tenga que incorporar copias de seguridad diferenciales , si aún no lo ha hecho:

Crear una copia de seguridad diferencial puede ser muy rápido en comparación con crear una copia de seguridad completa. Una copia de seguridad diferencial registra solo los datos que han cambiado desde que se basa la copia de seguridad completa en la copia de seguridad diferencial. Esto facilita la realización de copias de seguridad de datos frecuentes, lo que disminuye el riesgo de pérdida de datos.

Tengo entendido que los scripts de Ola incluso se pueden configurar para decidir entre una copia de seguridad completa o diferencial en función de la cantidad de cambio en la base de datos utilizando el parámetro ModificationLevel .

Utilizamos EMC DD Boost, y le damos la bienvenida a su propia opinión al respecto, pero hemos descubierto, debido a los métodos de desduplicación del lado del cliente que utiliza, que las copias de seguridad completas incluso de bases de datos de TB múltiple pueden ser muy rápidas, hasta el punto de que no tenemos que preocuparnos por las copias de seguridad diferenciales de SQL Server. En efecto, al usar EMC DD, está haciendo copias de seguridad diferenciales, pero no en SQL Server. El uso de múltiples archivos de destino también mejora enormemente la velocidad, incluso en DDBoost.