Infra

16
Jun
2025

Azure Arc para SQL Server

Desde hace años, en cada evento, webinar o presentación de infraestructura de Microsoft se repite como un mantra: el futuro es híbrido. Y aunque muchos se limitan a asentir mientras piensan en cómo sobrevivir al próximo reinicio inesperado del servidor de producción, lo cierto es que algo de razón tienen. Especialmente cuando aparece una herramienta que, por una vez, parece estar pensada para los que aún tenemos servidores físicos, clústeres que no caben en una suscripción y dolores de cabeza por políticas de compliance que cambian más que los nombres de productos en Microsoft. Hablemos claro: Azure Arc para SQL Server on-premises no es la panacea, pero sí un paso sensato hacia un control centralizado sin obligarnos a renunciar al datacenter de toda la vida.

¿Qué demonios es Azure Arc (y por qué debería importarnos)?

Empecemos por el principio, ¿qué es Azure Arc? En resumen es la forma en que Microsoft intenta convencernos de que Azure no es solo «la nube», sino «la plataforma de gestión» para todos nuestros recursos, estén donde estén. Y eso incluye nuestros SQL Server instalados con sudor y lágrimas en máquinas físicas, clústeres locales o VM que jamás verán una IP pública.

Azure Arc extiende la gestión de Azure a recursos externos como servidores, Kubernetes, y por supuesto, SQL Server. Pero aquí viene la parte jugosa: Azure Arc para SQL Server no instala una nueva base de datos ni te obliga a migrar nada. Lo que hace es registrar tu instancia on-premises en Azure, otorgándole una especie de identidad en el portal.

Una vez enlazada, puedes aplicar políticas, ver inventario, tener visibilidad de cumplimiento de licencias (sí, esa parte duele), activar extensiones como Defender for SQL o habilitar seguimiento de seguridad desde el Azure Security Center. Todo sin tocar la base de datos. Bueno, casi.

Cómo funciona realmente Azure Arc (no la versión edulcorada del marketing)

Cuando conectamos una instancia de SQL Server a Azure Arc, lo que instalamos es un agente: el Azure Connected Machine Agent, junto con una extensión específica para SQL. Este agente se comunica con Azure a través de HTTPS, informa de configuraciones, recopila datos de diagnóstico y permite acciones remotas de configuración.

Para que funcione, necesitas tener SQL Server 2012 o superior, y una conexión de red desde el servidor hacia Internet (no hace falta conexión entrante, lo cual es un alivio). Lo ideal es tener SQL autenticado con Active Directory para poder controlar mejor el acceso, pero se puede hacer también con SQL Auth si quieres vivir al límite.

Una vez conectado, la instancia aparece en el portal de Azure como un recurso más. Desde ahí podemos aplicar políticas, revisar vulnerabilidades de seguridad, controlar el uso de features según la edición (lo cual es útil para evitar sorpresas desagradables con licencias), monitorizar comportamiento con Azure Monitor o, incluso, balancear nuestro Always On. Todo ello sin abrir el Management Studio… aunque claro, a veces sigue siendo necesario.

Casos reales donde Azure Arc tiene sentido (y donde no)

Supongamos que gestionamos un parque de 40 servidores SQL distribuidos entre varios centros de datos. Algunos son máquinas virtuales, otros físicos con clústeres Always On que llevan más tiempo activos que algunos desarrolladores del equipo. Sin Azure Arc, revisar políticas, aplicar auditorías o simplemente saber qué versión exacta está instalada en cada nodo puede convertirse en una gymkhana de RDPs.

Con Azure Arc, podemos tener una visión centralizada de todas las instancias, aplicar políticas uniformes, activar auditorías y obtener insights de seguridad con Defender sin tener que desplegar scripts o agentes por separado. Además, podemos detectar desviaciones de configuración o uso de features que podrían tener impacto en licencias.

Pero no todo es oro. Azure Arc no es una herramienta de administración del motor de SQL. No vas a hacer restores desde el portal ni crear índices con drag & drop. Tampoco es un sustituto de tus herramientas de backup, ni tiene visibilidad real sobre el rendimiento más allá de lo que Azure Monitor pueda recoger (que no es poco, pero tampoco es SentryOne).

Y lo más importante: si no tienes una estrategia clara de seguridad, gestión de red y control de agentes, puedes acabar con más puntos de fallo que beneficios. Porque, no nos olvidemos, instalar agentes y abrir tráfico a Internet en servidores productivos sin pensar en segmentación ni proxies es una receta para el desastre.

El control de licencias en Azure ARC: la parte que nadie quiere mirar

Una de las funcionalidades más interesantes (y más ignoradas) de Azure Arc para SQL Server es el control de licencias. Cuando registramos una instancia, podemos indicar si está licenciada por núcleo o por servidor + CAL. Esto, combinado con el escaneo de features activas, nos permite detectar incoherencias: como esa instancia Standard Edition que «accidentalmente» tiene particionamiento activo (Si, cuando el particionamiento era exclusivo de Enterprise en SQL 2012 esto se podía conseguir). Este control es especialmente útil en entornos con auditorías frecuentes o donde se aplican acuerdos Enterprise Agreement.

¿Y la seguridad? ¿Me estoy exponiendo a algo?

Buena pregunta. Azure Arc requiere ciertos permisos en el servidor, y abre un canal de comunicación constante con Azure. Esto plantea varias consideraciones. Primero, necesitas validar que el tráfico esté cifrado, que el agente esté actualizado, y que el acceso al servidor esté controlado. Segundo, si vas a permitir que ciertas acciones se realicen desde el portal (como cambiar configuraciones o aplicar actualizaciones), más vale que tengas RBAC bien definido en Azure.

La buena noticia es que puedes integrar todo con Azure Policy, Defender, y Log Analytics. La mala es que si no lo haces bien, estarás delegando más poder del que quieres. Y ya sabemos cómo acaba eso.
Azure Arc es gratis… hasta que abres Log Analytics

Una de las verdades menos comentadas de Azure Arc es que registrar tu instancia de SQL Server no cuesta nada. Literalmente: añadir un servidor, instalar el agente de Connected Machine y habilitar la extensión de SQL puede hacerse sin pasar por caja. Microsoft lo promueve como “coste cero” porque, en efecto, el recurso en sí no genera facturación directa.

Pero, siempre hay un pero, en cuanto queremos algo más que ver el nombre del servidor en el portal, empezamos a tirar de servicios que sí cuestan dinero. El más obvio es Log Analytics, que es el backend de todo lo que huela a monitorización seria en Azure. Activar monitorización de rendimiento, auditoría, logs extendidos, o integrar con Defender for SQL pasa irremediablemente por conectar a Log Analytics.

Y aquí viene el truco de magia inverso: el volumen de datos ingeridos, el tipo de consultas (KQL, por supuesto), y el tiempo de retención, todo suma en la factura. No es que Log Analytics sea especialmente caro, pero si estás monitorizando muchas instancias, con métricas detalladas y sin control de retención, la broma puede escalar.

Para tenerlo claro, Azure Arc proporciona el marco, pero no la observabilidad avanzada. Esa vive en Log Analytics, que sí factura. Y lo hace por cada giga ingerido. Si además activas Defender, tienes otro coste adicional por nodo protegido.

¿Merece la pena? 

Esta es la pregunta clave que debes hacerte, si tu entorno tiene requisitos serios de auditoría, cumplimiento, o simplemente quieres centralizar trazabilidad sin herramientas externas, probablemente sí. Pero conviene dimensionarlo bien, ajustar las retenciones, y entender qué datos necesitas realmente antes de abrir el grifo

Este modelo freemium no es nuevo, pero conviene recordarlo: Azure Arc para SQL Server es gratis solo si lo usas como un cartel informativo. Si quieres que hable, escuches y analices, tendrás que pasar por caja.

Conclusión

Azure Arc para SQL Server on-premises es una de esas herramientas que, bien usada, puede marcar una diferencia seria en entornos complejos. Centralizar visibilidad, aplicar políticas, y tener un inventario completo con insights de seguridad no es poca cosa. Pero, como siempre, depende de cómo se implemente.

Si ya tienes una infraestructura ordenada, con buenas prácticas de seguridad, y buscas unificar la gestión sin perder el control, Arc es una opción potente. Si tu entorno es un castillo de naipes sostenido por scripts heredados y manuales en PDF de 2009, lo mejor es empezar por ahí antes de añadir más complejidad.

Porque sí, el futuro puede ser híbrido. Pero nosotros queremos que lo sea con cabeza, no con más capas de problemas. Azure Arc no es magia, pero tampoco es humo. Y eso, hoy en día, ya es mucho decir.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima! 

Publicado por Roberto Carrancio en Cloud, SQL Server, 0 comentarios
04
Jun
2025

¿Qué es xp_cmdshell y por qué deberías limitar su uso?

Hay ciertas funciones en SQL Server que tienen más leyenda que documentación, y una de ellas es xp_cmdshell. Mencionarla en una reunión de seguridad es como decir “TRIGGER” en una daily de DBAs: inmediatamente empiezan los sudores fríos. Pero como buenos profesionales de bases de datos, no podemos permitirnos el lujo de ignorarla. Hay que entender qué hace, cómo se usa (o se abusa), y sobre todo por qué en la mayoría de los casos deberíamos tenerla bien atada, o mejor aún, desactivada.

¿Qué es xp_cmdshell?

Para los recién llegados (o para los que han tenido la suerte de no cruzárselo nunca), xp_cmdshell es un extended stored procedure que permite ejecutar comandos del sistema operativo directamente desde SQL Server. Tal cual. Es decir, desde una sesión de SQL puedes invocar comandos como si estuvieras en la consola de Windows: copiar ficheros, lanzar scripts batch, ejecutar aplicaciones externas… o destruir medio sistema si tienes permisos suficientes y pocas luces.

El siguiente ejemplo es inocente (más o menos), pero ilustra la idea:

EXEC xp_cmdshell 'dir C:\';

SQL ejecuta el comando y te devuelve el resultado como si estuvieras en una consola de MS-DOS de los 90. Y sí, es tan peligroso como suena.

¿Para qué se usa xp_cmdshell legítimamente?

Hay quien justifica su uso con casos reales: automatización de procesos que interactúan con el sistema de archivos, lanzamiento de tareas administrativas, scripts que integran SQL con otros procesos batch o herramientas de terceros. Incluso estos ojos han visto escenarios donde se usaba para invocar clientes FTP y descargar archivos que luego se importaban con BULK INSERT o mover backups entre servidores.

Y aunque todo esto se puede hacer, la pregunta es: ¿debería hacerse así? Spoiler: no. O al menos, no sin un análisis serio de riesgos y alternativas. Porque una cosa es poder, y otra muy distinta es tener criterio.

La seguridad, el verdadero problema de xp_cmdshell

El mayor problema de xp_cmdshell no es su existencia, sino su potencia. Ya sabes, eso de que un gran poder conlleva una gran responsabilidad. Este procedimiento ejecuta los comandos en el contexto de seguridad de la cuenta del servicio de SQL Server, lo que, si no se ha configurado adecuadamente, puede significar ejecutar con privilegios elevados. Y eso convierte cualquier brecha de seguridad en una puerta abierta al sistema operativo, red y mil cosas más.

Por defecto, xp_cmdshell viene desactivada. Microsoft no es tonta, y sabe que dejar esto habilitado por defecto sería como enviar servidores a producción con el firewall desactivado. Pero como casi todo en SQL Server, se puede activar fácilmente:

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;

Y una vez activada, el riesgo está servido. Cualquier usuario que tenga permisos para ejecutarla puede comprometer el servidor. Si encima tiene permisos sysadmin (y aún hay entornos donde todo el mundo es sysadmin «porque así funciona»), la fiesta está asegurada.

¿Se puede usar xp_cmdshell de forma segura?

La teoría dice que sí. Microsoft introdujo ciertas medidas para controlar su uso. Por ejemplo, si el usuario no es sysadmin, se puede configurar una cuenta proxy mediante el procedimiento almacenado sp_xp_cmdshell_proxy_account que limita los permisos con los que se ejecutan los comandos.

EXEC sp_xp_cmdshell_proxy_account 'DOMINIO\usuario', 'contraseña_segura';

Esto permite definir una credencial para que el comando xp_cmdshell se ejecute con los permisos de ese usuario en lugar de usar la cuenta del servicio. Pero seamos serios: ¿cuántas veces se hace esto bien en entornos reales? ¿Cuántas veces se revocan luego los permisos cuando ya no hacen falta? ¿Y cuántos servidores en producción tienen la proxy account configurada pero también usuarios sysadmin “temporales” que llevan ahí desde 2016?

Además, aunque configures la cuenta proxy correctamente, sigue siendo un punto de entrada que puede explotarse si no se audita y controla su uso. El riesgo persiste, solo se disfraza de buena práctica.

Alternativas reales y razonables a xp_cmdshell

Casi todo lo que se hace con xp_cmdshell se puede hacer mejor y con más control desde fuera de SQL Server. Si necesitas mover archivos, usar PowerShell o scripts externos lanzados desde un agente de automatización como SQL Server Agent o un sistema de orquestación decente (¿alguien ha dicho Azure Data Factory?) es mucho más razonable.

Para transferencias FTP o SFTP, hay herramientas modernas que no requieren meter comandos del sistema operativo en medio del motor de base de datos. Y si lo que se busca es coordinación entre procesos, los servicios de Windows, los job schedulers o incluso Integration Services son alternativas mucho más limpias.

SQL Server es un motor de bases de datos, no un sistema operativo ni un centro de comandos. Empezar a usarlo como tal es como usar un bisturí para abrir latas: técnicamente se puede, pero no es lo suyo y probablemente acabes con un desastre.

Auditar, controlar, eliminar

Si estás heredando un sistema y no sabes si xp_cmdshell está activa, revísalo. Yo personalmente es de las primeras cosas que compruebo. Para verlo es tan fácil como ejecutar:

EXEC sp_configure 'xp_cmdshell';

Si el valor de «config_value» es 1, está habilitado. Si no se está utilizando (y muchas veces no lo está, pero nadie se atreve a desactivarla “por si acaso”), desactívalo sin piedad:

EXEC sp_configure 'xp_cmdshell', 0;
RECONFIGURE;

Y si alguien protesta, que traiga el caso de uso documentado, el análisis de riesgos y una alternativa propuesta. Si no puede justificarlo, no es necesario. Punto. No admito discusiones.

Además, si en algún entorno necesitas activarlo temporalmente, documenta cuándo y por qué, y asegúrate de desactivarla después. Y lo más importante: registra quién tiene permisos para usarlo, y controla ese acceso como si fuera el código para activar el botón rojo nuclear. Porque en cierto sentido, lo es.

Conclusión

xp_cmdshell es una herramienta poderosa, pero como todas las herramientas poderosas, puede causar más daño que beneficio si se usa mal. No está pensada para ser parte habitual de ningún flujo de trabajo moderno en SQL Server. Su existencia tiene sentido en contextos muy controlados, con auditoría, justificación y planificación. Pero la realidad es que en la mayoría de los entornos en los que aparece, lo hace como un parche rápido, una chapuza heredada o un atajo que algún valiente implementó sin medir consecuencias.

Limitar o eliminar su uso no solo mejora la seguridad del entorno, sino que obliga a buscar soluciones más sostenibles, limpias y profesionales. Porque si nuestra base de datos necesita ejecutar scripts del sistema para funcionar, igual el problema no está en xp_cmdshell, sino en cómo hemos diseñado la arquitectura.

Y si aún piensas que «no pasa nada por tenerla habilitada», revisa tus backups. Puede que los necesites antes de lo que crees, o que alguien los haya borrado desde xp_cmdshell.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en SQL Server, 0 comentarios
26
May
2025

ZSTD en SQL Server 2025: la compresión que por fin tiene sentido

Con SQL Server 2025, Microsoft ha decidido que ya era hora de dejar atrás el vetusto algoritmo MS_XPRESS para la compresión de backups y nos presenta a su nuevo juguete: Zstandard, o ZSTD para los amigos. No se trata de una mejora menor ni de un simple lavado de cara. Estamos ante un cambio real, tangible y, lo más importante, medible. Porque ya está bien de hacer backups comprimidos que no se sabe si salvan espacio o lo rellenan de aire.

En este artículo nos meteremos de lleno en las pruebas reales de rendimiento y compresión usando este nuevo algoritmo en la versión preliminar de SQL Server 2025 (17.x). Y sí, he hecho los deberes: mismo entorno, misma base de datos, mismas condiciones. Porque si vamos a hablar de rendimiento, hay que hacerlo como profesionales, no como vendedores de humo.

Un poco de contexto en esto de la compresión (pero solo el justo)

Hasta ahora, la compresión de backups en SQL Server se basaba principalmente en MS_XPRESS, ese algoritmo que venía con SQL Server y que, siendo honestos, cumplía. Pero cumplía como un coche de hace 20 años: te lleva, pero consume más de lo que debería y no gana ninguna carrera.

SQL Server 2025 introduce ZSTD como nuevo algoritmo de compresión, y según la propia documentación oficial, se trata de un método más rápido y más eficaz. No es marketing barato: ZSTD lleva años siendo la niña bonita del mundo open source, utilizado en proyectos como Facebook, zfs o Kubernetes. Y ahora por fin aterriza en SQL Server.

Escenario de pruebas: sin cuentos

He estado leyendo e intercambiando opiniones con otros compañeros MVPs de Microsoft y algunas pruebas les arrojaban reducciones de tiempo de hasta un 50%. Yo tenía que probarlo, y además he utilizado la base de datos StackOverflow2013 para las pruebas. Una base de datos con más de seis millones de páginas de datos (más de 50Gb) suficiente para ver diferencias significativas. Además con campos de texto grandes y pocos valores nulos o repetidos, cosas que siempre han puesto en aprietos a la compresión de SQL Server. Todo un reto para el nuevo algoritmo.

Todas las pruebas las he ejecutado en la misma instancia de SQL Server 2025 CTP 2.0, con la base de datos restaurada entre cada backup para mantener la consistencia. Ni trucos, ni trampa, ni memoria caché jugando sucio.

Backup tradicional con compresión MS_XPRESS

Para esta primera prueba vamos a realizar un backup con la comprensión tradicional de SQL Server para saber contra qué estamos comparándonos.

BACKUP DATABASE [StackOverflow2013]
TO DISK = N'C:\Program Files\...\StackOverflow2013.bak' 
WITH NOFORMAT, NOINIT, SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10;
Compresion-MSXPRESS

Resultados:

  • Tiempo total: 327 segundos
  • Velocidad media: 147.289 MB/seg
  • Tamaño comprimido: 14.84 GB

Backup nuevo con compresión ZSTD

Llega el momento de la verdad, ahora que ya tenemos una base sobre la que mejorar vamos a probar con el nuevo algoritmo de compresión de backups ZSTD.

BACKUP DATABASE [StackOverflow2013]
TO DISK = N'C:\Program Files\...\StackOverflow2013_ZSTD.bak'
WITH NOFORMAT, NOINIT, SKIP, NOREWIND, NOUNLOAD, COMPRESSION (ALGORITHM = ZSTD), STATS = 10;
Compresión ZSDT

Resultados:

  • Tiempo total: 300 segundos
  • Velocidad media: 160.092 MB/seg
  • Tamaño comprimido: 14.51 GB

Sí, has leído bien: más rápido y más comprimido. Porque para eso se inventan los algoritmos modernos, no para rellenar documentación técnica.

¿Y el espacio en disco? ¿Realmente hay más compresión?

Aquí no hay opiniones: hay archivos .bak. Si miramos los tamaños de las copias que acabamos de hacer estos son los datos:

  • MS_XPRESS: 14.498.432 KB
  • ZSTD: 14.169.192 KB

En torno a 329 MB menos por backup. Insisto: suma eso en entornos de alta frecuencia y multiinstancia, y deja que el almacenamiento te dé las gracias.

Compresión tamaños

Restauraciones

También he restaurado ambas copias para verificar si hay diferencias apreciables en el proceso inverso. Al fin y al cabo, para eso hacemos backups. Y normalmente, cuando restauramos una copia de seguridad lo hacemos con prisa, no me preguntes por qué.

Compresión Restore
Compresión ZSDT Restore

En este sentido, la copia con el algoritmo de compresión tradicional MS_XPRESS ha tardado 377 segundos, restaurando a 127.763 MB/seg. Por su parte, la copia con el nuevo algoritmo ZSTD se ha restaurado en 361 segundos a una media de 133.328 MB/seg. 

Una diferencia de rendimiento modesta, pero constante, a favor de ZSTD. No rompe récords, pero definitivamente no es humo. 

Relación de compresión

Veamos por último la relación de compresión de nuestras copias. Esto podemos verlo directamente de msdb.dbo.backupset con una sencilla consulta.

SELECT database_name, compression_algorithm, backup_size, compressed_backup_size, backup_size / compressed_backup_size AS CompressRatio
FROM msdb.dbo.backupset
WHERE database_name = 'StackOverflow2013';
Relación Compresión

Tampoco estamos ante un milagro, pero la mejora es real. Y si alguien piensa que medio punto en ratio de compresión no importa, que multiplique eso por 500 bases de datos diarias y hablamos. Además, recuerda, el ejemplo que he usado es de los menos favorables para una compresión.

Cómo habilitar la compresión ZSTD (cuando funcione bien)

ZSTD se puede usar de dos formas, la forma explícita que acabamos de ver, indicando el algoritmo en el comando BACKUP WITH COMPRESSION (ALGORITHM = ZSTD) o bien configurando el servidor para usarlo como valor predeterminado. Para eso lo definiremos en la configuración con este comando:

EXEC sp_configure 'backup compression algorithm', 3;
RECONFIGURE;

Ahora bien, aquí viene la parte divertida (léase con sarcasmo): actualmente hay un bug conocido en la configuración global. Es decir, puedes especificarlo manualmente sin problema, pero si intentas poner ZSTD como predeterminado a través del sp_configure, el sistema puede ignorar olímpicamente. No lo decimos nosotros, lo dice la propia documentación oficial de Microsoft en letras púrpuras. Nada grave sabiendo que aun es una versión preliminar.

Así que por ahora, mejor dejar ese WITH COMPRESSION (ALGORITHM = ZSTD) bien escrito en los scripts de mantenimiento y olvidarse de configuraciones globales hasta que alguien en Redmond se acuerde de arreglarlo antes de la disponibilidad general del producto.

Conclusión

ZSTD ha llegado a SQL Server y no como un simple añadido, sino como una alternativa seria al clásico MS_XPRESS. Mejora el rendimiento, reduce el tamaño y lo hace sin pedir permiso ni romper nada. ¿Es perfecto? No. ¿Está listo para producción? Aún no, está en preview. ¿Vale la pena probarlo? Sin duda.

En mis pruebas ha demostrado ser más eficiente, más rápido y ligeramente más eficaz en términos de compresión. Y si Microsoft arregla ese problemilla con la configuración global, puede convertirse en el nuevo estándar para backup en SQL Server.

Así que, si estás probando SQL Server 2025, ya estás tardando en incluir ZSTD en tus scripts. Y si aún sigues con backups sin compresión porque “es más seguro así”, quizás también sigas usando cintas magnéticas. En fin.

Yo por mi parte, ya lo tengo apuntado en el check de “cosas que sí merecen la pena en esta versión”. Habrá que ver si termina estando disponible en SQL Server Standard o solo en las versiones Enterprise.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en SQL Server, 0 comentarios
21
May
2025

Antivirus en servidores SQL Server: ni sin él, ni contra él

Cuando hablamos de proteger un entorno SQL Server, lo primero que nos viene a la cabeza suelen ser los backups, la alta disponibilidad, los roles de seguridad, incluso el cifrado. Pero curiosamente, uno de los elementos más básicos de la protección –el antivirus– sigue siendo tratado como un accesorio molesto, o lo que es peor, como una amenaza potencial para el rendimiento. Y claro, en ese dilema entre seguridad y rendimiento, muchas veces se acaba apostando por el camino más cómodo: desactivar o ignorar.
No vamos a defender aquí que el antivirus es la piedra angular de la seguridad (no lo es), pero tampoco podemos dejar que el miedo a una caída de rendimiento justifique decisiones negligentes. Lo que necesitamos es un enfoque racional: configurar el antivirus de forma que proteja sin interferir con la operación normal del motor de base de datos. *Spoiler*: se puede. Lo difícil es que alguien lo haga bien.

¿Qué hace el antivirus y por qué molesta (si lo dejamos)?

El trabajo del antivirus es inspeccionar archivos y procesos en busca de patrones maliciosos. Nada nuevo. Lo que sí suele pasarse por alto es *cómo* lo hace: analiza archivos al abrirse, al modificarse, y en ocasiones al cerrarse. También puede inspeccionar procesos en memoria, acceder a redes compartidas, lanzar escaneos programados… y todo eso suena bastante normal hasta que lo dejas funcionando en un servidor SQL Server con una carga seria.
Porque claro, cuando el antivirus decide inspeccionar `tempdb.mdf` mientras el motor está haciendo un `HASH JOIN` como si no hubiera un mañana, empieza la fiesta: bloqueos, ralentizaciones, timeouts y, si tenemos suerte, algún bonito `IO_COMPLETION` en el error log. Y no olvidemos el momento en que el antivirus escanea los archivos `.ldf` en pleno `checkpoint`. Porque sí, todo archivo es sospechoso, incluso los que cambian cien veces por segundo.
El problema no es el antivirus. El problema es no configurarlo.

Archivos y procesos que debemos excluir

Vamos al grano. Hay una serie de rutas, extensiones y procesos que deben quedar fuera del radar del antivirus si queremos mantener la estabilidad y el rendimiento del servidor SQL Server. No es opcional. No es debatible. Está documentado por Microsoft, y si no lo aplicas, estás jugando a la ruleta rusa con discos girando.
Empezamos por los archivos:
– Las bases de datos, claro: archivos `.mdf`, `.ndf` y `.ldf`. Eso incluye todas las rutas donde se ubiquen, incluyendo `tempdb`. Da igual si están en discos SSD, en cabinas SAN o en la nube: fuera del antivirus.
– Los archivos de backup: `.bak`, `.trn`, `.sqb`, `.dif`, etc. Si el antivirus decide escanear un `.bak` de 500 GB en pleno restore, luego no nos preguntemos por qué tarda 2 horas más de lo previsto.
– Los archivos de trace, log y dumps generados por SQL Server (`.xel`, `.trc`, `.dmp`). Algunos de ellos se escriben en caliente, y otros pueden ser enormes.
– Las rutas de instalación de SQL Server y sus binarios (`sqlservr.exe`, `sqlagent.exe`, etc.). Los procesos de SQL no deberían ser intervenidos por el antivirus, especialmente durante eventos como reinicios o cambios de configuración.
También conviene excluir herramientas relacionadas que trabajen cerca del metal, como agentes de backup de terceros (Veeam, Commvault, etc.), soluciones de monitorización, y carpetas temporales utilizadas en procesos ETL, especialmente si están en el mismo servidor.
Y por supuesto: nada de escaneos programados sobre las unidades donde residen estos archivos. ¿Queremos una caída de rendimiento nocturna «espontánea»? Pues eso.

El antivirus SI tiene cabida en un servidor SQL

Llegados a este punto, alguien siempre pregunta: «¿Y si directamente no pongo antivirus?». Bueno, también puedes dejar la puerta del CPD abierta por si alguien quiere entrar a ver qué hay. Todo es cuestión de prioridades.
Un servidor SQL Server, aunque no navegue por Internet, puede estar expuesto a amenazas reales. Las vías de entrada son múltiples: conexiones RDP inseguras, accesos compartidos, usuarios que suben archivos, integraciones con sistemas vulnerables, incluso malwares que viajan dentro de backups. Y no olvidemos el ransomware, que no necesita un navegador para hacer su trabajo. Lo único que necesita es una puerta entreabierta.
Así que sí, el antivirus es necesario. Pero como con cualquier otra herramienta, hay que usarla con cabeza.

Buenas prácticas de configuración del antivirus

Ya sabemos qué excluir, pero ¿qué más podemos hacer para convivir con el antivirus sin odiarlo?
Lo primero, usar soluciones corporativas que permitan configurar políticas centralizadas. Nada de versiones domésticas ni «freemium» que prometen IA mágica y acaban con el 30% de tu CPU. Necesitamos un antivirus que permita gestionar exclusiones, programar escaneos fuera del horario de carga, y monitorizar actividad sin interferir con los procesos críticos.
Lo segundo, documentar las exclusiones. Es increíble la cantidad de veces que se instala un nuevo motor, se configura bien, y meses después alguien cambia el antivirus o actualiza políticas sin revisar nada. Resultado, el rendimiento se degrada, y nadie sabe por qué. Tener un documento claro con las rutas y configuraciones esenciales debería ser parte del estándar de despliegue.
Tercero, coordinar con el equipo de seguridad. Sí, esos que mandan correos con gráficos de amenazas que nadie entiende. Hablad con ellos. Enseñadles los KB de Microsoft. Explicad por qué hay que excluir ciertos archivos. Si lo hacéis bien, es posible que incluso lo agradezcan. Al final, todos queremos lo mismo, que el sistema esté seguro y funcione bien.
Y por último, revisar con cada parche o actualización. Las rutas cambian, las versiones cambian, y lo que funcionaba en SQL Server 2016 puede no ser igual en 2022. La tecnología cambia más deprisa que las excusas para no leer la documentación.

Recursos recomendados (y válidos)

Si alguien necesitas pruebas documentales para convencer al comité de seguridad, que tire de lo oficial. Microsoft tiene un artículo actualizado con las exclusiones recomendadas para SQL Server que puedes encontrar aquí.
También hay buenas prácticas en la documentación de cada solución antivirus empresarial. Lo importante es no quedarse en lo básico: si hay un `.exe` que escanea un `.mdf`, eso es un problema.

Conclusión

El antivirus en un servidor SQL Server no es el enemigo. El enemigo es la ignorancia operativa. Dejar un antivirus sin configurar es tan irresponsable como dejar que todo el mundo sea `sysadmin`. Y no, no exageramos.
Podemos tener rendimiento y seguridad. Pero como casi todo en esta vida (excepto los planes de licenciamiento de Microsoft), requiere esfuerzo. Excluir bien, revisar políticas, hablar entre equipos y no asumir que las cosas «ya vienen bien puestas».
Si seguimos confiando en que el antivirus «sabrá lo que hace», luego no nos sorprendamos si decide escanear `master.mdf` en mitad de un failover. Porque ya lo hemos dicho antes: el antivirus no es malo. Lo malo es dejarlo pensar por sí mismo.
Y no, no vamos a acabar este artículo diciendo que “la seguridad empieza por uno mismo”. La seguridad empieza por no meter la pata.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima! 

Publicado por Roberto Carrancio en Rendimiento, SQL Server, 1 comentario
20
May
2025

SQL Server 2025: IA dentro del motor, T-SQL como interfaz para modelos, y SSMS 21

Por fin tenemos motivos sólidos para decir que esta versión no es otra iteración sin alma. SQL Server 2025 no se limita a una lista de mejoras de rendimiento, ni a tres nuevos tipos de índice que nadie usará hasta dentro de tres años. Aquí estamos ante un cambio de paradigma: el motor se vuelve semánticamente inteligente, el T-SQL habla con modelos de IA, y SSMS deja de vivir anclado en 2012. Todo esto sin que tengamos que reescribir la mitad de nuestra lógica de negocio. Milagro.

Buscando con IA, sin sacar los datos de la base

Hasta ahora, hacer vector search implicaba montar un servicio aparte, duplicar datos, sincronizar embeddings y cruzar los dedos para que todo estuviera alineado. Bien, pues eso se ha acabado. SQL Server 2025 incorpora búsqueda vectorial directamente en el motor, usando como base el algoritmo DiskANN (Disk Approximate Nearest Neighbor) para encontrar similitudes de forma eficiente.

Y no solo eso: el motor genera embeddings y fragmenta texto (chunking) como parte de T-SQL. Nada de pipelines raros ni servicios auxiliares. El motor habla semánticamente, y por fin podemos dejar de fingir que los LIKE ‘%palabra%’ son soluciones de búsqueda.

Imagina buscar documentos similares, tickets de soporte parecidos o patrones repetidos en logs… sin tener que montar un Frankenstein con Python, Redis y una esperanza. Aquí, directamente desde SQL Server.

T-SQL como orquestador de modelos

Otra joya que han metido: los modelos de IA se definen y consumen desde T-SQL, y se accede a ellos mediante REST. Esto permite conectar con Azure OpenAI, Azure AI Foundry, Ollama, HuggingFace o cualquier servicio que hable HTTP.

Pero la parte realmente interesante es que puedes probar distintos modelos sin cambiar el código T-SQL, simplemente apuntando a otro endpoint. Es decir: pruebas, evalúas, decides… y el código sigue funcionando como si nada. Esto convierte a SQL Server en un auténtico hub de orquestación para IA aplicada a los datos.

Sí, a esto lo han llamado “AI integration”, pero no es humo de marketing: esto es infraestructura real para desarrolladores y DBAs que no tienen tiempo para montar castillos de arena en cada nuevo proyecto.

RAG con sentido: integración nativa con LangChain y Semantic Kernel

Otra novedad clave: SQL Server 2025 incluye soporte nativo para patrones de RAG (Retrieval-Augmented Generation). Lo que antes requería montar conectores desde LangChain, ahora se hace con integración directa. Embeddings, índices vectoriales, chunking… todo desde el motor. LangChain y Semantic Kernel pueden consumir directamente los datos sin malabares.

Esto significa que puedes montar aplicaciones conversacionales, asistentes internos o flujos inteligentes que consulten tus datos empresariales sin tener que exportarlos a ninguna otra base. Tus datos siguen seguros, tu rendimiento también, y tu aplicación parece inteligente.

SSMS 21:  Git, Copilot y 64 bits… y no es broma

SQL Server Management Studio 21 ha salido del túnel del tiempo. Basado en Visual Studio 2022, ahora es una aplicación nativa de 64 bits (ya era hora), con actualizaciones automáticas (gracias, por fin) y soporte directo para Git.

Y lo mejor: Copilot ya está integrado (en preview). Lo puedes instalar como workload adicional, y te ayuda a:

  • Escribir y corregir T-SQL con lenguaje natural.
  • Generar scripts de mantenimiento.
  • Explicar consultas y sugerir optimizaciones.
  • Administrar configuraciones complejas con algo de contexto real.

¿Sustituye a un DBA con criterio? Ni de lejos. Pero es una ayuda decente que, usada con cabeza, puede acelerar muchas tareas del día a día. O al menos, evitar que tengamos que explicar por enésima vez qué hace un LEFT JOIN.

Python, JSON y expresiones regulares: tres cosas que ya no dan vergüenza

Se ha anunciado también un nuevo driver Python open source, desde cero, eficiente, moderno y mantenido por Microsoft. Olvida los hacks sobre ODBC: esto es serio, y se instala con pip install.

Y sí, JSON ahora se soporta de forma nativa en T-SQL. Ya era hora. Por fin podemos trabajar con documentos sin castings ni funciones intermedias. Lo mismo con RegEx: expresiones regulares nativas, sin tener que invocar CLR ni enviar los datos a PowerShell.

Esto desbloquea muchos escenarios de enriquecimiento de datos, validación y transformación dinámica, sin salir del entorno SQL.

Change Event Streaming: eventos sin CDC (ni drama)

Una joya más: Change Event Streaming permite emitir eventos directamente desde el transaction log a Azure Event Hubs, sin usar CDC. Esto no solo reduce la sobrecarga de I/O, sino que habilita arquitecturas reactivas mucho más limpias.

Puedes montar sistemas en tiempo real, agentes inteligentes que reaccionan a eventos de negocio, y todo con trazabilidad real. Y sin romperte la cabeza con triggers que nadie quiere mantener.

Rendimiento, disponibilidad y seguridad: seguimos afinando el motor

SQL Server 2025 incluye más de 50 mejoras en el motor, muchas de ellas en HADR, Columnstore, y procesamiento inteligente. Entre ellas:

  • Optimized Locking con TID Locking y Lock After Qualification, para reducir consumo de memoria y minimizar bloqueos.
  • Query Store disponible en secundarios de solo lectura, algo que llevábamos pidiendo años.
  • Mejoras en Intelligent Query Processing que aportan rendimiento sin tocar el código (veremos si los milagros existen o no).
  • Compatibilidad total con Microsoft Entra ID, para usar identidades gestionadas de forma segura y sin líos.

Y sí, sigue siendo la base de datos más segura según NIST. Ya no hace falta decirlo, pero está bien recordarlo por si alguien pregunta.

Fabric y la analítica sin ETL (casi)

SQL Server 2025 soportará database mirroring en Microsoft Fabric, permitiendo que los datos operacionales estén disponibles para análisis en tiempo casi real sin mover una sola tabla. No es exactamente magia, pero se le parece. Un puente directo entre operaciones y analítica, sin romper nada.

Developer Edition Standard: pruebas con realismo

Una novedad muy práctica: nueva Developer Edition Standard, gratuita pero limitada a las capacidades de la edición Standard. Ideal para probar comportamientos y validar configuraciones sin necesidad de recurrir a hacks ni entornos de “prueba/producción camuflada”.

Conclusión

SQL Server 2025 no es un service pack disfrazado. Es un cambio real, tanto en cómo usamos el motor como en cómo lo extendemos. La IA no es un complemento, es parte del core. Y eso nos obliga a entenderla, usarla y evaluarla con el mismo rigor con el que optimizamos un índice o afinamos una transacción.

Copilot ayuda, pero no sustituye. Las búsquedas vectoriales abren un nuevo paradigma, pero siguen requiriendo estructura y lógica de negocio. Y SSMS 21… bueno, al menos ya no se siente como una aplicación de otra década.

¿Vamos a activar todo esto en producción mañana? No. ¿Vale la pena empezar a probarlo y adaptarse? Sin duda. Y si queréis ver ejemplos reales, scripts de prueba y escenarios que no salen en las demos de marketing, os espero por aquí. Como siempre, alguien tiene que hacer las pruebas que importan.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima! 

Publicado por Roberto Carrancio en Cloud, SQL Server, 0 comentarios
19
May
2025

Versiones de SQL Server en Amazon AWS

Cuando hablamos de SQL Server en AWS, lo primero que debemos hacer es dejar atrás esa idea ingenua de que “en la nube todo es más fácil”. No, no lo es. Solo es diferente, y en muchos casos, más complejo. Porque cuando mezclamos la gestión de SQL Server con la selva de servicios de AWS, las posibilidades se multiplican… junto con los puntos de fallo. Así que vamos a desgranar, con precisión quirúrgica y sin evangelismos nublados por el marketing, qué opciones reales tenemos cuando queremos desplegar SQL Server en Amazon Web Services.

SQL Server en AWS: más allá del “lift and shift”

Hay dos grandes formas de ejecutar SQL Server en AWS: usar máquinas virtuales (EC2) o servicios gestionados (principalmente RDS). Y sí, hay matices, capas y excepciones, pero si no entendemos esta dicotomía básica, mejor volvemos a estudiar para el examen de certificación.

En esencia, EC2 nos da el control total (y la responsabilidad completa). RDS nos quita dolores de cabeza, pero también libertad. ¿Queremos hacer magia negra con xp_cmdshell, afinar a mano el maxdop, o aplicar un Service Pack que aún no ha salido oficialmente? Entonces EC2. ¿Preferimos que AWS se encargue de los backups, los parches y la alta disponibilidad con solo marcar unas casillas? RDS es nuestro nuevo amigo.

Amazon AWS EC2 con SQL Server: libertad para vivir al límite

Al desplegar SQL Server en instancias EC2, estamos hablando de IaaS de libro. Tú eliges el sistema operativo (Windows, claro, porque hablamos de SQL Server), tú instalas SQL Server, tú configuras todo. También tú lo rompes y lo arreglas.

La ventaja evidente es que puedes usar cualquier edición de SQL Server: Express, Web, Standard o Enterprise. Puedes traer tu propia licencia (BYOL, Bring Your Own License) o usar las licencias incluidas en la AMI (Amazon Machine Image) oficial con licencia de pago por uso.

Esta opción brilla en entornos que necesitan configuraciones exóticas o donde el cumplimiento normativo exige control absoluto sobre el sistema. También en arquitecturas donde SQL Server no está solo, sino embebido en un sistema complejo que se despliega como un todo.

¿El coste? Altísimo si no controlamos los recursos. Sí, puedes tener una r6i.16xlarge para presumir, pero luego no te quejes cuando el informe mensual de AWS te haga llorar más que un RAISERROR con severidad 25.

Amazon AWS RDS para SQL Server: el camino del zen (limitado)

RDS (Relational Database Service) ofrece SQL Server como servicio gestionado. Lo eliges desde la consola, eliges la edición, el tamaño, las opciones de almacenamiento, y listo: tienes una instancia SQL Server “as a service”.

Aquí puedes elegir entre las ediciones Web, Standard y Enterprise. Express solo está disponible en RDS para desarrollo y pruebas muy básicas. Las versiones van desde SQL Server 2012 hasta 2022, aunque las más antiguas ya huelen a rancio y deberían estar fuera de toda conversación seria.

AWS se encarga del parcheo, los backups automáticos, la monitorización con CloudWatch, la alta disponibilidad con Multi-AZ, y hasta de restaurarte una base de datos si te la cargas (dentro del periodo de retención). Muy cómodo, sí. Pero el precio de esa comodidad es la limitación.

Por ejemplo, no puedes usar funciones como FILESTREAM, SQL Server Agent personalizado, CLR Unsafe, xp_cmdshell, ni muchos otros elementos avanzados. Tampoco puedes instalar software adicional en el sistema operativo ni afinar el motor a nivel de sistema. ¿Es suficiente para la mayoría de los casos de uso? Sí. ¿Es frustrante cuando necesitas hacer algo fuera del guión? También.

¿Qué ediciones están disponibles en AWS y cuándo usarlas?

Aquí es donde las diferencias entre EC2 y RDS se hacen más evidentes. En EC2 puedes instalar lo que quieras, como si estuvieras en tu CPD de toda la vida. RDS, en cambio, restringe la elección a ediciones licenciadas por AWS.

  • SQL Server Express: limitada hasta el absurdo. Solo útil en pruebas o en ese ERP vintage que aún cabe en 10 GB. Está disponible en EC2 y en RDS.
  • SQL Server Web Edition: solo para aplicaciones web y bajo ciertas condiciones. Más barata que Standard, pero con muchas limitaciones. Solo disponible en RDS si tu contrato lo permite.
  • SQL Server Standard: el caballo de batalla. Lo suficientemente potente para la mayoría de workloads OLTP, con soporte de hasta 128 GB de RAM y sin las florituras de Enterprise. Disponible tanto en EC2 como en RDS.
  • SQL Server Enterprise: para cuando ya no hablamos de bases de datos, sino de feudos de datos. Requiere justificar su coste, pero habilita funciones como Always On, compresión de datos, particionamiento, y el Query Store decente (no el recortado de Standard). También disponible en ambas opciones.

Versiones disponibles en AWS: sí, también hay letra pequeña

En RDS, las versiones disponibles van desde SQL Server 2012 hasta 2022 (según la región y el tipo de instancia). Pero no siempre están todas. Hay regiones donde 2022 aún no está disponible o donde ciertas ediciones se ofrecen solo en ciertas clases de instancias. Y no esperes instalar CUs al día siguiente de su publicación: AWS sigue su propio calendario de validación, lo cual está bien si valoramos la estabilidad… y menos bien si necesitamos esa CU concreta para resolver un bug que nos está friendo en producción.

En EC2, como tú te lo guisas, tú decides qué versión instalar. Pero no te olvides de los ciclos de soporte. Instalar SQL Server 2016 en 2025 es como llevar un Nokia 3310 a una reunión de arquitectura cloud: nostálgico, pero absurdo.

Y si hablamos de costes… prepara la cartera

Ni EC2 ni RDS son baratos si no se diseñan con cabeza. RDS tiene costes predecibles, pero no siempre bajos. EC2 puede salir caro si dejamos las instancias encendidas todo el mes sin monitorizar nada. Y el coste de las licencias es otra historia. SQL Server no es barato, y Amazon lo sabe.

En RDS pagamos licencia por hora. En EC2 podemos traer nuestras licencias con Software Assurance, lo cual puede ahorrar bastante en escenarios Enterprise. Pero si lo haces mal, puedes terminar pagando el doble por rendimiento inferior. La arquitectura importa, y mucho.

¿Y qué pasa con la alta disponibilidad en AWS?

En EC2, la alta disponibilidad te la montas tú: con Always On Availability Groups, con failover clustering, o con lo que prefieras… y se te ocurra mantener. En RDS, basta con activar la opción Multi-AZ y dejar que AWS haga el trabajo sucio. Pero no confundamos Multi-AZ con Always On: RDS usa su propio sistema de replicación bajo el capó, que no es transparente ni configurable.

Si necesitas un AG real con réplicas legibles, bienvenido a EC2. Y prepárate para montar la infraestructura necesaria: subredes, listeners, quórum, test de failover, etc. ¿Merece la pena? Depende de lo que estés dispuesto a sacrificar por la comodidad.

Te recomiendo ver la sesión de Francisco Amat sobre este tema para llevar tu alta disponibilidad al siguiente nivel.

Conclusión

No hay una única respuesta correcta a la pregunta “¿cómo desplegamos SQL Server en AWS?”. Hay decisiones técnicas, estratégicas y económicas que tomar. EC2 es más flexible, pero también más arriesgado. RDS es más cómodo, pero impone más restricciones.

La elección depende del tipo de carga, del nivel de control que necesitamos, de los costes que estamos dispuestos a asumir y, por supuesto, de cuántos fuegos queremos apagar a las tres de la madrugada.

Así que no, no es cuestión de levantar una base de datos “en la nube” y seguir con nuestra vida. Es cuestión de entender cada opción, sus límites y sus consecuencias. Porque en AWS, igual que en la vida, cada elección tiene su precio. Y a veces, ese precio se mide en IOPS… o en dignidad.

¿Quieres rendimiento extremo, fine-tuning y llorar en modo sysadmin? EC2. ¿Prefieres comodidad, escalabilidad rápida y vivir con algunas restricciones? RDS. Tú decides. Pero decide con conocimiento, no con fe ciega en el marketing cloud.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima! 

Publicado por Roberto Carrancio en Alta Disponibilidad, Cloud, SQL Server, 0 comentarios
07
May
2025

10 cosas que debe tener tu DRP de SQL Server

Un buen Plan de Recuperación ante Desastres (DRP) en SQL Server no se improvisa con prisas ni se resuelve con un backup semanal en una carpeta compartida. Quien piense lo contrario probablemente también crea que los backups verificados se restauran solos por arte de magia. Aquí venimos a poner orden. Vamos a repasar diez elementos que deben estar presentes en cualquier DRP decente, serio y pensado por alguien que sabe lo que significa tener producción caída más de 15 minutos.

DRP Check 1: Inventario de instancias y bases de datos críticas

Antes de correr a hacer backups como si el mundo se acabara, hace falta saber qué estamos protegiendo. Un DRP sin inventario es como un GPS sin destino. Documentar todas las instancias SQL Server, su versión, configuración, bases de datos alojadas, y cuál de ellas es crítica es el primer paso. Sin eso, el resto del plan será un ejercicio de fe.

Esto incluye nombres, versiones, configuración regional, nivel de compatibilidad, y por supuesto, si estamos hablando de SQL Server On-Prem, en Azure, en máquinas virtuales o en una mezcla caótica digna de una pesadilla DevOps.

DRP Check 2. Estrategia de copias de seguridad (real y testada)

Esto no va de tener un script que haga BACKUP DATABASE, sino de tener un plan de backups bien definido, ajustado al SLA del negocio y validado con restauraciones periódicas. Porque sí, hacer backups sin probar restores es como llenar el depósito del coche sin saber si tienes motor.

Y recuerda debes incluir backups completos, diferenciales y de logs si la base está en FULL.

DRP Check 3. Plan de restauración documentado (y probado, otra vez)

Vale, ya tenemos backups. ¿Y ahora qué? Un DRP sin un procedimiento claro de restauración es solo un acto de fe. Hay que documentar cómo restaurar cada tipo de backup, en qué orden, en qué entorno, y cuánto tiempo se estima que llevará. No valen suposiciones.

¿Se han probado esas restauraciones en un entorno aislado? ¿Se ha medido el tiempo real? ¿Se ha verificado que la aplicación vuelve a levantar sin errores? Si la respuesta es no, el DRP es papel mojado.

DRP Check 4. Topología de alta disponibilidad y replicación

La disponibilidad no es solo cosa del DRP, pero forma parte de él. Un clúster de Always On, una replicación transaccional o un Log Shipping bien montado pueden ser la diferencia entre una caída de horas y una recuperación en minutos.

Aquí hay que documentar cómo están montadas esas soluciones, cómo se comportan ante fallos y, lo más importante, cómo se revierte o se conmutan sin pérdida de datos. Porque el botón “Failover” no es magia, y conviene saber qué pasa antes de pulsarlo.

DRP Check 5. Matriz de responsabilidad (quién hace qué y cuándo)

En medio del caos no hay tiempo para preguntar «¿quién se encarga de esto?». Un DRP debe tener definidos claramente los roles: quién inicia el protocolo, quién comunica a negocio, quién ejecuta los scripts, quién valida y quién da el OK final.

Y no, no vale con poner “El DBA” para todo. Porque el DBA también duerme (al menos en teoría) y puede que no esté disponible a las 3:00 de la mañana un festivo. Así que planifica relevos, turnos y contactos de emergencia. Y por supuesto, guarda esa información fuera del entorno afectado.

DRP Check 6. Procedimiento para activar el DRP

No todo fallo es un desastre. Un plan serio define umbrales: ¿cuándo se considera que hay que activar el DRP? ¿Cuánto tiempo puede estar caída una instancia sin que salten las alarmas? ¿Hay una ventana para intentos de recuperación antes de iniciar failover?

Este punto es crítico. Muchos planes fallan porque nadie sabe cuándo hay que usarlos. Y cuando se deciden, ya es tarde y el daño está hecho. Un buen DRP se activa con decisión, no con debates.

DRP Check 7. Infraestructura de recuperación (y entorno preconfigurado)

Recuperar una base de datos en un entorno que no existe es una broma de mal gusto. El DRP debe incluir un entorno de recuperación configurado con antelación: máquinas, redes, almacenamiento, seguridad… todo listo para levantar una instancia funcional.

Si estás en Azure o AWS, tener imágenes de máquinas o plantillas ARM listas para desplegar reduce el tiempo de recuperación drásticamente. Si estás en On-Prem, tener máquinas físicas o virtuales reservadas para contingencias no es un lujo, es prevención.

DRP Check 8. Automatismos y scripts listos para ejecutar

En medio del desastre, lo último que queremos es escribir scripts a mano o copiar/pegar desde un correo de 2017. El DRP debe contener los scripts ya preparados para tareas como restaurar backups, reconfigurar logins, recrear jobs, reiniciar endpoints y comprobar integridad.

Cuanto más automático esté todo, menos errores y más rapidez. Pero cuidado: automatizar sin entender es un atajo al desastre. Automatización sí, pero documentada, validada y revisada.

DRP Check 9. Validación post-recuperación

El DR no termina cuando el servidor levanta. Termina cuando la aplicación vuelve a funcionar, los usuarios acceden y nadie grita por Teams. El plan debe incluir validaciones técnicas (integridad, acceso, jobs funcionando, monitoreo operativo) y funcionales (consultas clave, flujos de negocio).

Aquí es donde muchos se relajan demasiado pronto. Recuperar una base sin comprobar que los índices no están corruptos o que el SQL Agent arranca, es como arreglar un coche y no probar que arranca. Todo debe quedar verificado y documentado.

DRP Check 10. Revisión y simulacros regulares

Por último, un DRP no es un PDF que se guarda en una carpeta y se olvida. Es un documento vivo que hay que revisar y probar. Idealmente, al menos una vez al año (y si el entorno cambia, con cada cambio relevante).

Los simulacros revelan errores, tiempos reales, dependencias ocultas y, sobre todo, preparan al equipo. No hay vergüenza en fallar en un simulacro. La vergüenza viene cuando el desastre es real y nadie sabe ni por dónde empezar. Y sí, si nunca has hecho un simulacro y crees que todo va a salir bien, te deseo la mejor de las suertes. La vas a necesitar.

Conclusión

Un DRP de SQL Server no es un archivo bonito con diagramas de PowerPoint. Es una estrategia detallada, técnica y validada que te permite dormir un poco más tranquilo (solo un poco). Tiene que estar alineado con el negocio, ejecutado por profesionales y probado con rigor.

Dejarlo para otro día es como ignorar un CHECKDB con errores porque “no ha fallado nada todavía”. Lo sabes tú, lo sabemos todos: el desastre no avisa. Pero sí se entrena. Así que más vale tener el plan listo y no necesitarlo, que necesitarlo y tener que improvisar.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima! 

 

Publicado por Roberto Carrancio en Alta Disponibilidad, Cloud, SQL Server, 0 comentarios