Recuperación ante Desastres

Si un host muere, un restore sale mal, o necesitas mover Chinaski a una máquina nueva, este es el runbook. Existen tres capas de backup (backups del timer a nivel de sistema, backups de archivos in-app con un restore de un clic, y un restore de sube-tu-propio-archivo) y saber cuál alcanzar es la mayor parte del trabajo.

Lo que deberías tener antes de que llegue el desastre

El backup diario del sistema (backup.sh bajo systemd): un snapshot en gzip de la base de datos, seguro con WAL, en /var/backups/chinaski<N>/ (verificado por integridad antes de conservarse, modo 0600, conservado 14 días por defecto) más un espejo rsync del directorio de media.
Backups in-app (Admin → Backups): archivos chinaski_backup_<timestamp>.tar.gz completos que contienen la base de datos, el media, los themes y los site templates, creados manualmente, automáticamente en un schedule diario o semanal que ajustas en la pestaña Backups, y opcionalmente enviados a un bucket de DigitalOcean Spaces.
El archivo env del host viejo (/etc/chinaski<N>/env con CHINASKI_SECRET, LISTEN_URL), ver la advertencia de “same secret” abajo. Respáldalo ahora; no está en la base de datos y no está en el tar.gz.

Restaurar en el sitio (el caso común)

Desde Admin → Backups, sube un chinaski_backup_*.tar.gz:

Los uploads de restore están limitados a 50 MiB.
Usa dry run primero: stagea el archivo y previsualiza qué cambiará, luego un clic de confirmación ejecuta el restore real.
El restore valida el archivo (el manifest del backup debe coincidir), luego lo aplica en un orden seguro: la base de datos se restaura atómicamente primero, luego el directorio de media se intercambia (con rollback si el intercambio falla), luego los themes y site templates se restauran; los fallos ahí se reportan como advertencias, no como abortos totales.
Si el backup fue hecho por una versión de schema distinta a la de la app en ejecución, el restore se niega en lugar de arriesgarse a corrupción; actualiza la app (o la versión que hizo el backup) en su lugar.
Opciones para restaurar: subir desde tu navegador, o restaurar directamente desde un backup almacenado en Spaces si Spaces está configurado. Los restores automáticos por API también están disponibles (mismas reglas) para scripting.
Lo que toca el restore es visible en el audit log; los restores fallidos dejan el site sin cambios.

Reconstruir un host perdido

Instala un Chinaski nuevo en el host nuevo con el instalador estándar (mismo patrón de nombre de instancia). Esto crea el usuario de servicio, una base de datos vacía y un nuevo archivo env.
Restaura el archivo env, no mezcles secrets. Copia el /etc/chinaski<N>/env viejo sobre el generado antes de arrancar, o espera que las settings cifradas (contraseña SMTP, secrets cifrados de API) almacenadas en una base de datos restaurada sean indescifrables. La key de cifrado de los secrets almacenados se deriva de CHINASKI_SECRET; restaurar una base de datos bajo un secret distinto arroja silenciosamente valores vacíos en lugar de un error, así que arregla primero el secret del env y, si no puedes, vuelve a guardar las settings después.
Restaura los datos de los backups que conservaste, más fácil vía el restore in-app de arriba (sube el tar.gz).
Haz rebuild del site estático (página del builder vía “Rebuild” en el dashboard de Settings) y pon el site en vivo con la configuración de reverse proxy/TLS de los ejemplos de deploy; luego verifica que /health responde y el contenido se renderiza.

Recuperarse con solo los backups del sistema

Si la ruta del tar.gz no está disponible, el snapshot diario de la DB en /var/backups más el espejo de media bastan:

Descomprime con gzip chinaski-<timestamp>.db.gz de vuelta a la ruta de la base de datos.
Sincroniza el espejo de media de vuelta al directorio de media de la instancia.
Ten presente la estrecha ventana de consistencia documentada en el propio script de backup: el snapshot de la DB se toma antes del espejo de media, así que un archivo de media borrado segundos antes del backup puede existir en la DB pero no en el árbol de media. El paso de reconciliación documentado es borrar las filas de media cuyo archivo falta en el directorio de media restaurado (un pase por nombre de archivo sobre la tabla de media), lo cual los comentarios del script de backup detallan.
Después del restore: dispara un rebuild, verifica /health, y toma un backup in-app fresco para restablecer tu red de seguridad normal.

Barandillas que conviene conocer

Los restores validan el manifest del backup y rechazan de plano los desajustes de versión de schema (“Restore aborted to prevent data corruption”), así que un backup de una versión mucho más vieja necesita restaurarse en la versión de app correspondiente.
La verificación de backups corre sobre cada archivo creado por defecto (hay una setting backup-verify; está activada a menos que se apague explícitamente).
Como los backups contienen hashes de contraseñas y secrets de sesión, trata el directorio de backups y cualquier tar.gz descargado como sensible: el directorio de backup del sistema se fuerza a modo 0700 en cada ejecución, y los snapshots se almacenan en modo 0600.
Un backup programado de Spaces corre solo cuando Spaces está completamente configurado (endpoint, bucket, access key, secret key) y solo cuando el modo air-gap está apagado.
La hora del último backup automático es visible en la pestaña Backups, junto a la lista de backups locales; haz una inspección rápida después de cualquier cambio de servidor.