ICM / backup / Sistema de replicación de datos con SQL Server

Sistema de replicación de datos con SQL Server

19 mayo 2021 | Carlos Calvo

¿Cuántas veces nos habrás «oído» decir que un plan de Disaster Recovery Plan y los backups son necesarios en las empresas? Muchas, seguramente, y seguiremos afirmándolo hasta que sea posible. Y por ello, hoy te queremos explicar cómo ejecutar un sistema de replicación de datos con SQL server.

¿Es necesaria una copia de seguridad? Sí, sí y sí

Dentro del mundo de la informática, ya sea a nivel profesional o a nivel personal, alguna vez en nuestra vida todos nos hemos maldecido por no haber hecho una copia de seguridad. De aquella información que sí, ya sabíamos que era importante, pero pensábamos que estando en nuestro disco duro externo nunca perderíamos. ¿Te suena esta situación?

Esa foto perdida, ese fichero de código fuente que guardabas como oro en paño, los vídeos de tu familia, tus viajes… Perder datos con los que tenemos una relación sentimental muchas veces nos parece un auténtico desastre. Realmente al que le ha pasado sabe que duele y que, además, nos sentimos mal por haber caído en algo tan sencillo como no realizar un backup de nuestros datos. Esta misma pérdida en el entorno empresarial puede suponer que pierdas un cliente, que te denuncie uno o varios de tus clientes -o todos-, o, incluso, que acabes cerrando tu negocio.

A nivel empresarial, no tener backups puede ser, como comentaba, un desastre. Tenemos muchos ejemplos a lo largo de la historia. En Madrid, el edificio Windsor, que se quemó en febrero de 2005, dejó a varias empresas sin sus datos que residían en el propio edificio. De este modo, provocó que varias de ellas tuvieran que cerrar por verse incapaces de continuar su negocio sin los datos perdidos. Y, en el fondo, por no tener un sistema de backup bien definido.

Los backups y DR para la continuidad del negocio

De lo que hablamos hoy en este artículo es de continuidad de negocio. Ojo, son palabras mayores. Estamos hablando de montar un sistema mediante el cual nuestra empresa pueda continuar su actividad (aunque no sea al 100%) si ocurre un desastre en el lugar donde tenemos nuestros datos.

Alguien dirá “ya Carlos, pero nosotros tenemos los datos en un Datacenter Tier III y me da mucha seguridad” -ver Diseño Data Center y Grados de disponibilidad (Tier). – Blog CliAtec-. Yo les contestaría: “¿recuerdas el incendio de OVH de hace unas semanas en que el fuego devoró los Datacenters SBG1 y SBG2 y parte de otros?” Pues ese incendio dejó a cientos de empresas sin servicio y sin datos. El que se vio afectado y no tenía un backup fuera de esos Datacenters aún está buscando en qué agujero meterse para no salir nunca más.

A veces, no es suficiente con tener un backup fuera de tu Datacenter. También es importante tener claro qué haremos con él si lo necesitamos en el futuro.

Ejemplo

Imaginemos esta situación: tenemos un pequeño site publicado en .netCore con IIS y una base de datos montada en SQL Server. Cada día, a las 12 de la noche, ejecutamos un backup que, además, sacamos de nuestro Datacenter y nos lo llevamos a, por ejemplo, un storage container de Azure. Bueno, bien, ¿no? Pues en principio no.

Eso nos garantiza que tenemos un backup a salvo, pero ¿has pensado alguna vez qué pasaría si se quemase el Datacenter donde tienes tus servidores de producción? ¿O si te los hackearan hasta el tuétano? Es decir, tendrías en Azure un montón de ficheros de backup.

Pero y la pregunta entonces sería, ¿qué hago yo con esto? Tengo unos .bak (backups SQL Server) que no tengo dónde levantar y tengo el código de mi app, pero ningún IIS en el que desplegarlo. Desastre. Volverás a levantar todos esos servicios, pero tus clientes se habrán quedado unas cuantas horas (a veces, días) sin servicio. Eso en internet, según la trayectoria de tu site, puede suponer la muerte.

Plan de Disaster Recovery

Por tanto, no es suficiente con tener un backup, sino que debemos tener un plan de Disaster Recovery (DR), que nos permita hacer uso de esos backups en un tiempo prudencial para poder continuar con nuestro negocio. Insisto, aunque no sea al 100%. Un buen plan de DR debería dar respuesta a algunas preguntas, se me ocurren las siguientes.

¿Cuánto tiempo puede estar mi negocio parado?

Pregunta básica. ¿no? Oye, si se me cae el negocio ahora mismo, ¿cuánto tiempo puede estar parado? ¿Doy servicio a terceros que se pueden permitir que mi negocio esté caído durante un tiempo prolongado? ¿Tengo inversores que van a empezar a desconfiar de mi negocio si está un día entero caído?

Y aquí no estamos hablando de la pérdida de datos, simplemente de continuidad del negocio y de la visibilidad pública o privada con tus Partners en Internet. Si tenemos una forma de levantar nuestro negocio en un Datacenter o proveedor Cloud como Aws o Azure (o cualquier otro) en un tiempo muy bajo, aunque sea a costa de perder datos, nuestra visibilidad pública no se verá demasiado afectada. Nuestros usuarios es posible que tengan que lidiar con una pérdida de datos, pero al menos estás ahí y tu servicio ha podido continuar ante un desastre grande.

¿Cuánto tiempo de datos puedo perder?

Pero ahora toca hablar de los datos. Imagina que levantas el negocio, pongamos en Azure; tenías una suscripción de Azure y contabas con un AppService correctamente configurado al que le has pinchado tu app en .netCore y la has levantado en poco tiempo. ¡Genial! Pero, ¿recuerdas que los datos pasaban por un proceso de backup cada 24h y se hacía a las 12 de la noche? Pues la mala suerte ha querido que el Datacenter se queme a las 23:30. ¿Sabes qué? Has perdido 23 horas y 30 minutos de datos. ¿Es asumible para tu negocio?

Aquí, dependiendo del tipo de negocio que tengas, te encontrarás con unos problemas casi imposibles de solventar. Quejas de clientes, transacciones perdidas, envíos de mensajería perdidos. Vamos, que vas a perder clientes casi con total seguridad o, al menos, los vas a enfadar; estado anímico que no nos interesa.

DR con SQL Server

Hoy, en este artículo nos vamos a centrar en la segunda pregunta y trataremos un caso práctico. Tenemos un SQL Server donde guardamos todos los datos que nuestra empresa necesita para funcionar -sí, esa que copiamos cada 24h a otro Datacenter. Queremos que, ante una caída prolongada del Datacenter donde residen los datos, nuestro negocio siga funcionando accediendo a esos datos. Ahora veremos qué debemos hacer para que nuestros datos de SQL Server estén a salvo en una localización concreta.

Para llevar a cabo la prueba, podríamos servirnos de varias características de SQL Server. Por un lado, tenemos Log Shipping, que se encargan de gestionar backups de los logs de transacciones y enviarlos a otro server para restaurarlos de forma programada.

Podríamos optar por Database Mirroring, que es parecido a Log Shipping pero usando un canal TCP para la transmisión de los logs de transacciones hacia otro servidor. Clusters de AlwaysOn o tenemos el maravilloso -sí, realmente pienso que es una maravilla de servicio- Always On Availability Groups de SQL Server, más sofisticado, pero sólo está accesible en la edición Enterprise del producto. Y tiene una gran pega; realmente tiene un precio al alcance de no todas las empresas.

Trabajando SQL Server con Log Shipping

En este artículo vamos a suponer que tenemos un presupuesto limitado y que estamos trabajando con la edición Web de SQL Server 2017. Seleccionamos esta edición porque es la más barata a nivel de licenciamiento con la que podemos hacer algún tipo de trabajo de replicación, así que trabajaremos con esta versión y con Log Shipping.

Lo primero que debemos decir es que Log Shipping no es un sistema que replique datos en tiempo real como sí hacen otros métodos mencionados en el párrafo anterior. Esto puede suponer una desventaja, nuestros datos no están sincronizados en tiempo real y sigue existiendo un número de minutos durante los cuales podría perder información. Y algunas ventajas, como el hecho que si hemos tenido una corrupción de datos, tendremos tiempo para evitar que esos cambios acaben en el servidor secundario. Necesitamos especificarle la frecuencia con la que realizamos esas copias de transiciones de logs de las que ahora hablaremos. Esto es importante ajustarlo bien en función del tamaño de nuestras bases de datos y del volumen de cambios de estas para que los Jobs de backup y restore sean lo más rápidos de ejecutar posible.

Además, nuestros logs pueden ser enviados a otro servidor SQL Server o a varios. En este caso, recibirá nuestros logs un único servidor; supongamos, ServerProd como servidor de producción y ServerDR como servidor de DR.

Caso práctico de DR con SQL Server

El funcionamiento es bastante simple: tenemos dos instancias de SQL Server. En la primera, en ServerProd, hay todas nuestras bases de datos y generaremos una serie de Jobs que se encarguen del movimiento de datos desde ServerProd y hacia ServerDR. Para que esto se pueda ejecutar las dos máquinas se deben ver a nivel de networking. Por ello, hemos ajustado las reglas de firewall de ambas, de tal forma que podamos acceder a un SMB publicado en ServerDR. Y de forma que los servicios SQL Server en ambas máquinas se vean a nivel de red.

Estos Jobs se generarán automáticamente a partir de nuestras acciones en la interfaz gráfica de SQL Server Management Studio. Pero podéis prepararos una batería de scripts que hagan este trabajo por vosotros de forma desatendida. Muy útil sobre todo si el ritmo de inserción de nuevas bases de datos al sistema de Log Shipping es alto.

Supongamos que la base de datos sobre la que queremos tener un DR configurado es ‘icm_db_dr_test’, que está ubicada inicialmente en ServerProd y supongamos que el SMB que utilizaremos para los movimientos de datos será \\serverprod\backup.

Primeros pasos

Lo primero que debemos hacer para que el montaje funcione es asegurarnos que la base de datos está configurada con RecoveryMode=Full, tal como vemos en la imagen siguiente:

sql server DR

Una vez tenemos la base de datos configurada en RecoveryMode=Full, configuraremos la sección “Transaction Log Shipping”. Para ello, habilitaremos la base de datos como base de datos primaria en una configuración de Log Shipping, tal como vemos en la siguiente imagen:

SQL SERVER DR

Tras habilitar la base de datos como “primary database”, haremos clic en el botón “Backup Settings” para configurar la ubicación de los backups y la frecuencia de estos.

Como podemos ver en la captura anterior, hemos configurado la ruta SMB sobre la que se han de realizar los backups del transactional log. Además, hemos definido una duración de 24 horas para los backups. Es decir, que cada vez que el Job de backup se ejecute, también se encargará de eliminar los backups en la ruta SMB que tengan una fecha de creación mayor de 24 horas. También hemos definido que queremos un backup cada 15 minutos. Según las necesidades de tu DR, esos valores se deberán modificar a otros que se ajusten más a vuestras necesidades. Una vez establecidos esos valores, aceptaremos la configuración y pasaremos al siguiente paso.

Instancias reservadas en SQL Server

Ahora añadiremos las instancias de SQL Server que harán de replicas secundarias de nuestra base de datos. En este mini tutorial, usaremos sólo una instancia secundaria, pero recuerda que comentamos anteriormente que se podrían utilizar más instancias como replicas secundarias.

En todo caso, haremos clic en el botón “Add” para añadir las instancias que queremos. En nuestro caso se trata de una instancia ubicada en otro Datacenter. Por cada instancia, deberemos configurar las siguientes características.

Aquí seleccionaremos la forma en la que la base de datos debe ser iniciada en la instancia secundaria. Nosotros queremos que haga un backup full sobre la base de datos, lo mueva a ServerDR a través del SMB y la restaure en la instancia secundaria. Así que seleccionaremos la opción que podemos ver en la imagen anterior.

Configurar la ruta local en ServerDR

Ahora, vamos a configurar la ruta local en ServerDR en la que queremos copiar los ficheros de transacciones, que se vayan moviendo a través del SMB. En este caso, se trata de la ubicación por defecto para los backups en ServerDR . Además, especificamos que ServerDR debe eliminar también de esa ubicación los backups cuya fecha de creación sea anterior a 24 horas antes. Nuevamente, dependiendo de las características de tu DR, deberías cambiar estos valores a unos que se ajusten mejor a vuestras necesidades.

Por último, configuraremos la forma en la que los backups que vamos moviendo a ServerDR se van restaurando en esa instancia. Lo que queremos en este caso es que en ServerDR las bases de datos estén accesibles para lectura. De esta forma, si ServerProd cae y deja de ser accesible, al menos en ServerDR ya tendremos las bases de datos listas para al menos poder leer datos de ellas.

Para conseguir esto, debemos indicar en la configuración que las bases de datos deben quedarse en modo Standby. Nosotros, además, solemos indicar que queremos que se desconecte a los usuarios durante cada restore. Esto nuevamente dependerá de la forma en la que queramos usar nuestro DR, pero suele ser lo recomendable utilicemos el DR como base de datos de lectura o no.

Finalización

Una vez hayamos configurado todo, podremos finalizar el proceso. Nos aparecerá una ventana indicando el estado de las tareas iniciales llevadas a cabo por SQL Server para configurar nuestro DR. La creación de los Jobs en ambas instancias y la primera ejecución de estos. Debería verse algo así:

Llegados a este punto, ya deberíamos ver en nuestra instancia secundaria la base de datos y que, además, está en modo Standby. Con la base de datos en ese estado, podríamos realizar un SELECT sobre cualquiera de sus tablas, pero no podremos realizar ninguna tarea que implique la actualización o inserción de registros.

Sistema de monitorización en el DR

Hay otra cosa interesante que podemos configurar. Si tenemos un sistema de monitorización en nuestra empresa, podremos configurar que nos salte una alarma si los Jobs no están ejecutándose correctamente durante un periodo de tiempo específico. Habrás visto en dos de las capturas que hay un tiempo que no hemos mencionado, son estos dos:

  • Alert if no backup occurs within…
  • Alert if no restore occurs within …

Lo que configuramos aquí es interesante. Imaginemos que hemos configurado (de hecho, así ha sido) que los backups/restores se realicen cada 15 minutos. Voy a decir una obviedad, lo sé; con esa configuración, cada hora se realizarán 4 tareas de backup/restore.

Esos dos datos indican el tiempo a partir del cual, si no se ha hecho un backup/restore correcto, SQL Server hará saltar un error. Si lo configuramos a 1 hora, SQL Server lanzará un error si han fallado 4 backups/restore seguidos.

Jugando con estos valores, podemos ajustar la tolerancia a errores que queramos permitir. Personalmente no configuraría una alarma al primer error, puesto que podría ser circunstancial o, simplemente, no indicar una caída real de ServerProd. En todo caso, si para tu negocio es crítico alertar al primer error, no habría problema en configurarlo de ese modo.

La siguiente Query nos puede indicar también si existen problemas en los Jobs de replicación. Si ejecutamos ‘exec sys.sp_check_log_shipping_monitor_alert’ el comando nos retornará un “success” si no hay problemas de replicación o un error si sí los hay. Cuando hay errores, debemos consultar el monitor de Jobs para saber qué Job falló y por qué. Además, si hacemos clic con el botón derecho del ratón en la instancia, vamos a “reports”, veremos que tenemos un report por defecto de SQL Server que nos dará información sobre el estado de las replicaciones:

Conclusión

Como podéis ver, es relativamente sencillo montarlo. Suponiendo que las instancias están ya configuradas y la conectividad a nivel de networking es correcta, no debería llevarte más de 5-10 minutos configurar Log Shipping para una base de datos dada. Dependerá del tamaño de la misma, velocidad de los discos para realizar el backup y para el restore, velocidad de la conectividad de red, etc…. Pero, si aislamos todas esas variables, nos queda que el tiempo de intervención de un técnico no debería superar los 5-10 minutos, menos aún si lo tienes todo correctamente “scripteado”.

Si lo piensas, son 5-10 minutos que te salvarán de sufrir una catástrofe si el Datacenter donde está ServerProd sufre un desastre. Merece la pena el esfuerzo de investigar los diferentes modos de replicar datos que tenemos con SQL Server.

Personalmente os invito a que probéis todos los sistemas de replicación para comprobar cuál se ajusta más a vuestras necesidades. Y, sobre todo, presupuesto.

Hoy hemos tocado quizás el sistema de replicación más sencillo, pero también el que más se aleja del tiempo real en cuanto a la replicación de datos. Así que mi consejo es que juguéis con las diferentes combinaciones de configuración de cada sistema para ver cuál se ajusta mejor a vuestro negocio. Y sobre todo que apliquéis una cuanto antes; dormiréis mejor