Microsoft anunció el 3 de agosto de 2026 una nueva protección incluida en Azure SQL: hasta los siete días más recientes de copias para restauración a un momento dado (PITR) pasan a tener inmutabilidad automática. Según Azure Updates, la función está en disponibilidad general para Azure SQL Database y Azure SQL Managed Instance.
La activación no exige crear políticas, preparar una cuenta de almacenamiento ni gestionar bloqueos. Microsoft la aplica por defecto a todas las bases de datos compatibles, con independencia del periodo PITR configurado, sin coste adicional y sin cambiar los flujos actuales de copia y restauración.
Qué aporta realmente la inmutabilidad
Una copia inmutable no puede alterarse ni eliminarse durante el periodo protegido. Es una barrera útil cuando el incidente incluye credenciales administrativas comprometidas, una eliminación accidental o un ataque que intenta inutilizar también los puntos de recuperación.
El cambio reduce trabajo operativo porque la protección vive dentro del servicio gestionado. La documentación de Microsoft Learn sobre la inmutabilidad automática confirma que usa las capacidades de almacenamiento inmutable de Azure y que los procedimientos existentes de restauración siguen funcionando igual.
Esto es un hecho distinto de afirmar que una plataforma ya cumple una norma concreta. Microsoft señala que la tecnología puede apoyar requisitos de conservación de registros como SEC 17a-4(f), CFTC 1.31(d) o FINRA, pero también pide evaluar cada obligación con los equipos legales y de cumplimiento. La configuración completa, la jurisdicción y los procesos alrededor del dato siguen importando.
Siete días protegidos no son una estrategia completa
El matiz principal está en la expresión «hasta los siete días más recientes». Esta función protege copias PITR recientes; no sustituye una política de retención ni amplía por sí sola el historial que el equipo haya decidido conservar. Azure SQL Database permite configurar la retención PITR dentro de sus límites de servicio y ofrece retención a largo plazo (LTR) para necesidades que van más allá.
También conviene separar inmutabilidad de redundancia. Una copia puede estar protegida contra cambios y, aun así, la arquitectura debe decidir si necesita almacenamiento local, zonal o georredundante. La posibilidad de restaurar ante una caída regional depende de esa elección, no solo del bloqueo contra borrado. Microsoft detalla estas diferencias en la guía de backups automáticos de Azure SQL Database.
La limitación más clara es Azure SQL Database Hyperscale: Microsoft indica que todavía no admite esta inmutabilidad automática y que llegará en una versión futura, sin comprometer una fecha. El anuncio no describe excepciones regionales para el resto y habla de todas las bases de datos compatibles.
Qué revisaría un equipo de IT
- Inventariar Azure SQL Database y Managed Instance, separando las bases Hyperscale para que la nueva protección no oculte ese hueco.
- Comprobar la retención PITR configurada en cada carga y confirmar que coincide con el objetivo de recuperación del negocio.
- Revisar la redundancia de las copias y si el diseño necesita restauración en otra región.
- Mantener o definir LTR cuando hagan falta meses o años de conservación; los siete días inmutables no cubren ese escenario.
- Ejecutar restauraciones de prueba y medir tiempo, permisos y dependencias. Una copia protegida solo demuestra su valor cuando el procedimiento de recuperación funciona.
- Documentar que no hay una acción de despliegue para esta novedad, pero sí una tarea de verificación para Hyperscale y para los controles que quedan fuera.
Mi lectura es que Microsoft ha añadido una base de seguridad sensata y transparente: protege el tramo más reciente sin pedir otro componente al administrador. Aun así, no convertiría «activado por defecto» en «recuperación resuelta». Retención, redundancia, pruebas y responsabilidades siguen siendo decisiones del equipo.