Actualización

Lo que está establecido sobre la actualización de la solución, la preparación que le corresponde a usted antes de ella, las trampas específicas de versión que constan por escrito, y cómo verificar una

El procedimiento de actualización debe validarse contra las dos versiones implicadas: la instalada y aquella a la que se dirige. Ninguna secuencia única de pasos sirve para todos los pares de versiones: al menos una release exige un reinicio, y un rango de releases eliminó una capacidad que una release posterior restauró. Establezca primero ambos números de versión, lea las notas de todas las versiones intermedias, y confirme el procedimiento con el soporte de implantación de DataDike antes de empezar.

Qué es esto y cuándo usarlo

Esta página cubre lo que ocurre alrededor de una actualización: la preparación que le corresponde a usted, los hechos específicos de versión que constan por escrito, y las comprobaciones que le dicen que la actualización cuajó.

No da una secuencia de comandos de actualización, porque no hay ninguna que pueda darse honestamente.

El material de origen de esta wiki no contiene ningún procedimiento de actualización paso a paso. Describe el modelo de actualización y registra cambios específicos de versión, pero no los comandos, ni el orden de las operaciones, ni la vía de rollback. Eso debe venir del soporte de implantación de DataDike o de su distribuidor, para su instalación y su par de versiones concretos. No ensamble un procedimiento a partir de fragmentos: una actualización ejecutada desde una secuencia adivinada es un evento de pérdida de datos, no un cambio fallido.

Qué está establecido sobre las actualizaciones

Hecho	Consecuencia para usted
En el modelo SaaS, el alojamiento, la infraestructura y la operación son responsabilidad de DataDike, y el licenciamiento por suscripción incluye actualizaciones continuas de versión (correcciones y funciones nuevas) sin coste adicional durante la vigencia, con soporte del proveedor 24x7x365	Usted no ejecuta la actualización. Confirme la ventana y lea las notas de versión
Los componentes pueden actualizarse individualmente, sin detener el producto	Se enuncia como una capacidad de la arquitectura, no como un procedimiento. No significa que una actualización concreta sea no disruptiva: son las notas de versión las que dicen si hay un reinicio de por medio
Las instalaciones on-premises funcionan en activo/activo	Un nodo puede quedar fuera de servicio durante el cambio sin que el servicio se detenga, pero solo si el cambio se aplica realmente nodo a nodo
Las correcciones y actualizaciones del sistema operativo las publica y firma DataDike y se aplican de forma controlada, con la compatibilidad de la plataforma preservada en cada actualización y un ciclo de vida gestionado que evita componentes en fin de vida	El sistema operativo y la aplicación se actualizan por el canal del proveedor, no desde los repositorios upstream de la distribución
La consola del appliance ofrece Reboot y Shutdown	Use esas opciones en lugar de improvisar un apagado del appliance

Antes de empezar

Todo lo que sigue es preparación que le corresponde a usted, sea quien sea quien ejecute la actualización.

1. Anote la versión instalada y la versión de destino. Todo hecho de esta página y de las notas de versión está condicionado a esos dos números. Sin ambos, nada de lo de aquí puede aplicarse.

2. Lea las notas de cada versión intermedia, no solo las de la de destino. Liste cada elemento que exija un reinicio, cambie un valor por defecto, o elimine o restaure una capacidad. Consulte Notas de versión.

3. Haga una copia de seguridad y restáurela en algún sitio. Una copia de seguridad sin probar no es un plan de rollback. Consulte Copia de seguridad y restauración.

4. Confirme la validez de la licencia para la ventana. Todas las funciones siguen deshabilitadas hasta que se importa una licencia, y una licencia vencida deja un periodo de gracia de siete días para importar la nueva. Una ventana de actualización es un mal momento para descubrir que la licencia caducó.

5. Programe fuera de la limpieza nocturna. Las tareas de mantenimiento y de limpieza se ejecutan de madrugada: la fuente cita las 02:00 para los trabajos diarios de limpieza y recomienda mantener las actualizaciones de sistema y los reinicios de worker fuera de la franja de 02:00 a 04:00, para que las tareas automatizadas no se interrumpan a mitad de ejecución.

6. Acuerde quién ejecuta el cambio y abra la solicitud con el soporte indicando ambos números de versión.

7. Registre cómo se ve un sistema sano ahora, antes del cambio, para que "¿estaba así antes?" tenga respuesta después: la respuesta actual de /api/health/, la lista de componentes con todos sus estados, y los dos workers de tareas en En línea. Consulte Monitorización y salud.

Hechos específicos de versión que constan por escrito

Proceden de las notas de versión y son la razón de ser del aviso que encabeza esta página. Se aplican únicamente a las versiones nombradas.

Versión o rango	Qué cambia	Qué significa para usted
5.0.1	Pasa a exigir comunicación TLS 1.3 entre la VM de Gateway y el servidor	La nota de versión declara que es necesario un reinicio
De la 5.0 a la 5.0.9	La edición de un activo para darle un nombre descriptivo personalizado se eliminó por error	Si está en ese rango, la capacidad falta. Es una regresión conocida, no un problema de configuración
5.1.0 (18 de agosto de 2026)	Se reintroduce la edición del nombre descriptivo. Los entornos que ya tenían renombrados individuales no pierden la personalización	La corrección para el rango anterior
Nota del 04 de mayo de 2026	Mejoras de fiabilidad y estabilidad en el proceso de actualización de la VM de gateway, con menor tiempo de caída entre versiones. El titular de la nota dice Broker VM mientras que su cuerpo dice Gateway VM: trate el componente como no confirmado	Las VM de broker y de gateway siguen su propia vía de actualización, separada de la de la plataforma

Una capacidad que falta después de una actualización no siempre es un error de configuración. La regresión del nombre descriptivo de la 5.0 a la 5.0.9 es el caso documentado: el ajuste desapareció de la consola, y ninguna cantidad de trabajo sobre permisos o políticas lo habría devuelto. Antes de investigar una función ausente, compruebe si las notas de versión la registran como eliminada.

Pasos

La ejecución le corresponde al soporte. El cambio que la rodea es suyo, y tiene una forma:

1. Establezca las versiones instalada y de destino.

2. Lea todas las notas de versión intermedias y anote los elementos que exigen un reinicio o cambian el comportamiento.

3. Haga la copia de seguridad, y demuéstrela restaurándola en una instancia de prueba.

4. Capture la línea base de salud previa al cambio descrita en Antes de empezar.

5. Abra el cambio con el soporte, indicando ambas versiones y los elementos que encontró en el paso 2.

6. Acuerde una ventana fuera de las horas de limpieza nocturna.

7. Ejecute la actualización junto con el soporte.

8. Verifique, con las comprobaciones de más abajo, antes de dar la ventana por cerrada.

No comprima los pasos 3 y 4. Son los dos que marcan la diferencia entre un rollback y un incidente.

Cómo verificar que funcionó

Una actualización que devuelve una página de inicio de sesión no ha demostrado casi nada. Trabaje hacia fuera, partiendo de las dependencias:

1. /api/health/ devuelve status, db_status y redis_status todos verdaderos. En un clúster, consulte la dirección virtual y cada nodo individualmente: un nodo dejado en la versión antigua, o excluido del reinicio, queda invisible tras la dirección virtual.

2. Configuración del sistema › Componentes muestra todos los componentes en Normal y ninguno en Sin conexión. Compare con la línea base que capturó: un componente presente que antes estaba en Normal y ahora está en High load es un hallazgo.

3. El motor de tareas está en marcha. Desde Configuración del sistema › Operaciones, abra Supervisión: ambos workers, el de mantenimiento y el de automatización, en En línea, y las colas sin acumulación de mensajes pendientes. Después compruebe, en la lista de operaciones, que la fecha de última publicación de una tarea de ciclo corto avanza tras la actualización. Un worker que ha vuelto pero no consume tiene el mismo aspecto que uno sano hasta que se hace esta comprobación.

4. Una sesión real por cada protocolo que use de verdad (terminal, gráfico, base de datos), abierta de extremo a extremo y no solo lanzada. Confirme que cada una aparece en el registro de auditoría y que su grabación se reproduce. Los conectores de protocolo son componentes separados; que uno de ellos no vuelva es el síntoma más habitual de una actualización parcial.

5. Una automatización se completa. Deje que se ejecute una rotación de credencial o una prueba de conectividad, y confirme el éxito en su historial de ejecución. Esto ejercita a la vez el worker de automatización y los activos.

6. Inicie sesión a través de su proveedor de identidad, con MFA. Que funcione el inicio de sesión local demuestra menos de lo que parece.

7. Confirme la fecha y la hora del servidor. Si el reloj está mal, los códigos OTP se rechazan y el inicio de sesión con MFA falla: la fuente señala una fecha y hora de servidor incorrectas como causa del error de OTP inválido. Un reinicio durante una actualización es exactamente cuando un reloj se desvía.

8. Abra la consola por su nombre HTTPS y confirme que el certificado sigue sirviéndose correctamente. Consulte Certificados y HTTPS.

Errores frecuentes

Síntoma	Causa	Solución
Una capacidad que funcionaba antes ha desaparecido	Regresión conocida en la versión a la que se movió. El caso documentado son los nombres descriptivos personalizados de los activos, eliminados entre la 5.0 y la 5.0.9	Consulte las notas de versión del rango antes de investigar. Para ese caso, la 5.1.0 la restaura
Códigos de MFA o de OTP rechazados justo después de la actualización	Fecha y hora del servidor incorrectas tras el reinicio	Corrija el reloj del servidor; la fuente documenta esto como causa del error de OTP inválido
Un nodo del clúster se comporta de forma distinta a los demás	No todos los nodos se actualizaron o se reiniciaron	Consulte /api/health/ en cada nodo, además de en la dirección virtual, y compare
Todas las tareas automáticas se detuvieron tras la actualización	Un worker de tareas no volvió	Operaciones › Supervisión, pestaña de workers; el servicio de tareas de ese servidor necesita reiniciarse
Un ajuste cambiado en el archivo de configuración del appliance no surte efecto	La configuración que reside en el config.txt del appliance se lee al arrancar el servicio	Los servicios tienen que reiniciarse después de que el archivo cambie
Las conexiones de gateway fallan tras pasar a la 5.0.1	Esa release pasa a exigir TLS 1.3 entre la VM de Gateway y el servidor, y declara que es necesario un reinicio	Reinicie como exige la nota de versión; confirme que el lado del gateway soporta TLS 1.3
Las sesiones se abren pero no se graba nada	El componente de grabación o de procesamiento de vídeo está sin conexión, o el backend de almacenamiento es inalcanzable	Revise Componentes y la notificación de Almacenamiento: Conectividad

Páginas relacionadas

• Notas de versión

• Copia de seguridad y restauración

• Monitorización y salud

• Certificados y HTTPS