SQL Server: cmo hacer copias de seguridad directamente en unidades de red

Jos Manuel Alarcn Agun

SQL SERVER: CMO HACER COPIAS DE SEGURIDAD DIRECTAMENTE EN UNIDADES DE RED

Nivel: Intermedio

por Jos Manuel Alarcn Agun

Generalmente, lo que ms nos interesa a la hora de realizar copias de seguridad es hacerlas hacia alguna mquina o dispositivo especializado de la red local, distintos a la mquina en la que se ejecuta nuestra aplicacin o -en nuestro caso concreto- el servidor de datos. As podremos recuperarlos desde cualquier otra mquina ante cualquier contingencia que surja. En los Data Center (y en muchas oficinas) suelen existir sistemas NAS (Network Attached Storage, almacenamiento en red) cuyo propsito es precisamente albergar las copias de seguridad. SQL Server, sin embargo, slo 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 limitacin, ya que hacer copias de seguridad en local no me resulta til en absoluto. Y tiene muchas limitaciones ms (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 despus, la ejecucin de un archivo .bat que mueva la copia a una unidad de red usando comandos del sistema operativo. Esto funciona pero aade complejidad ya que hay que coordinar ambas acciones y hay ms puntos de fallo. Adems hay una cuestin 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 sera hacer la copia directamente en el NAS sin pasar por el disco local. En este artculo voy a contar cmo podemos conseguir precisamente esto: hacer backups de SQL Server directamente a la red. Adems cuento cmo conseguir un backup diario, con un archivo para da de la semana, que se van sobrescribiendo automticamente, por lo que conseguimos de manera sencilla una retencin de 7 das. Las instrucciones que doy a continuacin 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 operacin por completo, sobre todo en lo referente a los pequeos detalles (como la seguridad) que hacen que llegue a funcionar.

1.- Cuenta de ejecucin de SQL Server

Lo primero que tenemos que hacer es asegurarnos de que nuestro sistema SQL Server va a tener acceso a la red local. Tanto el motor de bases de datos como el agente de SQL Server se ejecutan suplantando a un determinado usuario del sistema operativo.

Mucha gente instala SQL Server para que sus servicios se ejecuten bajo la cuenta de sistema, ya que sta tiene acceso a cualquier recurso del sistema local, y simplifica la gestin. Esto, aparte de un posible problema de seguridad (en el que no voy a entrar en este texto), no es necesario en absoluto. Adems hay una cuestin fundamental: la cuenta de sistema no tiene capacidades para acceder a la red. Por lo tanto si La cuenta de sistema no tiene nuestro servidor de datos se ejecuta bajo System no capacidades para acceder a la podremos realizar copias de seguridad a unidades de red. Network Service, sin red. embargo, s nos sirve para La cuenta recomendada para ejecutar SQL Server y nuestros propsitos. conseguir acceso a la red es "Servicio de Red" (o, en ingls, "Network Service"). Esta cuenta tiene los permisos suficientes para ejecutar SQL Server sin problema y adems nos sirve para nuestro propsito. Lo podemos cambiar desde la configuracin de Servicios de SQL Server, en las propiedades de cada servicio:

Figura 1.- Propiedades del servicio Agente de SQL Server 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 ms comn, las copias de seguridad sern 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 recomendacin sera que pusisemos 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 tendramos permiso para hacer los backups y todo lo que explico no sera necesario, pues podras especificar la ruta remota sin ms. Lo que explico aqu es cmo conseguir esto usando una instalacin tpica 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 slo por el hecho de hacer copias a la red. Lo explicado aqu es ms lioso pero ayuda a mantener separados la operacin normal del gestor de datos y las copias de seguridad, que pienso que no deberan estar tan entrelazadas. En mi opinin debera ser todo ms fcil y SQL Server debera ofrecer una opcin para suplantar a un usuario especfico a la hora de hacer copias (que es en el fondo lo que se consigue con este documento), lo hara que todo fuese ms fcil.

2.- Creacin de la cuenta para acceso a la red

Una cosa es la cuenta bajo la que se ejecuta el servidor y otra es la cuenta que usaremos para acceder al recurso de red. Tendr que ser un usuario que tenga permisos de lectura y escritura en la carpeta compartida en la que queremos escribir el backup. Si las mquinas no estn todas bajo un mismo dominio de Directorio Activo -es decir, utilizamos usuarios diferentes para cada mquina- debemos crear en la mquina en la Debemos crear en la mquina en que se ejecuta SQL Server una cuenta de usuario con el la que se ejecuta SQL Server una mismo nombre y clave que el que usaremos para cuenta de usuario con el mismo acceder a dicho recurso. Por ejemplo, si el NAS tiene un nombre y clave que el que usuario llamado "NAS\Backup" con clave "backup", usaremos para acceder a la red. deberemos crear tambin en local este mismo usuario. Cuando accedemos interactivamente desde el explorador de Windows al recurso remoto podemos escribir el usuario y la clave en la ventana que aparece, pero con el Script SQL que usaremos aqu, o disponemos del usuario tambin en local, o no funcionar.

3.-Habilitar el comando xp_cmdshell

Este comando permite ejecutar comandos del sistema operativo desde scripts T-SQL. Vamos a necesitarlo para habilitar el acceso a los recursos remotos. Por defecto viene desactivado y no podremos usarlo, ya que reviste bastante peligro puesto que otorga acceso a comandos del sistema que pueden ser muy peligrosos (como formatear el disco duro, por ejemplo). En SQL Server 2000 vena habilitado y las aplicaciones con problemas de seguridad debidas a inyeccin SQL y ejecutadas bajo cuentas con demasiados privilegios eran un agujero para la seguridad, por eso en la versin 2005 y posteriores se ha deshabilitado por defecto.

En nuestro caso lo necesitaremos, as que tenemos que habilitarlo. Para ello debemos lanzar las siguientes instrucciones T-SQL desde SQL Management Studio:
-- Permitir el cambio de opciones avanzadas de SQL Server EXEC sp_configure 'show advanced options', 1 GO -- Reconfigurar para que permita modificarlas. RECONFIGURE GO -- Habilitar la caracterstica xp_cmdshell EXEC sp_configure 'xp_cmdshell', 1 GO -- Refrescar para que el cambio surta efecto RECONFIGURE GO

4.- Programar la copia de seguridad

Ahora ya tenemos las bases necesarias para que esto funcione, as que lo nico que nos resta es crear una nueva tarea del agente SQL que se encargue de realizar la copia de seguridad. En el apartado de "pasos de la tarea" crearemos un nuevo paso con las siguientes instrucciones TSQL:
SET LANGUAGE us_english exec xp_cmdshell 'net use \\192.168.1.1\backups\SQL clave /user:backup' DECLARE @Archivo AS nvarchar(100) SET @Archivo = N'\\192.168.1.1\Backups\SQL\MiBaseDeDatos_' + DATENAME(WEEKDAY, GETDATE()) + '.bak' BACKUP DATABASE [MiBaseDeDatos] TO DISK = @Archivo WITH NOFORMAT, INIT, NAME = N'MiBaseDeDatos-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10; exec xp_cmdshell 'net use \\192.168.1.1\Backups\SQL /D'

Lo que estamos haciendo es poner el lenguaje actual en ingls. Yo suelo usar siempre el ingls 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 explcitamente 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 da de la semana para crear un archivo .bak cada da (lunes, martes, y as sucesivamente). El comando xp_cmdshell de la segunda lnea habilita la conexin a la carpeta de red \backups\SQL que est en nuestro NAS, con direccin IP 192.168.1.1. Podramos haber usado el nombre de red (por ejemplo \\NAS o similar), pero con la IP nos aseguramos de que siempre va a funcionar, pues lo otro a veces he detectado que da problemas. En esta lnea, por tanto, debes poner la ruta de red que quieres usar e indicar la clave y nombre de usuario que usaremos para acceder (ver punto 2). Las dos siguientes lneas 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 da de la semana en ingls, 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 da de la semana, con una retencin de 7 das, que se va sobrescribiendo automticamente cuando pasa una semana. Para m esto es ms que suficiente, pero si quisieras ms retencin o ms de una copia diaria al da tendras que buscar una forma alternativa para nombrar los archivos (por ejemplo, con el da del mes, o aadindole la hora). La siguiente lnea es una instruccin T-SQL normal y corriente para crear una copia de seguridad, slo que en este caso ya se har directamente sobre la carpeta de red, y no en local, que es lo que desebamos. 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 del autor

Jos Manuel Alarcn Agun, ASP.NET Visual Developer MVP. Es ingeniero industrial y especialista en consultora de empresa. Ha escrito varios libros, habiendo publicado ms de 300 artculos sobre informtica e ingeniera en publicaciones especializadas. Es colaborador de MSDN. Jos Manuel es tambin Instructor Certificado de Microsoft (MCT). Blog: www.jasoft.org Twitter: jm_alarcon

Acerca de campusMVP
CampusMVP te ofrece la mejor formacin en tecnologa Microsoft a travs de nuestros cursos online y nuestros libros especializados, impartidos y escritos por conocidos MVP de Microsoft. Visita nuestra pgina y prueba nuestros cursos y libros gratuitamente. www.campusmvp.com

Reconocimiento - NoComercial - CompartirIgual (by-nc-sa): No se permite un uso comercial de este documento ni de las posibles obras derivadas, la distribucin de las cuales se debe hacer con una licencia igual a la que regula esta obra original. Se debe citar la fuente.