Ejemplos de uso / 22
Copias de Hyper-V: notificación en positivo y alerta por silencio
Exportar máquinas desde Windows, supervisar resultado y silencio con Attacus y Sentinelia y revisar las alertas en el turno diario de mantenimiento proactivo.
Una copia en Windows que también se puede supervisar
Necesidad: exportar máquinas virtuales de Hyper-V a un destino de copias de seguridad y saber si la tarea termina con errores o deja de comunicar su resultado.
La tarea se ejecuta en un equipo Windows con PowerShell. Exporta las máquinas al almacenamiento elegido, conserva las versiones previstas y entrega el resultado a Attacus. Sentinelia recibe las señales y permite configurar dos comprobaciones: la última operación fue correcta y hay un resultado suficientemente reciente.
PowerShell escribe la exportación en un disco dedicado o en un recurso de red accesible desde la cuenta de la tarea. Después comunica su resultado mediante PowerShell → Attacus → Sentinelia → panel del técnico. Los archivos de la copia permanecen en el destino elegido; las señales transportan el resultado y el contexto de la operación.
Este caso parte de un uso real realizado el 11 de noviembre de 2026. Los nombres, rutas y plazos siguientes son ejemplos para adaptar a cada instalación.
Notificación en positivo: esperar una confirmación
La tarea está preparada para comunicar su resultado en cada ejecución, también cuando termina bien. Esa notificación en positivo permite supervisar dos aspectos del mismo trabajo: qué ocurrió y si la confirmación esperada sigue llegando.
| Lo que llega a Sentinelia | Qué significa para el técnico |
|---|---|
| Un resultado correcto y reciente | La tarea ha comunicado una operación correcta dentro del plazo previsto |
| Un resultado de error | La tarea ha podido comunicar que algo falló; el resumen ayuda a investigarlo |
| Ningún resultado nuevo dentro del plazo | Falta la confirmación esperada; el último «Sí» ya no basta |
Esta política se aplica a un mantenimiento proactivo con revisión diaria por turnos rotativos. Las incidencias quedan visibles en el panel y el técnico del turno las revisa cuando su carga de trabajo lo permite. La respuesta prevista es una intervención humana; en esta receta los monitores quedan sin acciones automáticas vinculadas.
El panel actualiza las alertas mediante WebSocket, por lo que también puede mantenerse abierto en una pantalla grande a la vista del equipo, con una Raspberry Pi detrás para mostrarlo.
Una pequeña «Bat Cueva», como la que imaginábamos con David A. cuando esta aplicación todavía era una idea.
El recorrido que vamos a preparar es:
Ejecutar y comunicar: Windows realiza la exportación y la tarea entrega a Attacus el resultado y su resumen.
Interpretar y supervisar: Sentinelia mantiene un monitor del resultado y otro de su antigüedad.
Revisar e intervenir: el técnico consulta el panel, identifica la causa y comprueba la recuperación.
Las ocho capturas del recorrido pueden ampliarse. Proceden de la configuración real y ocultan los nombres de equipos, tenant, empresa y sitio cuando aparecen. Los nombres de los monitores y las señales se conservan para poder seguir los pasos.
Preparar el equipo y el destino
Windows PowerShell 5.1 y el módulo Hyper-V, con permisos para ejecutar
Export-VM.Un directorio de destino existente, con espacio para una exportación nueva antes de retirar versiones anteriores.
Attacus instalado y conectado con Sentinelia.
Una cuenta Windows dedicada a la tarea, con permisos de exportación, escritura en el destino y escritura de registros junto a los scripts.
Para un destino de red utiliza una ruta UNC, por ejemplo \\COPIAS01\HyperV\HV01. Las unidades de red asignadas en la sesión interactiva pueden no existir cuando se ejecuta una tarea programada.
Organizar el alcance y el acceso del equipo técnico
Sitúa el agente y los monitores en la estructura a la que pertenece el equipo: tenant → empresa → sitio. El tenant reúne la organización, la empresa identifica la entidad que mantiene esos recursos y el sitio concreta la sede cuando corresponde. La guía de organización explica cómo preparar esa jerarquía.
En este caso los monitores se han configurado como monitores de sitio. Si la copia corresponde al conjunto de una empresa, elige esa pertenencia de acuerdo con tu organización. Comprueba siempre el resumen de alcance antes de guardar.
El alcance cumple dos funciones: permite ordenar y localizar los recursos, y delimita cuáles puede consultar o gestionar cada cuenta. Los permisos del usuario determinan qué operaciones puede realizar dentro de ese alcance. Un filtro del catálogo ayuda a buscar; la autorización depende de la cuenta y sus permisos.
Una cuenta de alcance de sitio consulta los monitores de ese sitio. Los monitores de empresa requieren alcance de empresa o superior; tenlo en cuenta al decidir la pertenencia del monitor y quién realizará la revisión.
| Identidad | Dónde se configura | Responsabilidad en este recorrido |
|---|---|---|
| Cuenta Windows de la tarea | Windows y autorización de señales externas en Attacus | Ejecutar la exportación y entregar sus resultados |
| Identidad del agente Attacus | Conexión del agente con Sentinelia | Transportar las señales hacia la instalación correspondiente |
| Cuenta del técnico de turno | Usuarios, alcance y permisos de Sentinelia | Consultar el panel y los recursos de su ámbito e intervenir según sus permisos |
Asigna a cada técnico su propia cuenta y el alcance que le corresponda, junto con los permisos para consultar el panel, los monitores y la telemetría que necesite. La pertenencia a un turno no concede permisos por sí sola. Las capturas se tomaron durante la configuración administrativa; el técnico puede trabajar con un acceso más acotado.
Los campos nombre_empresa, servidor_name y AttacusTag del script aportan contexto al resumen y a la identidad de las señales. La pertenencia organizativa y las autorizaciones se preparan en el portal y en Attacus; esos textos no las asignan.
Descargar y configurar los scripts
Guarda estos dos archivos en la misma carpeta, por ejemplo C:\Scripts\CopiasVM:
Descargar cp-attacus.ps1: exportación, retención y envío de señales.
Descargar lanzador-attacus.ps1: configuración de la tarea y código de salida para el Programador de tareas.
Asigna los permisos antes de programar la tarea. En Propiedades → Seguridad, restringe el acceso a la carpeta y a los scripts a la cuenta que ejecutará la tarea y a las identidades administrativas necesarias:
La cuenta de la tarea necesita Lectura y ejecución sobre ambos scripts. Reserva su modificación a los administradores que los mantienen.
Revisa los permisos heredados de la carpeta: otros usuarios no deben poder modificar, eliminar ni sustituir los scripts, ni crear archivos en esa carpeta. Un script protegido dentro de una carpeta que permite reemplazarlo sigue siendo vulnerable.
Prepara
log.logyerror.logen esa misma carpeta y concede a la cuenta de la tarea la escritura necesaria sobre esos archivos, sin darle modificación general sobre la carpeta o los.ps1.Comprueba los permisos efectivos con la identidad real de la tarea. La autorización de señales en Attacus controla quién puede enviarlas; los permisos NTFS protegen el código que ejecutará esa identidad.
Si otro usuario pudiera cambiar un script, su código se ejecutaría con los permisos de la cuenta de la tarea en la siguiente ejecución.
Edita el bloque CONFIGURACION del lanzador. Para una tarea diaria, por ejemplo:
$configuration = @{
VM = @('VM-ERP', 'VM-ARCHIVOS')
Path = '\\COPIAS01\HyperV\HV01'
nombre_empresa = 'Mi empresa'
servidor_name = $env:COMPUTERNAME
Monthly = $false
n_copy = 7
AttacusScriptPath = 'C:\Program Files\Attacus\Enviar-SenalAttacus.ps1'
AttacusTag = 'copias_hyperv_diaria'
}
Este bloque es una propuesta de configuración diaria. El archivo descargable incluye valores iniciales que debes adaptar. Las capturas del caso real utilizan el tag pruebas_copiasvm; el ejemplo anterior propone copias_hyperv_diaria. Utiliza el tag que hayas elegido de forma consistente al aprobar las señales y al seleccionarlas en los monitores. Cambiarlo crea otra identidad de señal que necesita su propia aprobación.
Los grupos Weekly y Monthly del script distinguen la retención; no programan la periodicidad. En este ejemplo se conservan siete carpetas del grupo Weekly, incluida la nueva, y la ejecución diaria se configura en Windows.
Utiliza un destino propio para cada conjunto de máquinas y evita ejecuciones simultáneas sobre él: la retención distingue el grupo, pero no la empresa, el tag ni la lista de máquinas. Si falla alguna exportación, conserva la carpeta parcial y no elimina las copias anteriores. Las carpetas parciales también pueden entrar en la retención de futuras ejecuciones correctas.
Aprobar las dos señales con la cuenta de la tarea
Ejecuta el lanzador con la misma identidad Windows que utilizará el Programador de tareas:
powershell.exe -NoProfile -NonInteractive -File "C:\Scripts\CopiasVM\lanzador-attacus.ps1"
El script envía dos señales de categoría hyperv, con el tag configurado:
| Clave | Tipo | Qué informa |
|---|---|---|
copia_correcta |
Booleano | Si todas las exportaciones y la retención terminaron sin errores |
copia_resumen |
JSON | Máquinas solicitadas y exportadas, resultados individuales, duración, fechas y errores |
Si es su primer envío, revisa ambas propuestas en Attacus → Señales → Señales externas… y autorízalas para la cuenta de la tarea. Sigue la guía de aprobación del contexto Windows. Aprobar una señal no autoriza automáticamente la otra.
La primera ejecución puede completar la exportación aunque sus señales queden pendientes de aprobación. Ese primer envío no se reproduce al aprobar: vuelve a comprobar la entrega desde la identidad autorizada. -WhatIf sirve para mostrar la operación prevista, pero no exporta, no valida el entorno ni propone señales.
Attacus añade a cada dato aceptado una fecha con clave terminada en _aceptada_en. En Agentes → Ver telemetría de Sentinelia comprueba el booleano, el JSON y sus fechas asociadas. La aceptación local inicia la entrega a Sentinelia; la respuesta inmediata del script no es una confirmación de recepción remota.
Qué mirar: el booleano responde a «¿terminó bien la operación?»; la fecha permite comprobar si sigue llegando un resultado; el JSON aporta el detalle. Son tres lecturas con funciones distintas.
Programar la exportación en Windows
Crea una tarea con la cuenta autorizada y estos valores:
| Campo | Configuración de ejemplo |
|---|---|
| Programa | C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe |
| Argumentos | -NoProfile -NonInteractive -File "C:\Scripts\CopiasVM\lanzador-attacus.ps1" |
| Iniciar en | C:\Scripts\CopiasVM |
| Desencadenador | Una vez al día, a la hora elegida |
| Si la tarea ya se está ejecutando | No iniciar una instancia nueva |
El lanzador espera la exportación, la retención y los envíos. Un código 1 puede deberse a la copia, al registro o a la notificación: consulta el error antes de repetir una exportación que quizá ya terminó. Los archivos log.log y error.log se guardan junto a cp-attacus.ps1.
Dejar contexto para el siguiente técnico
La condición técnica determina el estado del monitor. La descripción, el motivo humano del fallo y la posible solución permiten entender qué significa ese estado para este entorno y por dónde empezar a intervenir. En un turno rotativo, esos campos conservan conocimiento operativo para quien no preparó la configuración.
| Campo | Qué conviene explicar |
|---|---|
| Nombre | Qué trabajo se está supervisando y qué aspecto representa: resultado o silencio |
| Descripción | Qué exporta la tarea, con qué periodicidad, dónde se guarda y qué equipo la mantiene |
| Motivo humano del fallo | Qué condición ha dejado de cumplirse y qué implica para la revisión de las copias |
| Posible solución | Qué comprobar primero, qué evidencias consultar y cómo verificar la recuperación |
Como redacción de referencia para Estado de copia de seguridad:
Motivo humano: «La última ejecución ha comunicado un error en la exportación o en la retención. Revisar el resumen para identificar la fase y las máquinas afectadas».
Posible solución: «Consultar el resumen JSON y los registros de la tarea. Comprobar el destino y el error concreto, corregir la causa y verificar el resultado de una nueva ejecución».
Para Copia Hyper-V en Servidor, que supervisa el silencio:
Motivo humano: «No se dispone de un resultado nuevo dentro del plazo configurado. El último valor conservado no permite confirmar la continuidad de las copias».
Posible solución: «Revisar la última ejecución en el Programador de tareas, los registros, el servicio Attacus y la conectividad. Comprobar si la exportación terminó antes de decidir repetirla».
Son propuestas de redacción para adaptar a la instalación; las capturas conservan los textos escritos durante la configuración real. Distingue la condición observada de sus posibles causas: una ausencia de resultados orienta la investigación, pero no demuestra por sí sola que haya fallado la exportación.
La posible solución es una ayuda para la persona que atiende la incidencia. Las acciones automáticas se configuran mediante sus propios enlaces y en este caso quedan sin vincular.
Alertar cuando la copia comunica un fallo
Crea un monitor de telemetría sobre hyperv / copia_correcta, con el tag de esta tarea. Elige Definir aquí los valores normales y establece verdadero como valor normal.
Con alerta individual, una lectura false representa un problema que atender. El resumen JSON permite investigar qué máquinas fallaron o si el error se produjo al aplicar la retención. Consulta el JSON como diagnóstico; el booleano aporta la condición operativa.
Monitor del resultado: Estado de copia de seguridad
La captura utiliza esta configuración:
| Campo | Valor del caso real |
|---|---|
| Nombre | Estado de copia de seguridad |
| Cómo detectar un problema | Definir aquí los valores normales |
| Señal | hyperv.copia_correcta:pruebas_copiasvm |
| Valor considerado normal | Verdadero |
| Espera antes de confirmar el problema | 0 segundos |
| Intervalo de evaluación | 900 segundos, cada 15 minutos |
| Desfase inicial | 15 segundos |
| Fallos / comprobaciones correctas para cambiar de estado | 1 / 1 |
| Uso | Monitor con alerta individual en el panel |
El motivo humano del fallo orienta al técnico: el servidor ha notificado un fallo en su copia de seguridad. La posible solución le recuerda verificar el estado de la copia y realizar las correcciones oportunas.
Qué mirar: un resultado falso puede producir la indisponibilidad en la siguiente evaluación. El intervalo de 15 minutos determina la cadencia de supervisión; la tarea de copia conserva su propia programación diaria.
Alertar por silencio aunque el último resultado fuera correcto
Un último valor verdadero no garantiza que la tarea siga ejecutándose. Si el Programador de tareas deja de lanzarla, el equipo se apaga o la entrega se interrumpe, puede no llegar un nuevo resultado que indique el fallo.
Utiliza la fecha hyperv / copia_correcta_aceptada_en, con el mismo tag, para vigilar la antigüedad del último resultado aceptado por Attacus y recibido en Sentinelia. Por ejemplo, para una copia diaria cuyo tiempo habitual de ejecución y entrega permita un margen de dos horas:
Crea una regla sobre esa señal de fecha.
En Dato que se comprobará, elige Fecha respecto a ahora.
Selecciona Si queda por debajo del límite y sitúa el límite en el pasado: ahora − 26 horas.
Describe el problema como Sin resultado reciente de la copia Hyper-V.
Utiliza esa regla en un monitor de telemetría con alerta individual.
El reloj de Sentinelia sigue evaluando la fecha aunque no lleguen nuevas lecturas. Cuando supera la antigüedad permitida, el silencio puede generar una alerta sin que la tarea tenga que enviar un error. Consulta cómo comparar fechas respecto al presente.
Adapta el plazo a la periodicidad, la duración de la exportación y el margen de entrega. Para una tarea semanal no corresponde el límite diario de este ejemplo. Comprueba la primera lectura antes de dar la supervisión por preparada: una señal sin datos no acredita una copia correcta ni reciente.
La fecha _aceptada_en registra cuándo Attacus aceptó el resultado, tanto si fue verdadero como falso. Una entrega posterior a Sentinelia conserva esa fecha. Sirve para vigilar la continuidad de los resultados, pero no identifica por sí sola la última copia correcta. Para supervisar también ese dato de negocio, la tarea puede emitir una señal datetime específica que solo actualice al completar una copia correcta; esa señal adicional necesita su propia aprobación.
Regla de silencio: una fecha que envejece
Qué mirar: selecciona Si queda por debajo del límite. La condición de silencio se expresa como fecha de aceptación < ahora − 26 horas. Elegir «Si supera el límite» comprobaría el sentido contrario.
Tras guardarla, la ficha permite revisar la última lectura y la próxima frontera temporal:
Con el horario adaptado de este ejemplo, la fecha informada corresponde al 11/11/2026 a las 14:33:46,19 y el presente evaluado a ese día a las 20:03:02,19. El dato sigue dentro del plazo; la próxima frontera corresponde al 12/11/2026 a las 16:33:46,19. La regla está activa y todavía no coincide con la condición de problema. Es la evaluación de la regla; la alerta depende del monitor que la utiliza. La captura conserva las horas originales; aquí se aplica el mismo desplazamiento a toda la cronología del ejemplo.
Monitor de silencio: Copia Hyper-V en Servidor
Crea un segundo monitor y selecciona Usar una regla de interpretación existente. Elige la regla de las 26 horas y configura Monitor con alerta individual en el panel.
| Campo | Valor del caso real |
|---|---|
| Nombre | Copia Hyper-V en Servidor |
| Fuente | Regla sobre hyperv.copia_correcta_aceptada_en:pruebas_copiasvm |
| Intervalo de evaluación | 900 segundos, cada 15 minutos |
| Espera antes de confirmar el problema | 3600 segundos, una hora |
| Fallos / comprobaciones correctas para cambiar de estado | 1 / 1 |
| Uso | Monitor con alerta individual en el panel |
Qué mirar: la espera de 3600 segundos se añade al plazo de la regla. Con esta configuración, el aviso no aparece al cumplirse exactamente 26 horas: el problema debe persistir una hora adicional y confirmarse según las evaluaciones del monitor. Si quieres que las 26 horas sean el único margen temporal, configura esa espera a cero. Ajusta ambas decisiones a tu política de mantenimiento.
El motivo y la posible solución ayudan al técnico a revisar la programación de la copia, la conectividad del equipo y el servicio de Attacus. Son orientaciones para investigar; el silencio por sí solo no identifica cuál de esas causas se ha producido.
Leer conjuntamente resultado y antigüedad
| Último resultado | Antigüedad dentro del plazo | Qué atender |
|---|---|---|
| Correcto | Sí | La última operación fue correcta y existe un resultado reciente |
| Con errores | Sí | La tarea informó de un fallo; revisar el resumen |
| Correcto | No | El último éxito ya no basta: falta un resultado nuevo |
| Con errores | No | El último resultado fue un fallo y además ha dejado de renovarse |
| Sin lectura evaluable | Sin referencia | Comprobar la primera ejecución, autorizaciones y entrega |
En este caso conservamos dos monitores con alerta individual. Así el panel puede distinguir una copia que comunicó un error de una tarea cuyo resultado dejó de llegar. Ambos quedan sin acciones automáticas vinculadas; el técnico decide la intervención durante su revisión.
Revisar el catálogo antes de pasar al turno diario
La captura se tomó antes de que transcurriera el tiempo suficiente para la primera evaluación de ambos monitores. En ese instante, Copia Hyper-V en Servidor ya aparece disponible y Estado de copia de seguridad figura pendiente, sin ejecución. Ese pendiente corresponde al arranque de la supervisión y no indica que la copia haya fallado.
Con una cadencia de 15 minutos y el desfase inicial configurado, hay que dejar que el motor alcance las evaluaciones programadas para que los estados se establezcan. La llegada de una lectura, la evaluación de la regla y la evaluación de cada monitor son momentos distintos.
La siguiente captura muestra el catálogo después de ese periodo inicial:
Habilitado significa configurado para operar; Disponible refleja el resultado operativo de una evaluación. En una nueva instalación, deja transcurrir los tiempos configurados y consulta la actividad de ambos monitores antes de interpretar su estado inicial.
La alerta visible que se muestra más adelante procede de una prueba controlada de la condición booleana. El recorrido de silencio queda documentado mediante su regla temporal y su monitor.
Mantenimiento proactivo durante el turno diario
El equipo organiza un turno diario rotativo. El técnico responsable entra en Panel → Alertas operativas cuando su carga de trabajo lo permite y revisa las incidencias que siguen activas. En esta receta no se configuran acciones de correo, llamadas HTTP/API ni cambios DNS: la alerta en el panel es el punto de entrada al trabajo humano.
| Incidencia visible | Primera revisión | Información de apoyo |
|---|---|---|
| Estado de copia de seguridad | Comprobar qué falló en la exportación o en la retención | Resumen JSON, resultados por máquina y registros de la tarea |
| Copia Hyper-V en Servidor | Comprobar por qué falta un resultado reciente | Última fecha aceptada, programación de Windows, servicio Attacus y conectividad |
| Ambas | Revisar el último error comunicado y la falta posterior de resultados | Histórico de ambos monitores y cronología de la tarea |
El recorrido del técnico es:
Leer la incidencia: consultar el nombre del monitor, el motivo del fallo y la posible solución.
Investigar: abrir el monitor, revisar su última evaluación y consultar la telemetría y el resumen de la tarea.
Intervenir: corregir la causa y comprobar el resultado de la siguiente ejecución o de una prueba controlada.
Verificar la recuperación: confirmar que llega un resultado reciente y correcto, que los monitores recuperan su disponibilidad y que la incidencia deja de estar activa.
Una nueva lectura falsa puede recuperar la actualidad del dato y mantener el fallo de la copia. Del mismo modo, un «Sí» antiguo no recupera la continuidad. Revisa las dos dimensiones antes de dar el trabajo por terminado.
Si una intervención requiere apartar temporalmente una alerta del foco, utiliza una inhibición con motivo y vigencia. El siguiente técnico debe poder entender qué se está atendiendo y hasta cuándo dura esa decisión. La inhibición conserva la incidencia y su seguimiento; la recuperación depende de las evaluaciones del monitor.
La revisión diaria aporta visibilidad y seguimiento de mantenimiento con una atención diferida acorde al turno. El tiempo hasta que una persona atiende una incidencia depende también de cuándo pueda revisar el panel.
La incidencia en el panel y las opciones del técnico
Para completar el recorrido se provocó de forma controlada un incumplimiento de la condición booleana de Estado de copia de seguridad. La siguiente captura muestra el resultado en el panel: el monitor está Indisponible, el diagnóstico es valor_inesperado y la alerta aparece visible en el foco principal. Es una prueba del circuito de supervisión y atención; no acredita un fallo real de la exportación.
Qué mirar: el seguimiento conserva las fechas de apertura, confirmación y ejecución. El engranaje reúne las operaciones manuales disponibles sobre la incidencia:
| Opción | Uso durante la revisión |
|---|---|
| Ver monitor | Abrir la actividad y contrastar el diagnóstico con la configuración, las lecturas y el contexto operativo |
| Inhibir… | Preparar una retirada temporal del foco, con motivo y vigencia, cuando la intervención lo justifique |
La captura muestra el menú abierto; no se aplicó una inhibición para obtenerla. La incidencia de copia permanece en el foco principal. El contador de alertas inhibidas corresponde a otra incidencia de la instalación.
Los monitores de esta receta siguen sin acciones automáticas vinculadas. El técnico dispone de una incidencia visible y de acceso a su evidencia para decidir cómo intervenir durante su turno.
Al terminar una prueba de este tipo, restablece el criterio previsto para producción: verdadero como valor normal en el monitor del resultado. Comprueba después su evaluación y la recuperación en el panel. Si el resultado real es falso, corresponde investigar la copia y verificar una ejecución correcta.
Ejemplo de resultado recibido en Sentinelia
La captura de telemetría muestra tres de las lecturas con el tag pruebas_copiasvm: el resultado booleano, su fecha de aceptación y el resumen JSON. Attacus genera también la fecha de aceptación del JSON, que queda fuera de ese encuadre. Los nombres del servidor y de la máquina virtual se han sustituido por HV-LAB01 y VM-APLICACIONES en el ejemplo publicado.
El recorrido del ejemplo corresponde al 11 de noviembre de 2026. Al leer las fechas, distingue dos tratamientos:
Fechas de Attacus y Sentinelia: las señales de tipo fecha, como
copia_correcta_aceptada_en, y las marcas de observación y recepción se normalizan a UTC en el backend. La interfaz de Sentinelia las presenta en la zona horaria del navegador, normalmente la del equipo desde el que se consulta. A esas fechas de la interfaz se refiere la etiqueta «hora local».Fechas dentro del JSON:
inicioyfinforman parte del contenido enviado por el script. Conservan sus valores ISO 8601 y el desplazamiento indicado, aquí+01:00. El navegador muestra ese contenido sin convertir sus fechas internas a otra zona horaria.
La tabla reúne tiempos de la operación y de su comunicación. Los horarios del ejemplo se expresan con la referencia +01:00; los rótulos de hora local de las capturas pertenecen a las fechas de la interfaz, no a una transformación del JSON.
En este ejemplo, la tarea comienza a las 14:16:00 y termina a las 14:27:12,73. Después se aceptan y reciben las señales que permiten seguir el resultado en Sentinelia:
| Dato | Resultado del ejemplo |
|---|---|
| Exportación | Una máquina, de 14:16:00 a 14:27:12,73; duración declarada de 672,73 segundos |
hyperv.copia_correcta:pruebas_copiasvm |
Sí, con calidad válida; observado a las 14:33:46,19 y recibido a las 14:33:50,19 |
hyperv.copia_correcta_aceptada_en:pruebas_copiasvm |
Fecha 14:33:46,19, con origen calculado; recibida a las 14:33:51,19 |
hyperv.copia_resumen:pruebas_copiasvm |
JSON con calidad válida; observado a las 14:41:01,19 y recibido a las 14:41:03,19 |
Con ambas señales autorizadas previamente en Attacus, el script entrega primero el booleano y después el resumen JSON. El booleano expresa el resultado de la exportación y la retención; el resumen conserva el detalle de esa misma ejecución. La aceptación de cada señal y su recepción en Sentinelia son momentos distintos de la finalización de la tarea.
El JSON siguiente representa una ejecución correcta con el mismo formato que genera cp-attacus.ps1. ejecucion_id identifica la ejecución, resultados contiene el resultado de cada máquina y errores recoge los problemas de preparación, exportación o retención. errores_registro recoge los fallos al escribir los registros locales. El resumen se prepara antes de enviar las señales a Attacus.
Las capturas ilustran la presentación de las señales en el portal. El contenido siguiente y el archivo descargable muestran el ejemplo de salida del script, con los nombres y el horario utilizados en este recorrido.
Consultar el ejemplo de resumen generado por PowerShell.
{
"version": 1,
"operacion": "exportacion_hyperv",
"ejecucion_id": "0ba40c72-f866-4b97-a412-200f7a772d0b",
"estado": "correcta",
"resumen": "Copia completada: 1 de 1 maquinas exportadas. Retencion aplicada: 4 copias Weekly.",
"correcta": true,
"empresa": "Mi empresa",
"servidor": "HV-LAB01",
"tipo": "Weekly",
"destino": "C:\\temp\\copiasVM\\Prueba_20261111_141600_000",
"carpeta_copia": "C:\\temp\\copiasVM\\Prueba_20261111_141600_000\\Weekly_2026_11_11_14-16-00-008",
"inicio": "2026-11-11T14:16:00.0000000+01:00",
"fin": "2026-11-11T14:27:12.7298991+01:00",
"duracion_segundos": 672.73,
"retencion": 4,
"solicitadas": 1,
"exportadas": 1,
"maquinas_solicitadas": [
"VM-APLICACIONES"
],
"resultados": [
{
"nombre": "VM-APLICACIONES",
"correcta": true,
"error": null
}
],
"errores": [],
"errores_registro": []
}
Comprobar el recorrido en tu instalación
Comprueba una ejecución correcta, un resultado de error controlado y el vencimiento de la fecha sin recibir una nueva lectura. Para probar el silencio utiliza un plazo temporal de prueba y restablece después el plazo real. Revisa también la recuperación cuando llegue un resultado reciente; si es false, se recupera la actualidad del dato pero continúa el problema de la copia.
La alerta por silencio indica ausencia de un resultado reciente; no determina por sí sola si falló la programación, el equipo, Attacus o la comunicación. La continuidad del agente y el resumen de la tarea ayudan a investigar.
La exportación produce los archivos de las máquinas en el destino. Su resultado y su seguimiento deben completarse con las comprobaciones de recuperación que requiera tu política de copias, incluida una prueba de restauración.