# dfbackup — Copia de seguridad PrestaShop 8 & 9: guía completa

> Presentación dfbackup es un módulo de copia de seguridad completo para PrestaShop 8 y 9. Respalda su base de datos y sus archivos en PHP puro (sin mysqldump ni shell_exec),…

- Página: <https://www.datafirefly.com/es/documentation/dfbackup/>
- Idioma: es
- Actualizado el: 2026-07-02
- Otros idiomas: [fr](https://www.datafirefly.com/documentation/dfbackup/index.md), [en](https://www.datafirefly.com/en/documentation/dfbackup/index.md), [de](https://www.datafirefly.com/de/documentation/dfbackup/index.md), [it](https://www.datafirefly.com/it/documentation/dfbackup/index.md), [pl](https://www.datafirefly.com/pl/documentation/dfbackup/index.md), [nl](https://www.datafirefly.com/nl/documentation/dfbackup/index.md), [pt](https://www.datafirefly.com/pt/documentation/dfbackup/index.md)
- Índice: <https://www.datafirefly.com/es/documentation/llms.txt>

## Presentación

dfbackup es un módulo de copia de seguridad completo para PrestaShop 8 y 9. Respalda su base de datos y sus archivos en PHP puro (sin mysqldump ni shell_exec), cifra opcionalmente los archivos en AES-256, los sube a varios destinos (Local, S3, FTP, Dropbox, replicación PrestaShop) y ofrece una restauración en un clic con snapshot de seguridad automático.

Se añaden tres pestañas en el menú **Parámetros avanzados** de su back-office: **Dashboard** (vista general y lanzamientos manuales), **Historial** (lista de backups, restauración, verificación, eliminación) y **Ajustes** (programación, almacenamiento, cifrado, notificaciones).

## Instalación

1. En su back-office, vaya a **Módulos > Gestor de módulos > Subir un módulo**.
2. Seleccione el archivo `dfbackup-1.0.0.zip` descargado tras su compra.
3. Haga clic en **Instalar**. El módulo crea cuatro tablas (`dfbackup`, `dfbackup_log`, `dfbackup_filemap`, `dfbackup_audit`) y el directorio de almacenamiento `var/dfbackup/` protegido por un .htaccess.
4. Abra **Parámetros avanzados > DF Backup** para acceder al dashboard.

Después de cada actualización del módulo, vacíe la caché PHP (opcache) y la caché Smarty: **Parámetros avanzados > Rendimiento > Vaciar caché**. En algunos hostings es necesario reiniciar PHP-FPM para recargar el bytecode.

## Lanzar un primer backup

Desde el Dashboard, tres botones permiten un lanzamiento manual:

- **Run backup now** — backup completo (BDD + archivos);
- **Database only** — solo volcado de BDD, rápido (menos de un minuto en la mayoría de tiendas);
- **Files only** — solo archivo de ficheros.

El backup se ejecuta en segundo plano en su propio proceso PHP: la página no se bloquea y una tarjeta de progreso muestra los logs en tiempo real con un porcentaje estimado (volcado BDD, archivado, cifrado, checksum, upload, rotación). Puede salir de la página — el backup continúa del lado servidor.

## Programación

En **Ajustes > Programación**, se proponen tres frecuencias:

- **Daily** — cada día a la hora objetivo (ej. 03:00);
- **Weekly** — un día de la semana + hora;
- **Monthly** — un día del mes + hora.

Una ventana de tolerancia de 30 minutos y una deduplicación de 60 minutos evitan los disparos dobles. Coexisten dos mecanismos de ejecución:

### Cron nativo de PrestaShop

El hook `actionCronJob` se ejecuta con las visitas a la tienda. Suficiente para tiendas con tráfico regular, pero no garantizado de noche.

### Web-cron (recomendado)

Una URL firmada por token se muestra en los Ajustes, con el formato:

```
https://su-tienda.com/index.php?fc=module&module=dfbackup&controller=webcron&token=SU_TOKEN
```

Configure un servicio externo gratuito como [cron-job.org](https://cron-job.org) o EasyCron para llamar esta URL cada hora (o cada 15 minutos). El módulo verifica internamente si la hora objetivo se ha alcanzado y responde inmediatamente `QUEUED | id=N` cuando se dispara un backup, o `Not scheduled now.` en caso contrario. La respuesta es instantánea — sin riesgo de timeout del lado del servicio de cron.

El botón **Regenerar token** invalida inmediatamente la URL antigua. Recuerde actualizar su servicio de cron externo tras la regeneración.

## Destinos de almacenamiento

Cada backup puede subirse a **varios destinos simultáneamente** — la regla 3-2-1 (tres copias, dos soportes, una fuera del sitio). Marque los destinos deseados en **Ajustes > Almacenamiento**:

### Local

Los archivos permanecen en `var/dfbackup/` bajo la raíz de PrestaShop, protegidos por un .htaccess Deny. Siempre activo como copia de trabajo.

### Amazon S3 y compatibles

Rellene Access Key, Secret Key, bucket, región. El campo **Endpoint** permite usar cualquier servicio compatible S3:

- Amazon S3: dejar el endpoint vacío, indicar la región (ej. `eu-west-3`);
- Cloudflare R2: `https://ACCOUNT_ID.r2.cloudflarestorage.com`, región `auto` — 10 GB gratis, cero coste de salida;
- MinIO auto-hospedado: `https://minio.su-dominio.com`;
- OVH Object Storage, Scaleway, Wasabi, Backblaze B2: endpoint proporcionado por su proveedor.

El multipart upload se activa automáticamente por encima de 100 MB (partes de 10 MB) — los archivos de varios GB se transfieren sin saturar la memoria PHP.

### FTP / FTPS

Host, puerto, credenciales, directorio remoto (creado automáticamente si no existe), FTPS y modo pasivo activables.

### Dropbox

Pegue un access token generado desde la [consola de desarrollador de Dropbox](https://www.dropbox.com/developers/apps) (permiso `files.content.write`). Los archivos por encima de 150 MB pasan automáticamente a upload_session por chunks.

Cada destino dispone de un botón **Test** que verifica la conexión y los permisos de escritura antes del primer backup real.

## Replicación hacia un PrestaShop staging

La replicación empuja cada backup hacia una segunda instalación PrestaShop equipada con dfbackup — ideal para mantener un entorno de pre-producción sincronizado cada noche.

### Configuración

1. **En la tienda destino (staging)**: instale dfbackup, luego registre un secreto compartido (32+ caracteres aleatorios) bajo la clave de configuración `DFBACKUP_REPLICATION_SECRET` (vía Ajustes o Parámetros avanzados > Configuración).
2. **En la tienda origen (producción)**: en **Ajustes > Almacenamiento > Replicación PrestaShop**, indique la URL del staging (ej. `https://staging.example.com`) y el mismo secreto. Marque **Replicación** entre los destinos.
3. Haga clic en **Test replication target**: el destino debe responder OK.

### Restauración automática (opcional)

Para que el staging aplique automáticamente cada archivo recibido, active en el **destino** la clave `DFBACKUP_REPLICATION_AUTO_RESTORE = 1` y marque la opción correspondiente del lado origen. A la mañana siguiente, su staging refleja la producción del día anterior.

El auto-restore sobrescribe la BDD y los archivos del staging en cada recepción. Nunca lo active en una tienda de producción. El flag del lado destino es una protección deliberadamente separada del secreto compartido.

### Seguridad del transporte

Los archivos se transfieren por chunks de 8 MB, cada uno firmado HMAC-SHA-256 (la firma cubre los parámetros y el hash del cuerpo). Un control anti-replay rechaza cualquier petición cuyo timestamp se desvíe más de 5 minutos.

## Cifrado AES-256

En **Ajustes > Cifrado**, active la casilla y defina una passphrase. Los archivos se cifran entonces en AES-256-CBC con HMAC-SHA-256 (patrón encrypt-then-MAC, derivación PBKDF2 con 120 000 iteraciones).

- La passphrase **nunca se almacena en texto plano** — solo su hash sirve para la verificación en la restauración.
- Un archivo cifrado cuya passphrase se pierde es **definitivamente irrecuperable**. Guarde la passphrase en un gestor de contraseñas (Bitwarden, 1Password) antes de activar la opción.
- El checksum SHA-256 se calcula sobre el archivo antes del cifrado y se verifica en la restauración.

## Restauración

Desde **Historial**, cada backup propone tres acciones: **Verificar** (recalcula el SHA-256), **Restaurar** y **Eliminar**.

### Desarrollo de una restauración

1. Un **snapshot de BDD de seguridad** se crea automáticamente antes de cualquier operación.
2. Usted elige el alcance: todo, solo BDD, o solo archivos.
3. Si el archivo está cifrado, se pide la passphrase.
4. La BDD se restaura instrucción por instrucción; los archivos se extraen por lotes.
5. Las tablas `dfbackup*` se **preservan siempre**: su historial de backups sobrevive a la restauración.

### Modo migración (cambio de dominio)

Marque **Modo migración** e indique el nuevo dominio: el módulo actualiza `PS_SHOP_DOMAIN`, `PS_SHOP_DOMAIN_SSL`, la tabla `shop_url` y reescribe las URLs hardcoded en los contenidos CMS, productos y meta. Práctico para clonar una tienda a pre-producción o mudarse de dominio.

Tras una restauración, vacíe siempre la caché (Rendimiento > Vaciar caché) y verifique la página de inicio en navegación privada.

## Rotación y retención

Dos reglas acumulativas en **Ajustes > Retención**:

- **Conservar N backups** — más allá, se eliminan los más antiguos;
- **Eliminar tras X días** — independientemente del número.

Solo los backups con estado `completed` o `verified` se cuentan y purgan; los snapshots pre-restauración y pre-upgrade siguen las mismas reglas.

## Notificaciones y alertas

- **Email** — envío vía `Mail::Send` (se respetan sus ajustes SMTP de PrestaShop) en caso de éxito y/o fallo, plantillas FR/EN/ES/DE.
- **Webhook** — pegue una URL de Slack, Discord o Microsoft Teams: el formato se auto-detecta. Cualquier otra URL recibe un JSON genérico.
- **Alerta back-office** — un banner aparece en la cabecera de todas las páginas admin si el último backup falló (rojo) o data de más de 7 días (amarillo).
- **Snapshot pre-upgrade** — un backup de BDD se lanza automáticamente antes de cada actualización de módulo (hook `actionAdminModulesUpgradeBefore`), desactivable en los Ajustes.

## Exclusiones de archivos

El módulo excluye de oficio `var/dfbackup`, `var/cache`, `.git`, `node_modules` y la carpeta autoupgrade. Puede añadir sus propias rutas y patrones glob (ej. `img/tmp/*`, `*.log`) en **Ajustes > Exclusiones**. El modo incremental (solo archivos modificados, detección por huella ruta + tamaño + fecha) reduce fuertemente el tamaño de los backups intermedios.

## Solución de problemas

### Un backup queda bloqueado en "running"

Si el proceso fue interrumpido (reinicio del servidor), la fila se marcará como fallida en el próximo lanzamiento gracias al bloqueo `flock`. También puede eliminarla desde el Historial.

### "Another backup is already running"

Un bloqueo de archivo impide dos backups simultáneos. Espere a que termine el backup en curso (visible en el Dashboard) o verifique que un cron externo no se dispare al mismo tiempo que un lanzamiento manual.

### El backup falla en una tienda grande

Aumente **Max execution time** y **Memory limit** en los Ajustes (el módulo los aplica a su propio proceso). Active el modo incremental para los archivos y excluya los directorios voluminosos innecesarios (exports, logs).

### Los cambios del módulo no parecen aplicarse

Casi siempre es el opcache PHP sirviendo bytecode antiguo. Vacíe la caché de PrestaShop _y_ reinicie PHP-FPM (o espere la expiración del opcache).

### La URL de web-cron devuelve un 404

Use la URL en formato dispatcher (`index.php?fc=module&module=dfbackup&controller=webcron`) mostrada en los Ajustes — algunos hostings bloquean el acceso directo a los archivos PHP bajo `/modules/`.

## Desinstalación

La desinstalación elimina las cuatro tablas y todas las configuraciones. Los archivos presentes en `var/dfbackup/` **no** se eliminan automáticamente — descargue sus backups recientes antes de desinstalar si prevé reinstalar más tarde.