Sin cerrar OneNote ni Teams antes de la copia nocturna en AWS aumenta la posibilidad de restaurar un servidor Terminal Server con datos corruptos o incompletos. La solución más fiable es orquestar instantáneas “application‑consistent” con VSS, acompañadas de scripts que sincronicen o detengan las aplicaciones que mantienen conexiones en tiempo real.
Cómo funcionan realmente las instantáneas de Amazon EBS
La fotografía que AWS toma de un volumen EBS es crash‑consistent por defecto: se copian los bloques tal y como estaban en el momento en que el hipervisor congeló el disco. Desde la perspectiva del sistema operativo equivale a quitar el cable de alimentación; la RAM y la caché de disco no se incluyen.
Cuando se trata de un Windows Server 2019 que sirve como Terminal Server multiusuario, se superponen tres capas de complejidad:
- Procesos de usuario activos (Word, Excel, Teams, OneNote, Acrobat, etc.).
- Servicios en segundo plano (SQL Server Express, antivirus, spooler de impresión).
- Posibles sesiones RDP huérfanas que siguen ejecutando software.
Si alguna aplicación conserva datos sin confirmar en memoria, la imagen puede resultar inconsistente al montarse en otro volumen o al arrancar la instancia restaurada.
Instantáneas application‑consistent con VSS
Windows expone el servicio Volume Shadow Copy Service (VSS), capaz de coordinar a las aplicaciones para que vacíen cachés, congelen bases de datos y liberen bloqueos durante unos segundos. Con VSS, la copia incluye el mismo estado que verías tras un apagado limpio.
AWS Systems Manager (SSM) y el EC2 Systems Manager Agent permiten lanzar automáticamente:
- Un script PowerShell de pre‑snapshot que llama a
diskshadow
para iniciar VSS y, si se desea, pausa servicios o cierra procesos concretos. - La creación de la snapshot.
- Un script post‑snapshot que reanuda todo.
Plantilla mínima de un documento SSM
{ "schemaVersion": "2.2", "description": "Snapshot consistente con VSS", "mainSteps": [ { "action": "aws:runPowerShellScript", "name": "PreSnapshot", "inputs": { "runCommand": [ "Stop-Process -Name Teams -Force -ErrorAction SilentlyContinue", "Stop-Process -Name OneNote -Force -ErrorAction SilentlyContinue", "diskshadow /s C:\\scripts\\vss.txt" ] } }, { "action": "aws:createImage", "name": "TakeSnapshot", "inputs": { "instanceId": "{{ TargetId }}", "noReboot": true, "description": "TerminalServer nightly snapshot" } }, { "action": "aws:runPowerShellScript", "name": "PostSnapshot", "inputs": { "runCommand": [ "Start-Process \"C:\\Program Files\\Microsoft\\Teams\\current\\Teams.exe\"", "Start-Process \"C:\\Program Files\\Microsoft Office\\root\\Office16\\ONENOTE.EXE\"" ] } } ] }
OneNote y Teams: por qué son especiales
Componente | Características técnicas que complican el snapshot |
---|---|
Teams | Base de datos SQLite en %APPDATA%\Microsoft\Teams . Sincronización chat/ficheros casi en tiempo real con la nube. Al restaurar un snapshot se recrea un estado histórico; los mensajes “futuros” vuelven a descargarse, pero la base local puede contener entradas duplicadas o bloqueos «database is locked». |
OneNote | Almacena un cache binario que agrupa páginas, archivos incrustados y metadatos. Si una transacción de archivo .one se corta a la mitad, OneNote mostrará un aviso de corrupción y creará una copia de “páginas perdidas”. Puede pasar inadvertido hasta semanas después de la restauración, complicando auditorías. |
¿Qué ocurre con Word, Excel, Acrobat o el front‑end de SQL Server?
Aplicaciones tradicionales que ya han cerrado todos sus documentos presentan un riesgo mucho menor. Sin embargo, conviene tener en cuenta:
- Bloqueos Handle aún abiertos. La interfaz puede estar cerrada, pero el proceso mantiene un handle al archivo durante la escritura de propiedades o miniaturas.
- Documentos anclados en la Jump List de Windows. El sistema actualiza automáticamente datos de uso reciente.
- Complementos COM o VSTO. Pueden ejecutar hilos en segundo plano (p. ej., sincronizadores de SharePoint o plugins de firma digital).
La recomendación sigue siendo aplicar VSS y, aun así, realizar comprobaciones de integridad la primera vez que un usuario vuelva a abrir el documento tras la restauración.
Checklist de buenas prácticas antes de la instantánea nocturna
- Configura la política de grupo “Cerrar sesiones desconectadas tras x minutos” para limitar aplicaciones huérfanas.
- Programa un
shutdown -l
(logoff) selectivo a los usuarios que no pertenezcan a un grupo de excepción. - Incluye en el script pre‑snapshot:
Get-Process Teams, OneNote | Stop-Process -Force
Invoke-Sqlcmd
para pausar tareas de mantenimiento en bases incrustadas.
- Ejecuta
vssadmin list writers
y asegúrate de que todos están en estado Estable. - Avisa a los usuarios con
msg * /server:localhost "Se realizará copia de seguridad en 5 minutos"
.
Pruebas de restauración: el ingrediente olvidado
Un backup no probado es tan inútil como no tener backup. Minimiza sorpresas con este flujo de trabajo trimestral:
- Restaurar la instantánea en un volumen nuevo y adjuntarlo a una instancia de prueba con la misma versión de Windows.
- Arrancar en modo seguro para permitir los cambios de SID y NIC.
- Validar:
- Inicio de sesión de un usuario representativo.
- Apertura de OneNote sin avisos de “Failed Page” y sincronización correcta de secciones.
- Teams: capacidad de enviar un mensaje y que se refleje en el tenant.
- Base de datos SQL Express:
DBCC CHECKDB
sin errores.
- Documentar cada hallazgo y ajustar el script pre‑snapshot según los resultados.
Comparativa rápida de riesgos y mitigaciones
Escenario | Riesgo principal | Gravedad | Mitigación recomendada |
---|---|---|---|
Teams o OneNote abiertos y escribiendo | Corrupción de archivos cache y duplicación de mensajes | Alta | Cerrar proceso + VSS consistente |
Word / Excel recién cerrados | Metadatos incompletos en .tmp | Media | VSS + verificación de apertura tras restaurar |
SQL Server Management Studio con una consulta activa | Transacción a medias en tempdb | Alta | DETACH o poner BD en single‑user antes de snapshot |
Visor PDF sin cambios pendientes | Nulo | Baja | Sin acción; snapshot es suficiente |
Estrategia de contingencia multinivel
No confíes únicamente en las instantáneas:
- Versionado de OneDrive y SharePoint. Ofrece hasta 500 versiones por archivo .one.
- Copias de seguridad completas en Amazon Backup o herramientas de terceros. Deben guardarse en cuentas separadas para evitar un borrado accidental por un rol comprometido.
- Exportaciones de OneNote. Convertir cuadernos críticos a PDF o archivo .onepkg antes de cambios mayores.
- Automatización de DR. CloudFormation o Terraform que reconstruya la infraestructura y monte los volúmenes restaurados.
Preguntas frecuentes
¿Puedo confiar en “auto‑save” de OneNote como protección?
No. El auto‑save actualiza la nube cada pocos segundos, pero escribe primero en la caché local. Si la instantánea captura un estado intermedio, los índices pueden quedar incoherentes.
¿Qué ocurre si dejo Teams abierto pero todos los chats están sincronizados?
Teams mantiene archivos de base de datos abiertos en modo escritura incluso cuando no aparecen cambios. El snapshot no capturará la transacción completa de SQLite, lo cual puede bloquear la base al restaurar.
Mi Terminal Server usa perfiles itinerantes; ¿cambia algo?
Sí. Si el perfil del usuario se redirige a un share SMB, el riesgo se transfiere al servidor de archivos. Necesitarás snapshots coherentes también en ese host o un respaldo de VSS Shadow Copies compartidas.
Conclusiones clave
Para un servidor Windows Server 2019 alojado en AWS y usado como Terminal Server:
- Cerrar o detener Teams y OneNote antes de la instantánea es la práctica más segura.
- Sincronizar manualmente—o forzar cierre—reduce la probabilidad de pasar horas reparando cuadernos o eliminando mensajes duplicados tras una restauración.
- Para las demás aplicaciones que no mantienen sesión en la nube basta con validar que el archivo esté cerrado, pero sigue siendo recomendable VSS.
- Las pruebas de restauración trimestrales son obligatorias: ningún procedimiento de respaldo está completo sin validación.
Resumen accionable
- Implementa instantáneas application‑consistent con VSS a través de AWS SSM.
- Incluye scripts para detener Teams y OneNote, y para pausar transacciones de SQL si procede.
- Ejecuta health checks automáticos tras restaurar: OneNote / Teams / DB.
- Mantén copias de seguridad adicionales y un plan de DR documentado.
Adoptar estas prácticas disminuye radicalmente la probabilidad de que la próxima restauración de tu Terminal Server se convierta en una carrera contra el reloj para recuperar datos dañados.