Copias de seguridad de SQL Server: un par de preguntas

Ejecutamos nuestro trabajo de respaldo semanal a las 9 p.m. los viernes y estamos experimentando un par de problemas con respecto al espacio en disco (que a veces es peligrosamente bajo) y el rendimiento. Estamos buscando racionalizar / optimizar lo que sucede y agradeceríamos sus comentarios.

Específicamente:

1. El proceso de copia de seguridad tarda aproximadamente 4 horas en actualizar las estadísticas durante la copia de seguridad. ¿Podemos desactivar este proceso de forma segura para ahorrar tiempo?

2. Nos estamos quedando sin espacio en disco muy regularmente y nos preguntamos si deberíamos reiniciar el proceso. Actualmente crea la copia de seguridad y luego elimina la copia de seguridad anterior y esto es lo que está acaparando espacio en disco. ¿Podemos eliminar con seguridad el anterior primero y luego hacer la copia de seguridad?

Cualquier otro comentario u observación sería muy bienvenido EDITAR: el tamaño total de los archivos SQL en el servidor es de alrededor de 35 GB. Un db tiene un tamaño de aproximadamente 25 GB, mientras que los otros seis comparten los otros 10 GB.

(1) Sí, generalmente tengo el proceso de copia de seguridad solo. Si pudiera, no estaría haciendo nada durante mi tiempo de respaldo. Es posible que haga que realice la copia de seguridad y luego actualice las estadísticas. Parece que está ejecutando dos trabajos (1 para copia de seguridad, 1 para estadísticas de actualización) al mismo tiempo.

(2) ¿Copia la copia de seguridad en cinta u otro almacenamiento en disco? Si es así, normalmente limpio los archivos antes de crear nuevas copias de seguridad localmente. De lo contrario, si estoy buscando espacio de almacenamiento, consideraría comprimir el archivo de copia de seguridad antes de crear el nuevo. (Es decir, si no puede habilitar la compresión en las copias de seguridad, como sugirió @Simon , esto también ahorraría algo de espacio).

Solo puedo responder la pregunta 2 aquí. Le recomiendo que eche un vistazo a las copias de seguridad comprimidas.

• SQL Server puede hacer esto, si tiene la edición Enterprise 2008. Si no, mira los dos a continuación.
• Quest Litespeed
• RedGate SQL backup

1) No veo una relación directa entre la tarea de hacer una copia de seguridad y la tarea de actualizar las estadísticas. Para que pueda dividirlos sin ningún problema. Vería la parte de estadísticas de actualización más relacionada con un trabajo que desfragmentaría / reconstruiría los índices.

2) Incluso si es por poco tiempo, no querrás estar sin una copia de seguridad. Por lo tanto, querrá eliminar la última copia de seguridad solo si ya la tiene guardada en otro lugar.

Nota al margen aquí: si está haciendo copias de seguridad en la misma caja de almacenamiento donde tiene la base de datos, entonces las copias de seguridad no serán seguras cuando tenga un problema de hardware con la caja de almacenamiento. Por lo tanto, debe asegurarse de tener suficiente espacio para realizar copias de seguridad en otro lugar, no en la misma máquina.

Nota al margen 2: según lo especificado por Simon, invierta tiempo / dinero en copias de seguridad comprimidas si tiene problemas de espacio. Puede ver muchas ideas en esta pregunta: la copia de seguridad más pequeña posible ... con SQL Server .

Su tarea de estadísticas de actualización no debería tomar 4 horas para una base de datos de 3-4 GB. Es muy probable que haya tenido algunos problemas de E / S o que tenga una base de datos muy fragmentada que está creando problemas de E / S. Ejecute una desfragmentación o reconstrucción de índice en la base de datos y vea si eso mejora el rendimiento. De lo contrario, inicie perfmon y compruebe dónde está su cuello de botella de rendimiento.

No recomendaría eliminar su única copia de seguridad antes de tomar una nueva. No sería la primera vez que fallaba una copia de seguridad o la instancia fallaba, y no es aconsejable tener un intervalo de tiempo sin posibilidad de recuperación.

Esa no es la solución a su problema. Descubrir cómo tener más espacio para albergar a ambos sería la forma correcta de hacerlo.