Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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), 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 nuestro servidor de datos se ejecuta bajo System no podremos
realizar copias de seguridad a unidades de red.
La cuenta recomendada para ejecutar SQL Server y conseguir acceso a la red es "Servico 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:
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 esta cuenta.
En cualquier caso (y sin ser especialista en absoluto en SQL Server), mi recomendacin sera que
pusisemos ambos servicios a ejecutarse bajo esta cuenta.
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 no estamos bajo un mismo dominio de Directorio
Activo -es decir, utilizamos usuarios diferentes para cada mquina- debemos crear en nuestra mquina
local (en la que se ejecuta SQL Server) una cuenta de usuario con el mismo nombre y clave que el que
usaremos para acceder a dicho recurso. Por ejemplo, si el NAS tiene un usuario llamado "NAS\Backup"
con clave "backup", 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 ventan que aparece, pero con el Script SQL que usaremos aqu, o disponemos del usuario
tambin en local, o no funcionar. El motivo no lo tengo muy claro, pero es as :-(
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 Serevr 2000 vena habilitado por
defecto y las aplicaciones con problemas de seguridad debidas a inyecin SQL y ejecutadas bajo cuentas
con demasiados privilegios eran una coladera, por eso en la versin 2005 y posteriores se ha
deshabilitado por omisin.
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
Ya est.
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 T-SQL:
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 pero t, claro est,
puedes usar el idioma que prefieras. El hecho de establecer el idioma es para asegurarnos de que si
transportamos el Script a otro servidor diferente los nombres de los archivos de copia de seguridad van a
tener nombres consistentes, ya que usaremos el nombre del 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 queires
usar e indicar la clave y nombre de usuario que usaremos para acceder (ver paso 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 mi 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.
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.
Espero que te resulte til y que mis horas de prueba y error te ahorren a ti mucho tiempo. Si me
loquieres agradecedr, ya sabes, matriclate en alguno de nuestros cursos o compra alguno de nuestros
libros ;-)