Mucha gente cree que para hacer una copia de seguridad basta con copiar el archivo de la base de datos. Solo cuando se cambia de servidor o se borran datos por error se descubre que: la base de datos se puede abrir, pero las claves de DeepSeek y la clave privada de pago que contiene no se pueden descifrar; o que la base de datos volvió, pero las imágenes y los archivos adjuntos se perdieron por completo. Este artículo explica con claridad el alcance de las copias de seguridad, las tareas programadas y el proceso de restauración de KingCMS X1.
Qué hace exactamente la copia de seguridad con un clic
La copia de seguridad del panel de administración no copia directamente el archivo de base de datos que se está escribiendo, sino que usa la interfaz de copia de seguridad en línea de SQLite para obtener una instantánea consistente, por lo que también se puede hacer mientras hay visitas en el sitio. Después de cada copia se ejecuta PRAGMA integrity_check; los archivos que no pasan la verificación no se registran como copias válidas. El registro guarda el nombre del archivo, tamaño, SHA256, origen (manual/programada/antes de restaurar), creador y fecha; de forma predeterminada se comprime con gzip en .sqlite.gz. Al marcar «incluir archivos subidos», la base de datos y data/uploads/ se empaquetan en un zip.
Lo más fácil de pasar por alto: app.key
data/app.key no está incluido en la copia de seguridad. Se encarga de descifrar los campos de claves en la configuración: DeepSeek API Key, clave privada de pago, claves de API de terceros dependen de él. Si solo se restaura la base de datos y no se restaura app.key, esas configuraciones se convierten en texto cifrado imposible de descifrar. Al cambiar de servidor o reinstalar el sistema, hay que respaldar data/app.key por separado, llevarlo junto con todo lo demás y no subirlo a ningún repositorio.
Qué hay que llevarse al cambiar de servidor
Lo más seguro es llevarse todo el directorio data/: base de datos, archivos subidos en uploads/, app.key y los registros de copias en backups/. Si solo se migra la base de datos, hay que llevar además app.key y uploads/; el resultado habitual de llevar solo la base de datos es «la página abre, todas las imágenes se rompen y las claves dan error».
Copias de seguridad programadas
En «Ajustes → Seguridad y sistema → Copia de seguridad de datos» se puede configurar: intervalo de copia automática (desactivado/todos los días/todas las semanas, se ejecuta los lunes), hora de ejecución (por defecto 03:15, según la zona horaria del sitio), número máximo de copias conservadas (por defecto 15; al superarlo se eliminan automáticamente las copias programadas más antiguas; las copias manuales y las de antes de restaurar no se eliminan automáticamente) y si se comprime. Las copias programadas solo respaldan la base de datos, no incluyen los archivos subidos.
Las copias programadas dependen de que el programador ejecute cron:run cada minuto. En el panel de BT, basta con crear una tarea Shell en «Tareas programadas» y elegir un período de 1 minuto; el comando debe ejecutarse con el usuario que ejecuta el sitio web para evitar que el propietario de los archivos sea incorrecto. Sin el programador, las copias automáticas no se activan y solo se pueden hacer manualmente desde el panel de administración.
Proceso de restauración
En la lista de copias de seguridad, despliega «Restaurar» e introduce el nombre del sitio o «confirmar». El sistema primero verifica el archivo seleccionado y, si falla, lo rechaza directamente; .sqlite.gz se descomprime primero en un archivo temporal y luego se verifica. Si la verificación pasa, se genera automáticamente una copia «antes de restaurar» y después se sobrescribe la base de datos actual con los datos de la copia, manteniendo la estructura actual de la base de datos (los registros de migración no se restauran); por último, se cierran todas las sesiones iniciadas y el administrador debe volver a iniciar sesión. La restauración sobrescribe los datos actuales, por lo que se recomienda hacerla en horas de baja actividad y confirmar que se ha elegido la copia correcta.
Aprovechar para hacer mantenimiento de la base de datos
Después de eliminar datos, el archivo SQLite no se reduce automáticamente; el espacio queda en páginas libres. La tarea semanal de mantenimiento ejecuta VACUUM y, opcionalmente, tras el mantenimiento ejecuta PRAGMA optimize. Si en las 24 horas anteriores no ha habido una copia de seguridad correcta, antes del mantenimiento se hace automáticamente una copia; si no se puede obtener el bloqueo o está ocupado, se omite y se intenta en el siguiente ciclo. El mantenimiento ocupa un bloqueo de escritura, por lo que es más estable programarlo en horas de baja actividad.
Resumen
Recuerda tres cosas: la copia de seguridad debe incluir app.key y los archivos subidos; las copias programadas solo respaldan la base de datos y dependen de cron:run cada minuto; antes de restaurar, el sistema hace automáticamente otra copia, pero la sobrescritura es irreversible. Incluye estas tres reglas en la lista de operaciones y mantenimiento; así te ahorrarás muchos problemas en comparación con tener que recuperarlo todo después de un incidente.