Copias de Seguridad y Recuperación

Chinaski ejecuta tres capas de backup cooperantes, cada una con un trabajo distinto . así que ninguna falla única se lleva tu site con ella. Esta página te orienta sobre las capas y enlaza las páginas detalladas.

Juntas cubren el stack estándar de resiliencia: snapshots locales frecuentes para recuperación rápida tras errores, archivos completos in-app para recuperación completa point-in-time y copias off-site, y . en tiers de base de datos hosted . una copia cloud off-site que sobrevive a la pérdida total de la máquina.

Las tres capas

• El backup diario del sistema . un timer systemd ejecuta backup.sh una vez al día (por defecto 03:17, deliberadamente fuera de las horas pico). Toma un snapshot de SQLite WAL-safe, lo verifica por integridad antes de conservarlo, lo comprime con gzip y lo guarda en /var/backups/chinaski<N>/ con una retención por defecto de 14 días (configurable). El directorio de media se refleja por separado con rsync, porque los archivos de media son inmutables después de subirlos y un espejo es seguro de mantener incrementalmente.
• Backups in-app (Admin → Backups) . archivos .tar.gz completos que contienen la base de datos y el media y los themes y los site templates. Se crean manualmente, en un schedule diario o semanal, y (opcionalmente) se empujan automáticamente a un bucket de DigitalOcean Spaces para almacenamiento off-site. Cada archivo creado se verifica por defecto antes de contar.
• Flujos de restore . el lado del restore vive con los backups: subir un archivo (con una vista previa dry-run y paso de confirmación), restaurar desde un archivo almacenado en Spaces, o restaurar a mano desde el snapshot diario del sistema durante la recuperación de desastres.

Qué contiene un backup

Los snapshots a nivel de sistema capturan la base de datos (todo el contenido, usuarios, settings, logs) más un espejo de media. Los archivos in-app capturan la base de datos más el media más los themes más los site templates . todo lo que está hecho el site, en un archivo que puedes llevar a otro host. Las páginas daily y Spaces+restore recorren los contenidos exactos de cada capa.

Los caminos que esta sección cubre

• Backup Schedule & Retention . dónde viven los schedules automáticos (cron/timers del sistema y ajustes de schedule in-app), las perillas de retención tanto para snapshots de base de datos como para archivos in-app locales, y cómo se comporta el pruning.
• Backup Manual . archivos point-in-time: qué hay en el archivo, crear, descargar, borrar; la advertencia de que los flujos manuales son parte del mismo pipeline de retención/verificación.
• Restaurar . la superficie de restore in-app: vistas previas dry-run, gating por versión de schema, restore de base de datos atómico, swap de media por etapas; qué significa "restore refused".
• Recuperación ante Desastres . el runbook de host completo: reconstruir Chinaski en otro lugar a partir de lo que ya estás conservando.

Postura de seguridad que conviene saber de antemano

• La verificación está activada por defecto. Cada archivo in-app se extrae y valida después de crearse; una verificación fallida evita que se almacene un archivo defectuoso.
• Sensibles por diseño . los archivos contienen hashes de contraseñas y secrets cifrados. El directorio de backups se ajusta a modo 0700 en cada ejecución de backup del sistema, los archivos se escriben en modo 0600, y los controles de restore son solo de admin con cada restore auditado.
• Protege las credenciales, no solo los datos . restaurar una base de datos en una instancia cuyo CHINASKI_SECRET difiere pierde el acceso a las settings cifradas (contraseñas SMTP, secrets de webhook). El archivo env (CHINASKI_SECRET, LISTEN_URL) es un artefacto separado que deberías copiar durante cualquier migración de host completo; no está dentro de los backups.
• Todo está auditado . creación, restore, borrado y pruning de retención escriben todos entradas de auditoría con el actor y el nombre de archivo.