Copia de seguridad y restauración

Guarde siempre una copia de los datos de su sitio. Con buenas copias de seguridad, si surge algún problema podrá recuperar todo tal como estaba, sin preocupaciones.

Qué puede hacer

Hacer una copia de seguridad de la base de datos con un clic, y también empaquetarla junto con los archivos subidos.
Los archivos de copia de seguridad se pueden descargar, eliminar y usar para restaurar.
Las copias de seguridad pueden ejecutarse automáticamente según una programación, sin necesidad de hacer clic manualmente cada día.
Antes de restaurar, el sistema guarda automáticamente otra copia como respaldo.

Cómo hacer una copia de seguridad manual

Inicie sesión en el panel de administración y vaya a la página «Configuración del sistema → Copia de seguridad de datos».
Haga clic en el botón de copia de seguridad con un clic. Si necesita incluir los archivos subidos, marque «Incluir archivos subidos».
Cuando finalice la copia, aparecerá un registro en la lista con el nombre del archivo, el tipo, el tamaño, el SHA256, el origen, el creador y la hora.
Para descargar, haga clic en «Descargar». El archivo se entrega como adjunto, solo es accesible para administradores con sesión iniciada y la acción se registra en el registro de auditoría.

Los archivos de copia de seguridad se guardan en data/backups/. Este directorio está fuera de la raíz del sitio public/ y se crea automáticamente en la primera copia de seguridad. Los nombres de archivo incluyen una marca de tiempo y una parte aleatoria, por lo que la URL de descarga no se puede adivinar.

Las copias de seguridad de la base de datos se comprimen de forma predeterminada y se guardan como .sqlite.gz. Puede desactivar «Comprimir archivos de copia de seguridad» en «Configuración del sistema → Copia de seguridad de datos»; al desactivarlo, se guardan como .sqlite sin comprimir.

Cómo restaurar

En la lista, despliegue «Restaurar» e introduzca el nombre del sitio o «confirmar».
El sistema primero valida el archivo seleccionado; si la validación falla, se rechaza la restauración.
Una vez superada la validación, el sistema crea automáticamente una copia de seguridad «previa a la restauración».
Los datos de la copia de seguridad sobrescriben la base de datos actual, conservando la estructura actual de la base de datos.
Al finalizar la restauración, se borran todas las sesiones iniciadas y todos los administradores deben iniciar sesión de nuevo.

La restauración sobrescribe los datos actuales. Realícela en horas de baja actividad y confirme que ha seleccionado la copia de seguridad correcta.

Cómo configurar copias de seguridad programadas

Configure lo siguiente en «Configuración del sistema → Copia de seguridad de datos»:

Opción	Valor predeterminado	Descripción
Intervalo de copia automática	Diario	Opciones: desactivado, diario, semanal (semanal se ejecuta el lunes)
Hora de ejecución	03:15	Se ejecuta según la zona horaria del sitio, formato `HH:MM`
Máximo de copias a conservar	15	Al superarse, se eliminan automáticamente las copias programadas más antiguas; las copias manuales y las «previas a la restauración» no se eliminan automáticamente
Comprimir archivos de copia de seguridad	Activado	Las copias de la base de datos se guardan como `.sqlite.gz`; al desactivarlo, se guardan como `.sqlite` sin comprimir
Mantenimiento automático de la base de datos	Semanal	Opciones: desactivado, semanal; VACUUM se ejecuta solo dentro de `cron:run`
Día de mantenimiento	Domingo	Se calcula según la zona horaria del sitio
Hora de mantenimiento	03:45	Se ejecuta según la zona horaria del sitio, formato `HH:MM`
Optimizar estadísticas tras el mantenimiento	Activado	Ejecuta `PRAGMA optimize` al finalizar el mantenimiento

Las copias de seguridad programadas solo respaldan la base de datos y no incluyen los archivos subidos. El programador comprueba cada minuto mediante cron:run si toca ejecutar, y se ejecuta solo una vez al día (o a la semana).

Configurar el programador

Sustituya /var/www/kingcms y la ruta de PHP por las rutas reales de su servidor. Se recomienda ejecutarlo cada minuto.

crontab del sistema

* * * * * /usr/bin/php /var/www/kingcms/bin/kingcms cron:run >> /var/www/kingcms/data/cron.log 2>&1

Configúrelo con el usuario que ejecuta el sitio web (normalmente www-data) para evitar que los archivos se creen con un propietario incorrecto:

sudo -u www-data crontab -e

Servicio y temporizador de systemd

/etc/systemd/system/kingcms-cron.service:

[Unit]
Description=Tareas programadas de KingCMS

[Service]
Type=oneshot
User=www-data
ExecStart=/usr/bin/php /var/www/kingcms/bin/kingcms cron:run

/etc/systemd/system/kingcms-cron.timer:

[Unit]
Description=Ejecutar las tareas programadas de KingCMS cada minuto

[Timer]
OnCalendar=*:0/1
Persistent=true

[Install]
WantedBy=timers.target

Actívelo:

sudo systemctl daemon-reload
sudo systemctl enable --now kingcms-cron.timer

Panel BT (BaoTa)

En «Tareas programadas» (计划任务), cree una nueva tarea de script Shell, elija «N minutos» como intervalo e introduzca 1, y use el mismo contenido de script que el comando crontab anterior. Tras guardar, ejecútela una vez manualmente para confirmar que no hay errores.

Alojamiento compartido

Utilice la función «Tareas programadas» o «Cron Jobs» del proveedor de alojamiento para ejecutar el comando anterior cada minuto. Los alojamientos que no pueden ejecutar comandos Shell no pueden usar copias de seguridad automáticas y solo pueden hacer copias manuales en el panel de administración.

Programador de tareas de Windows

Cree una nueva tarea, establezca el desencadenador en «Diario» y marque «Repetir la tarea cada 1 minuto» con una duración de «Indefinidamente»; establezca la acción en «Iniciar un programa»:

C:\php\php.exe C:\kingcms\x1\bin\kingcms cron:run

En «Iniciar en», indique C:\kingcms.

Confirmar que está en ejecución

La página «Configuración del sistema → Copia de seguridad de datos» muestra:

Última ejecución: la hora en que el programador ejecutó cron:run por última vez.
Última copia automática: la hora de creación de la copia programada más reciente.
Tamaño del archivo de base de datos / Espacio recuperable / Último mantenimiento: uso de la base de datos y resultados del mantenimiento; haga clic en «Mantener ahora» para añadir manualmente una tarea de mantenimiento a la cola.

Si el programador no se ha ejecutado durante más de 10 minutos, o nunca se ha ejecutado, aparecerá una barra de advertencia amarilla en la parte superior de la página.

Mantener la base de datos

Tras eliminar datos, el archivo SQLite no se reduce automáticamente. El mantenimiento semanal ejecuta VACUUM, que reescribe el archivo como una copia compacta; si «Optimizar estadísticas tras el mantenimiento» está activado, también se ejecuta PRAGMA optimize después.

El mantenimiento lo ejecuta solo el programador de línea de comandos cron:run; las solicitudes web nunca ejecutan VACUUM directamente.
Si en las 24 horas previas al mantenimiento no ha habido una copia de seguridad correcta, primero se crea automáticamente una copia programada; si la copia automática falla, se omite esta ejecución de mantenimiento.
Si no se puede obtener el bloqueo de mantenimiento o la base de datos está ocupada, se omite y se registra en el log, y se reintenta en el siguiente ciclo.
Al hacer clic en «Mantener ahora» y confirmar, solo se añade una tarea de mantenimiento a la cola; el programador la ejecuta en segundo plano.
Cada mantenimiento se registra en el registro de auditoría con la acción backup.vacuum.

Durante el mantenimiento se mantiene un bloqueo de escritura de la base de datos, por lo que se recomienda programarlo en horas de baja actividad. Las bases de datos grandes tardan más en mantenerse.

Archivos que debe respaldar por separado

app.key no se incluye en las copias de seguridad. Se utiliza para descifrar los campos de claves de la configuración. Al cambiar de servidor o reinstalar el sistema, respalde por separado data/app.key; de lo contrario, la clave de DeepSeek, la clave privada de pago, las claves de API y otros secretos de la base de datos no se podrán descifrar.

Problemas frecuentes

La última ejecución nunca se actualiza: primero ejecute manualmente php bin/kingcms cron:run en la línea de comandos para ver el error; confirme que la ruta de PHP en crontab es correcta y que el usuario que ejecuta tiene permiso de escritura en data/.
El comando no encuentra PHP: use which php o command -v php para obtener la ruta absoluta y póngala en crontab.
Falla la copia de seguridad: compruebe el espacio en disco y los permisos de data/; el directorio de copias debe ser escribible y creable. Si indica que la extensión sqlite3 no está habilitada, instale la extensión sqlite3 de PHP y reinicie PHP-FPM.
La hora de ejecución no es correcta: la «Hora de ejecución» se calcula según la zona horaria del sitio. Tras modificar la zona horaria del sitio en «Configuración del sistema → Configuración → Básico del sitio → Información básica», se aplicará en la siguiente ejecución.
Falla el empaquetado con medios: el servidor necesita la extensión zip de PHP habilitada. Si el directorio de subidas no existe, solo se empaqueta la base de datos.
Ubicación del log: si redirige la salida a data/cron.log en crontab, consúltelo allí; también puede ver los logs de ejecución en «Tareas programadas» del panel BT; los logs de errores de PHP-FPM o del servidor web registran las excepciones de copia de seguridad.

Documentación relacionada: Configuración del sistema, Instalación, Actualización.