Copias de seguridad y restauración
Un sitio sin respaldos es un sitio a punto de perderse. Este capítulo te enseña qué respaldar, con qué frecuencia y cómo restaurar cuando algo pasa.
Qué respaldar
Tu instalación tiene tres cosas críticas que deben respaldarse juntas:
- La base de datos — todos tus datos (usuarios, registros, configuraciones).
- Los archivos subidos — imágenes, PDFs, adjuntos (viven en
cms/views/assets/files/, la biblioteca del panel, y enuploads/, donde los módulos guardan contratos firmados, documentos y adjuntos). - Los archivos
config.php— credenciales y ajustes.
Si respaldas solo la base de datos y pierdes los archivos, tus imágenes se rompen. Si respaldas solo los archivos, pierdes todos los registros.
Cómo respaldar
Método 1: Empaquetado del framework (recomendado)
Ver Empaquetar y desplegar. Genera un ZIP con los tres componentes juntos.
- Ventaja: es un solo archivo, portátil.
- Desventaja: para instalaciones grandes puede tardar minutos.
Método 2: Manual
Si tienes acceso al servidor:
# Base de datos
mysqldump -u usuario -p nombre_bd > backup_$(date +%Y%m%d).sql
# Archivos
tar -czf files_$(date +%Y%m%d).tar.gz cms/views/assets/files/ web/uploads/
# Configs
cp api/config.php config_api_$(date +%Y%m%d).php
cp cms/config.php config_cms_$(date +%Y%m%d).php
- Ventaja: rápido, scriptable.
- Desventaja: requiere conocimiento técnico y estar seguro de que respaldas todo.
Método 3: Panel del hosting
Muchos hostings (cPanel, Plesk, Cloudways) tienen sistema de respaldos automáticos. Actívalo — es la línea de defensa más simple.
Con qué frecuencia
Depende de cuánto cambian tus datos:
- Diario: sitios con actividad (ecommerce, sistemas de gestión con muchos cambios).
- Semanal: sitios más estáticos.
- Manual antes de cambios grandes: siempre antes de actualizar, migrar, importar masivamente, o cualquier cosa que pueda salir mal.
Cuántos guardar (retención)
Recomendación mínima:
- Los últimos 7 respaldos diarios.
- Los últimos 4 semanales (uno por semana del mes pasado).
- Los últimos 12 mensuales (uno por mes del año pasado).
Con eso puedes volver hasta un año atrás si es necesario.
Para aplicar esa regla sin perder la tarde, la lista de Configuración → Empaquetado permite marcar varios paquetes y borrarlos (o descargarlos) de una sola vez: Descargar o borrar varios paquetes.
Dónde guardarlos
Fuera del servidor. Si el servidor se rompe (fallo de disco, ataque, incendio), los respaldos que estén ahí se pierden también.
Opciones comunes:
- Amazon S3 / Google Cloud Storage / Backblaze B2 — barato, escalable, con reglas de retención automáticas.
- Google Drive / Dropbox — simple, buena para instalaciones pequeñas.
- Un servidor propio en otro proveedor — control total, más trabajo.
Nunca solo el mismo servidor.
Automatizar respaldos
Para que no dependas de acordarte.
Lo que trae el sistema (recomendado)
En Automatizaciones → Nueva tarea elige «Respaldar el sistema completo». Cada noche genera el mismo paquete que harías a mano —base de datos, archivos subidos y sitio— y borra los antiguos para no llenar el disco: guarda los 7 últimos.
Hay una segunda tarea, «Borrar los registros antiguos del sistema», que limpia los archivos de registro de más de 30 días. Un disco lleno no se presenta como un disco lleno: se presenta como que todo dejó de guardar.
Una copia guardada junto a los datos que protege te salva de una
equivocación —un borrado, una actualización que salió mal—, pero no de
perder el servidor. Baja el paquete cada cierto tiempo, o copia la carpeta
packages/ a otro lado.
Una tarea programada solo corre si algo llama al sistema cada pocos minutos. La sección Automatizaciones explica las dos maneras y te entrega la dirección lista para copiar. Sin eso, la tarea queda programada y no se ejecuta nunca.
Con el hosting
Si el hosting lo ofrece, actívalo también. Dos respaldos por caminos distintos es mejor que uno, y el del hosting suele quedar fuera de tu servidor.
Con servicios externos
Herramientas como UpdraftPlus (para WordPress, pero adaptable), o servicios pagos como BackupBuddy hacen esto — no vienen incluidos en el framework, pero un buen técnico puede configurarlos.
Restaurar desde un respaldo
Con el sistema de empaquetado
- Ve a Configuración → Empaquetado → Importar paquete.
- Sube el ZIP del respaldo.
- El sistema restaura archivos + base de datos.
Manualmente
# Base de datos
mysql -u usuario -p nombre_bd < backup_20260729.sql
# Archivos
tar -xzf files_20260729.tar.gz -C /
# Configs
cp config_api_20260729.php api/config.php
cp config_cms_20260729.php cms/config.php
Después ejecuta sudo ./setup.sh para reajustar permisos.
Probar los respaldos
Un respaldo no probado no es un respaldo.
Al menos una vez por trimestre:
- Levanta un servidor de pruebas (puede ser local).
- Restaura un respaldo reciente.
- Verifica que todo funciona: login, ver datos, editar registros.
Si nunca lo pruebas, el día que lo necesites descubrirás si servía.
Errores comunes
- Respaldar solo la base de datos. Las imágenes también.
- Respaldos en el mismo servidor. Se pierden juntos.
- Sin rotación. Un respaldo de hace 2 años no sirve. Pero sí ocupa espacio.
- Nunca probarlos. La primera vez es al restaurar la producción rota, sin margen de error.
¿Qué sigue?
- Actualizar a nuevas versiones — siempre respalda antes de actualizar.
- Empaquetar y desplegar — el mecanismo que también sirve para respaldar.