Skip to main content
Próxima versión — Zylon 1.58Esta documentación se publica antes del lanzamiento para que puedas preparar tus integraciones de API. La imagen de la versión todavía no está disponible. Para instalaciones con 1.57, consulta la documentación de 1.57.
La tarea de borrado permanente elimina definitivamente los elementos despues de que primero se hayan eliminado en Zylon o marcado como inactivos. Cuando se eliminan chats, proyectos, archivos u organizaciones en Zylon, siguen siendo recuperables hasta que vence la ventana de retencion. Esta configuracion de limpieza permite que cada organizacion alinee el borrado permanente de Zylon con su propia politica de retencion de datos.

​
Configuracion predeterminada

La limpieza programada está deshabilitada por defecto. Los valores de Helm configuran una programación diaria a las 03:00 UTC y un umbral de retención de Workspace de 14 días, que se usa al habilitar la limpieza. Helm define timezone: "UTC"; si se omite la zona horaria del runtime fuera de Helm, se usa la de la máquina servidor. La limpieza de logs almacenados usa el mismo programador de limpieza. Esta desactivada por defecto; cuando se activa, el umbral predeterminado de retencion de logs almacenados es 180 dias.

​
Ejemplo de configuracion

Edite /etc/zylon/zylon-conf.yaml y luego aplique el cambio con sudo zylon-cli sync. Use una ventana de retencion que coincida con la politica de su empresa. Muchas organizaciones necesitan un valor bastante mayor que el predeterminado.
enabled activa o desactiva las revisiones programadas de limpieza. cron determina cada cuanto tiempo el sistema revisa elementos inactivos y logs almacenados, timezone define de forma opcional la zona horaria usada para interpretar la expresion cron y workspace.enabled activa o desactiva el borrado permanente de datos de workspace. deleteAfterDays es el numero de dias que deben pasar antes de que un elemento inactivo o un elemento eliminado previamente se elimine de forma definitiva por la ejecucion del cron. logging.enabled activa o desactiva la limpieza de logs almacenados, y logging.deleteAfterDays elimina registros de log almacenados con mas antiguedad que ese umbral. Helm usa UTC por defecto; si se omite la zona horaria del runtime fuera de Helm, se usa la de la máquina servidor.
Sugerimos configurar una zona horaria IANA que coincida con la zona horaria de la empresa.

​
Valores aceptados

​
Valores de cron

La limpieza usa el mismo formato cron de 5 partes que la sincronizacion:
Use valores dentro de estos rangos: Ejemplos:
  • 0 3 * * * se ejecuta todos los dias a las 03:00
  • 15 4 * * 0 se ejecuta cada domingo a las 04:15

​
Valores de zona horaria

zylonBackend.scheduler.cleanup.timezone usa UTC por defecto en Helm. Si se omite el ajuste del runtime fuera de Helm, el cron usa la zona horaria de la máquina servidor. El cron también debe cumplir minimumIntervalMinutes, cuyo valor predeterminado en Helm es 1440; un cron más frecuente se rechaza salvo que se reduzca ese valor. Cuando configure zylonBackend.scheduler.cleanup.timezone, use un identificador IANA valido. Ejemplos comunes:
  • UTC
  • Europe/Madrid
  • America/New_York
  • America/Los_Angeles
  • Asia/Tokyo
  • Pacific/Auckland
  • Africa/Johannesburg
Para una lista practica de identificadores de zona horaria IANA, consulte IANA Time Zones.

​
Valores de retencion

Para zylonBackend.scheduler.cleanup.deleteAfterDays, use un numero entero positivo de dias como 14, 30, 90 o 365, segun su politica de retencion. Para zylonBackend.scheduler.cleanup.logging.deleteAfterDays, use un numero entero positivo de dias. El valor predeterminado es 180 dias, aproximadamente seis meses.
Usa ventanas de retención positivas según la política de tu empresa. Para logs almacenados, logging.deleteAfterDays: 0 no deshabilita el borrado: hace que los logs existentes sean elegibles para limpieza. Para deshabilitar la limpieza de logs, configura logging.enabled: false. Para retener logs sin borrado permanente de Workspace, sigue Limpieza solo de logs.

​
Acceso antes del borrado permanente

Antes de que expire la ventana de retencion, los datos eliminados todavia no se han borrado de forma definitiva. Durante ese tiempo, un operador puede usar el flujo de migracion y restauracion por CLI para recuperar organizaciones, proyectos, chats o archivos. Si necesita ayuda para realizar esa recuperacion, tambien puede contactar con Atencion al cliente.

​
Ejecucion y manejo de fallos

La tarea de limpieza se ejecuta segun el cron configurado y revisa si los elementos inactivos y los elementos eliminados previamente ya superaron la ventana de retencion deleteAfterDays. Cuando la superan, el sistema los marca para borrado permanente y los elimina de Zylon. Una ejecucion de limpieza puede borrar definitivamente chats, archivos, proyectos y organizaciones, junto con otros datos en cascada. Los fallos por elemento se registran. La tarea continua con los demas elementos y la siguiente ejecucion programada reintenta los pendientes.