Backup Schedule & Retention

Chinaski mantiene tu contenido seguro con backups en dos ejes: tu app o tu servidor pueden programarlos automáticamente, y cualquiera puede podar los viejos para mantener acotado el uso de disco. Esta página explica los ajustes de schedule, qué corre y cuándo, y cómo funciona la retención.

Programar backups en la app

Bajo Settings → Backups puedes habilitar backups automáticos con dos ajustes:

Backup frequency: Off (por defecto), Daily o Weekly.
Backup time: la hora local de ejecución, por defecto 02:00.

Cuando está habilitado, la app revisa cada minuto e inicia un backup en el momento en que el reloj alcanza tu hora configurada: una vez al día para un schedule Daily, o no más de una vez cada siete días para Weekly. Si varios workers del servidor están corriendo, la coordinación se maneja internamente: exactamente uno se dispara, y los timestamps almacenados en settings evitan una segunda ejecución en la misma ventana.

Una ejecución programada hace todo el pipeline por su cuenta:

Crea el archivo (snapshot de base de datos más archivos de la aplicación), el mismo procedimiento de snapshot seguro que usan los backups manuales; los fallos se registran como ejecuciones fallidas en el historial de backups y en el audit log, y la ventana de tiempo omitida puede reintentarse después.
Verifica el archivo: cada backup se prueba de humo (verificación de restauración) antes de colocarse en la carpeta de backups, a menos que desactives la verificación. Cada ejecución registra si la verificación pasó, falló o se omitió.
Publica el archivo en la carpeta local de backups y, si has configurado almacenamiento cloud (un destino "Spaces" compatible con S3 con keys establecidas en Settings → Backups), lo empuja allá. En modo airgap nada deja el host. Si la key de almacenamiento cloud almacenada no puede leerse, el push remoto se omite en lugar de intentarse semi-configurado.

Retención (cuántos backups conservar)

Dos ajustes en Settings → Backups acotan cuántos backups se acumulan localmente: ambos por defecto 0, lo que significa ilimitado (la retención es opt-in):

Keep last N local backups: borra los archivos más viejos una vez que existan más de N.
Keep local backups for N days: borra los archivos más viejos que esa cantidad de días.

Detalles que conviene saber:

Las dos reglas se combinan generosamente, no estrictamente: un archivo solo se borra cuando está tanto más allá de los últimos N como más viejo que el límite de días ("conservar lo que sea más generoso").
La página de lista de backups previsualiza el efecto: puedes ver cuántos backups la política actual borraría antes de que corra alguna vez.
Cada borrado automático se registra en el audit log con la política que lo disparó.
Los barridos de retención también corren una vez cuando la app arranca, por si los backups se acumularon mientras el servidor estaba caído.
La nomenclatura de archivos lleva timestamp (chinaski_backup_YYYYMMDD_HHMMSS.tar.gz), así que nada se sobrescribe silenciosamente.

El backup programado del lado servidor (nivel OS)

Hay un segundo sistema de programación independiente incluido para despliegues systemd:

Un timer diario (chinaski-backup@) se dispara a las 03:17 hora local (minuto elegido para repartir carga si varias instancias comparten un host), con un pequeño delay aleatorio, y recupera el tiempo si el host estaba apagado cuando debía correr.
El script de backup hace un snapshot consistente de la base de datos (seguro mientras el CMS está vivo), lo comprime con gzip, verifica el archivo y lo almacena bajo /var/backups/chinaski<instance>. Los archivos de media se reflejan al lado. Los snapshots de más de 14 días se borran; cámbialo con CHINASKI_BACKUP_RETENTION_DAYS en el archivo env de la instancia (las rutas de backup y media también pueden sobrescribirse).
El snapshot y el media son legibles solo por el dueño (directorio 0700).
Antes de confiar en el timer, corre un backup manual y confirma que ambas partes completan.

Mantener los dos en orden

El scheduler de la aplicación y el timer del OS hacen trabajos similares con distintos alcances (archivo completo vs snapshot de base de datos + media; retención gestionada por la app vs el default de 14 días). Correr ambos está bien y es conservador. De quien dependas: vigila el historial de la pestaña Backups: cada intento programado registra su resultado (éxito, fallo y qué tipo de backup manual/programado/API/push fue), incluidos los resultados de verificación de cada ejecución.