Servidor de seguridad

Un  servidor  de  seguridad  presenta  una  doble  ventaja.  Para  empezar,  ofrece  una  garantía  frente  a  la  solución  de 
problemas  extremadamente  rápida  en  caso  de  error  del  servidor  principal,  minimizando  la  pérdida  de  los  datos. 
Además, el servidor de seguridad se alimenta de las copias de seguridad realizadas sobre el servidor principal, lo que
permite  validar  todas  las  copias  de  seguridad,  y  esto  es  un  punto  importante.  Como  contrapartida,  el  servidor  de 
seguridad representa una inversión elevada, ya que esta máquina no puede servir para un entorno de explotación si 
deseamos obtener una solución de reemplazo que se pueda establecer rápidamente. 

1. Instalación del servidor de seguridad

El  servidor  de  seguridad  es  un  segundo  servidor  SQL  que  contiene  una  imagen  en  espejo  del  servidor  de 
producción. El servidor de seguridad puede utilizarse en modo de solo lectura para reducir la carga de trabajo del 
servidor de producción o bien para sustituir al servidor de producción cuando este último esté dañado. El servidor 
de seguridad también puede utilizarse para ejecutar instrucciones DBCC, lo que permite verificar la coherencia de la 
base sin añadir una carga de trabajo adicional en el servidor de producción. 

En primer lugar, es necesario restaurar una copia de seguridad de todas las bases del servidor de producción. Si los 
directorios  son  diferentes,  es  preciso  utilizar  la  opción  MOVE  TO  del  comando  RESTORE  para  cargar  la  ruta  de  los 
archivos de la base. 

Todas  las  restauraciones  deben  tener  la  opción  NORECOVERY  o  STANDBY.  Esta  última  opción  se  detalla  a 
continuación. 

El servidor de seguridad será actualizado por medio de las copias de seguridad del registro de transacciones. 

2. Uso del servidor de seguridad en modo de solo lectura

Dado que el servidor de seguridad es una imagen del servidor de producción, es posible utilizar este servidor para 
los clientes que realizan únicamente operaciones de lectura (SELECT). Esto va a permitir descargar, al servidor de 
producción,  de  la  gestión  de  las  consultas  de  lectura  de  datos,  que  pueden  llegar  a  ser  muy  pesadas, 
fundamentalmente en el caso de análisis.  

Con SQL Server, todos los servidores activos cubiertos con la SA (Software Assurance) permiten instalar un servidor 
de  seguridad.  De  hecho,  solo  los  servidores  activos  necesitan  una  licencia.  Sin  embargo,  preste  atención  a  este 
servidor  de  seguridad,  porque  no  debe  tener  ninguna  carga  de  trabajo.  Las  conexiones  de  usuario,  incluidas  las 
necesarias para las tareas de informes, no son posibles. 

El problema que se plantea es el de la restauración. En efecto, la opción NORECOVERY, que permite restaurar los 
registros, no permite que nadie utilice la base de datos. Para evitar este problema, existe la opción STANDBY, que 
autoriza  únicamente  las  operaciones  de  lectura  sobre  la  base  de  datos.  Esta  opción  necesita  la  utilización  de  un 
archivo  que  servirá  para  anular  las  modificaciones  aportadas  por  la restauración  de  otros  registros  de 
transacciones. 

3. Puesta en marcha de un servidor de seguridad

El punto de partida de la puesta en marcha de un servidor de seguridad es normalmente una copia de seguridad 
completa de la base de origen. 

En el ejemplo siguiente, la copia de seguridad de la base GESCOM está realizada en una unidad física. 

© Éditions ENI – Todos los derechos reservados – Copia personal de Mercedes Ccesa Quincho - 1-
 En  una  segunda  etapa,  esta  copia  de  seguridad  debe  restaurarse  en  el  servidor  de  seguridad.  Dado  que  las 
ubicaciones de los archivos físicos no son necesariamente las mismas, se utiliza la opción MOVE TO en el proceso de 
restauración. 

En el ejemplo siguiente, es otra instancia de SQL Server la que actúa de servidor de seguridad. 

Con  el  objetivo  de  simplificar  los  elementos  de  sintaxis,  la  base  GESCOM  inicial  no  contiene  el  catálogo  de  texto 
completo. 

Seguidamente,  las  copias  de  seguridad  de  los  registros  de  la  base  principal  se  restauran  en  el  servidor  de 
seguridad con la opción STANDBY o NORECOVERY. 

Este  proceso  de  envío  de  los  archivos  diarios  puede  automatizarse  con  SQL  Server   configurando  el  servidor 
principal para que sitúe una copia de seguridad del registro en una carpeta accesible por el servidor de seguridad. 

Desde  SQL  Server  Management  Studio,  la  configuración  del  envío  automático  de  los  registros  se  efectúa  de  la 
manera siguiente. 

- 2- © Éditions ENI – Todos los derechos reservados – Copia personal de Mercedes Ccesa Quincho
Es necesario definir la base de datos como base de datos primaria, a continuación definir la ruta local o de red de 
acceso a la copia de seguridad del registro. Posteriormente, es posible definir el servidor o los servidores a los que 
se  va  a  enviar  la  copia  del  registro,  así  como  el  modo  de  restauración  deseado  del  registro.  Las  operaciones  de 
copia de seguridad y de restauración se planifican. 

© Éditions ENI – Todos los derechos reservados – Copia personal de Mercedes Ccesa Quincho - 3-
 Todas las operaciones relativas al envío de los registros pueden seguirse mediante una base de datos testigo que 
a va consignar todos los eventos relativos a esta operación. 

El  procedimiento  de  envío  automático  de  los  registros  se  establece  para  bases  de  datos,  cuya  estructura  física 
permanece razonable en términos de complejidad (algunos archivos). 

Evidentemente, este proceso se basa en los trabajos planificados y SQL Server Agent debe estar activo. 

4. Cómo trabajar con el servidor de seguridad

Si el servidor de producción se avería, el servidor de seguridad debe tomar el relevo lo más rápidamente posible. Es 
indispensable un enfoque riguroso para perder la mínima cantidad de datos. 

a. Conexión

Servidor de producción 

Copia de seguridad del registro de transacciones 

Si la operación es posible, debe realizarse una copia de seguridad del registro de transacciones para 
que las transacciones validadas desde la última copia de seguridad no se pierdan. 

Desconexión 

Con el objetivo de evitar cualquier conflicto, el servidor de producción debe estar físicamente 
desconectado de la red. 

Servidor de seguridad 

Nombre del servidor 

Para no molestar a los puestos clientes que utilizan el servidor, el cambio de nombre permite una 
relativa transparencia en relación con las aplicaciones. 

Restauración del registro 

El registro que se ha salvaguardado en el servidor de producción debe restaurarse con la opción 
RECOVERY para hacer accesible la base de datos en modo de lectura y escritura. 

b. Restauración del servidor de producción

Cuando se haya solucionado el problema en el servidor de producción, este debe retomar su rol inicial. 

Servidor de seguridad 

l Realizar una copia de seguridad de la base de datos y de todos los registros de transacciones. 

l Desconectar físicamente el servidor de la red. 

- 4- © Éditions ENI – Todos los derechos reservados – Copia personal de Mercedes Ccesa Quincho
 Servidor de producción 

l Restaurar las copias de seguridad de la base de datos y de los registros de transacciones. Posteriormente, conectar 
de nuevo el servidor a la red. 

c. Restablecimiento del ordenador SQL Server de seguridad

El servidor de seguridad debe cambiar de nombre antes de su conexión a la red. Para que se convierta en imagen 
del  servidor  de  producción,  lo  más  sencillo  es  realizar  una  copia  de  seguridad  completa  de  la  base  de  datos  y 
restaurarla con la opción STANDBY o NORECOVERY. 

© Éditions ENI – Todos los derechos reservados – Copia personal de Mercedes Ccesa Quincho - 5-