> For the complete documentation index, see [llms.txt](https://wiki.datadike.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.datadike.com/es/pam/deploy-operate/upgrade.md). # 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 {% hint style="warning" %} **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. {% endhint %} ## 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. {% hint style="danger" %} **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. {% endhint %} ## 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](/es/pam/release-notes.md). 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](/es/pam/deploy-operate/backup-and-restore.md). 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](/es/pam/deploy-operate/monitoring.md). ## 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 | {% hint style="warning" %} **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. {% endhint %} ## 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](/es/pam/deploy-operate/certificates.md). ## 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](/es/pam/release-notes.md) * [Copia de seguridad y restauración](/es/pam/deploy-operate/backup-and-restore.md) * [Monitorización y salud](/es/pam/deploy-operate/monitoring.md) * [Certificados y HTTPS](/es/pam/deploy-operate/certificates.md)