Professional Documents
Culture Documents
hacer copias de
seguridad
directamente en
unidades de red
José Manuel Alarcón Aguín
SQL SERVER: CÓMO HACER COPIAS DE SEGURIDAD DIRECTAMENTE EN
UNIDADES DE RED
Nivel: Intermedio
por José Manuel Alarcón Aguín
Generalmente, lo que más nos interesa a la hora de realizar copias de seguridad es hacerlas
hacia alguna máquina o dispositivo especializado de la red local, distintos a la máquina en la
que se ejecuta nuestra aplicación o -en nuestro caso concreto- el servidor de datos. Así
podremos recuperarlos desde cualquier otra máquina ante cualquier contingencia que surja.
En los Data Center (y en muchas oficinas) suelen existir sistemas NAS (Network Attached
Storage, almacenamiento en red) cuyo propósito es precisamente albergar las copias de
seguridad.
SQL Server, sin embargo, sólo ofrece soporte nativo para realizar copias de seguridad en
unidades de disco o dispositivos de backup hardware locales. Esto siempre me ha parecido una
seria limitación, ya que hacer copias de seguridad en local no me resulta útil en absoluto. Y
tiene muchas limitaciones más (como no comprimir o cifrar las copias), aunque esto es bueno
para las empresas que venden herramientas especializadas en ello, como la excelente SQL
Backup de Red Gate Software.
Lo que muchos hemos hecho toda la vida ha sido lo siguiente: haces el backup en una carpeta
local y programas, un tiempo prudencial después, la ejecución de un archivo .bat que mueva la
copia a una unidad de red usando comandos del sistema operativo. Esto funciona pero añade
complejidad ya que hay que coordinar ambas acciones y hay más puntos de fallo. Además hay
una cuestión adicional que a mí ya me ha ocurrido en servidores viejos: si el disco local no
tiene espacio suficiente no puedes hacer copias de seguridad (no te caben), cuando a lo mejor
tienes cientos de GB libres en el NAS que no puedes aprovechar :-(
Lo ideal sería hacer la copia directamente en el NAS sin pasar por el disco local. En este artículo
voy a contar cómo podemos conseguir precisamente esto: hacer backups de SQL Server
directamente a la red. Además cuento cómo conseguir un backup diario, con un archivo para
día de la semana, que se van sobrescribiendo automáticamente, por lo que conseguimos de
manera sencilla una retención de 7 días.
Las instrucciones que doy a continuación funcionan con SQL Server 2005 y 2008, y las he
sacado a base de prueba y fallo durante bastante tiempo. No he encontrado en Internet
instrucciones algunas que contemplen esta operación por completo, sobre todo en lo
referente a los pequeños detalles (como la seguridad) que hacen que llegue a funcionar.
Si las copias de seguridad las vamos a hacer escribiendo el comando desde el SQL
Management Studio, esta cuenta debemos asignarla al motor de SQL Server. Si, como es más
común, las copias de seguridad serán automatizadas con el agente de SQL Server, es este
servicio el que debe ejecutarse con una cuenta con acceso a la red. En cualquier caso (y sin ser
especialista en SQL Server), mi recomendación sería que pusiésemos ambos servicios a
ejecutarse bajo esta cuenta.
NOTA: en realidad si creamos un usuario especial para ejecutar SQL Server y a éste le damos acceso a los
recursos de red que nos interesen, ya tendríamos permiso para hacer los backups y todo lo que explico no sería
necesario, pues podrías especificar la ruta remota sin más. Lo que explico aquí es cómo conseguir esto usando
una instalación típica de SQL Server que se ejecuta con alguna de las cuentas predeterminadas (en este caso
Network Service), y sin tener que crear un usuario especial sólo por el hecho de hacer copias a la red. Lo
explicado aquí es más lioso pero ayuda a mantener separados la operación normal del gestor de datos y las
copias de seguridad, que pienso que no deberían estar tan entrelazadas. En mi opinión debería ser todo más fácil
y SQL Server debería ofrecer una opción para suplantar a un usuario específico a la hora de hacer copias (que es
en el fondo lo que se consigue con este documento), lo haría que todo fuese más fácil.
Lo que estamos haciendo es poner el lenguaje actual en inglés. Yo suelo usar siempre el inglés
para todo y tengo los sistemas en este idioma porque considero que tiene muchas ventajas.
Tú, claro está, puedes usar el idioma que prefieras. El hecho de establecer el idioma
explícitamente es para asegurarnos de que si transportamos el Script a otro servidor diferente
los archivos de copia de seguridad van a tener nombres consistentes, ya que usaremos el día
de la semana para crear un archivo .bak cada día (lunes, martes, y así sucesivamente).
Las dos siguientes líneas declaran el nombre y la ruta del archivo de backup que vamos a crear.
Lo que yo hago aquí es ponerle como sufijo el nombre del día de la semana en inglés, de forma
que se me crean copias de seguridad diarias con el nombre "MiBaseDeDatos_Monday.bak",
"MiBaseDeDatos_Tuesday.bak", y así sucesivamente. Con esto consigo tener una copia
completa cada día de la semana, con una retención de 7 días, que se va sobrescribiendo
automáticamente cuando pasa una semana. Para mí esto es más que suficiente, pero si
quisieras más retención o más de una copia diaria al día tendrías que buscar una forma
alternativa para nombrar los archivos (por ejemplo, con el día del mes, o añadiéndole la hora).
La siguiente línea es una instrucción T-SQL normal y corriente para crear una copia de
seguridad, sólo que en este caso ya se hará directamente sobre la carpeta de red, y no en local,
que es lo que deseábamos.
Finalmente con xp_cmdshell, nos desconectamos del recurso de red. Esto es necesario para
que no queden conexiones abiertas y nos impidan volver a reconectar en sucesivas ocasiones.
Acerca de campusMVP
CampusMVP te ofrece la mejor formación en tecnología Microsoft a través de nuestros cursos online y
nuestros libros especializados, impartidos y escritos por conocidos MVP de Microsoft. Visita nuestra
página y prueba nuestros cursos y libros gratuitamente. www.campusmvp.com