Una buena política a la hora de trabajar con nuestras bases de datos es sacar partido a los planes de mantenimiento de SQL Server para crear flujos de trabajo que nos ayuden a realizar todo tipo de tareas del día a día en las bases de datos, pero automatizándolos para no tener que estar pendientes.
Una de las tareas más comunes es la de realizar copias de seguridad. Podemos realizar backups de muchas maneras, incluso manualmente en versiones como SQL Server Express (gratuita) que no soportan el programador de tareas de SQL Server, el Agente de SQL Server. Pero sin duda la manera más sencilla y visual es utilizar los planes de mantenimiento. Gracias a ellos podemos simplemente arrastrar cajas especializadas en un diseñador visual y unirlas mediante flechas para crear secuencias y conseguir lo que necesitemos:
En el caso de la figura, por ejemplo, la tarea realiza las siguientes sub-tareas:
- Verificar la integridad de todas las bases de datos y sus índices.
- Realizar un backup completo de todas las bases de datos. Se hará semanalmente ya que forma parte de un plan con varias otras tareas que se encargan de hacer backups diferenciales y backups de logs mucho más a menudo.
- Borrado de copias de seguridad antiguas.
- Borrado de histórico de operaciones antiguas.
- Si cualquier paso falla notificará automáticamente por correo electrónico a las personas responsables del proceso.
Como vemos todo muy visual y sencillo. Posteriormente, cuando tengamos todo definido, las programaremos para que se ejecuten periódicamente de forma automática, de lo cual se encargará el agente de SQL Server (SQL Server Agent).
El borrado de backups no funciona
Bien, lo anterior era tan solo para que conocieses esta interesante herramienta en caso de que no fuese así. El objetivo de este post, sin embargo, es comentar un problema que ocurre a veces y que puede darte más de un dolor de cabeza.
Uno de los pasos del flujo anterior, el 4, se encarga de borrar todas las copias de seguridad antiguas. De este modo tenemos un cierto periodo de retención de los datos (por ejemplo 15 días) durante el cual podemos volver a cualquier punto anterior de una base de datos en dicho tiempo (siempre y cuando coordinemos bien los diferentes tipos de copia de seguridad: completa, diferencial y la frecuente de los logs), pero a la vez mantenemos bajo control el espacio de almacenamiento, ya que estos backups pueden llegar a ocupar mucho espacio en disco.
Si abrimos la edición de ese paso 4 de borrado de datos, veremos una pantalla como esta:
Realmente es muy sencilla: indicamos qué queremos borrar, en dónde están las copias de seguridad, qué extensión tienen, y el periodo de retención que queremos. En este caso se borrarán los archivos que tengan más de 15 días de antigüedad.
El problema es que, dependiendo de cómo tengas las copias organizadas, no te funcionará. Y esto hace que puedan acumularse muchos GB de datos hasta que se te llene el disco y te quedes sin copias recientes. ¡Ouch!
Una cuestión muy habitual es que las copias de seguridad se guarden dentro de subcarpetas, una por cada base de datos. En este caso lo que debes hacer es marcar la casilla "Incluir subcarpetas de primer nivel"
que se ve en la figura anterior. Pues bien, dependiendo de cómo hayas escrito los campos anteriores, te funcionará o no el borrado de estos archivos.
En primer lugar, si usas el botón de los tres puntos "..."
para elegir la ruta en la que están guardadas las copias de seguridad, se produce una cosa extraña. Si eliges una subcarpeta en un disco, por ejemplo "K:\SQLBackups"
, esta ruta se mostrará en el cuadro de texto sin la barra inclinada final, tal y como la he puesto yo en la figura. Pero si tienes una unidad de disco entera dedicada a backups (y por lo tanto esas subcarpetas están en la raíz de ésta), te escribirá algo como "K:\", es decir, le pone la barra inclinada al final. En condiciones normales esto no es ningún problema, pero SQL Server tiene un bug (no lo he encontrado reflejado en ninguna parte, es un bug sacado de la (amarga) experiencia que hace que sea muy diferente ponerle o no esta barra.
Si le dejas la barra del final a una unidad raíz y marcas lo de incluir las subcarpetas, la tarea no funcionará. Lo peor es que no producirá ningún error y no te enterarás tampoco. Por lo tanto, es muy importante que le quites a mano la barra inclinada final que te pone la UI de SQL Server Management Studio.
Es un detalle tonto pero muy importante. Con esto te funcionará como cabe esperar y tus backups antiguos se irán eliminando para no ocupar espacio innecesario.
Otro detalle tonto pero importante: la extensión del archivo debe ir sin el punto delante. Si se lo pones "tragará" con él sin problemas y no te advertirá de nada, pero tampoco te funcionará el proceso. Así que debe ir como se ve en la figura, simplemente bak
(o la extensión que corresponda según el caso) sin el punto.
Como ves los detalles son importantes...
Nota: lo anterior funciona bien como he indicado con SQL Server 2017. No lo he probado en versiones anteriores, pero es muy probable que ocurra lo mismo pues esto no tienen pinta de haberlo tocado mucho en años. Si este post te ayuda y usas una versión anterior déjalo en los comentarios para que sepamos para qué versiones sirve. Gracias.
Puede que te interese también:
¡Espero que te sea útil!