> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zylon.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Borrado permanente
> Configure la politica de retencion usada por la tarea de limpieza
**Próxima versión — Zylon 1.58**
Esta 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](/es/v1.57/overview).
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.
```yaml theme={null}
zylonBackend:
scheduler:
cleanup:
enabled: false
cron: "0 3 * * *"
timezone: "UTC"
minimumIntervalMinutes: 1440
workspace:
enabled: true
deleteAfterDays: 14
logging:
enabled: false
deleteAfterDays: 180
```
## 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.
```yaml theme={null}
zylonBackend:
scheduler:
cleanup:
enabled: true
cron: "0 3 * * *"
timezone: "Europe/Madrid"
workspace:
enabled: true
deleteAfterDays: 365
logging:
enabled: true
deleteAfterDays: 180
```
`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](#valores-de-zona-horaria) 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:
```text theme={null}
minute hour day-of-month month day-of-week
```
Use valores dentro de estos rangos:
| Campo | Valores aceptados |
| - | - |
| Minuto | `0-59` o `*` |
| Hora | `0-23` o `*` |
| Dia del mes | `1-31` o `*` |
| Mes | `1-12` o `*` |
| Dia de la semana | `0-6` o `*` |
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](https://datetime.app/iana-timezones).
### 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](/es/v1.58/operator-manual/configuration/features/log-delivery-storage#configurar-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](/es/v1.58/customer-support-manual/zendesk-client-manual).
## 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.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.