# dfbackup — PrestaShop 8 & 9 Backup: complete guide

> Overview dfbackup is a complete backup module for PrestaShop 8 and 9. It backs up your database and files in pure PHP (no mysqldump, no shell_exec), optionally encrypts archives with…

- Page: <https://www.datafirefly.com/en/documentation/dfbackup/>
- Language: en
- Last updated: 2026-07-02
- Other languages: [fr](https://www.datafirefly.com/documentation/dfbackup/index.md), [es](https://www.datafirefly.com/es/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)
- Index: <https://www.datafirefly.com/en/documentation/llms.txt>

## Overview

dfbackup is a complete backup module for PrestaShop 8 and 9. It backs up your database and files in pure PHP (no mysqldump, no shell_exec), optionally encrypts archives with AES-256, uploads them to multiple destinations (Local, S3, FTP, Dropbox, PrestaShop replication) and offers a 1-click restore with an automatic safety snapshot.

Three tabs are added under the **Advanced Parameters** menu of your back office: **Dashboard** (overview and manual runs), **History** (backup list, restore, verify, delete) and **Settings** (scheduling, storage, encryption, notifications).

## Installation

1. In your back office, go to **Modules > Module Manager > Upload a module**.
2. Select the `dfbackup-1.0.0.zip` file downloaded after purchase.
3. Click **Install**. The module creates four tables (`dfbackup`, `dfbackup_log`, `dfbackup_filemap`, `dfbackup_audit`) and the `var/dfbackup/` storage directory protected by an .htaccess.
4. Open **Advanced Parameters > DF Backup** to access the dashboard.

After every module update, clear the PHP cache (opcache) and Smarty cache: **Advanced Parameters > Performance > Clear cache**. On some hosts a PHP-FPM restart is required to reload the bytecode.

## Running a first backup

From the Dashboard, three buttons offer manual runs:

- **Run backup now** — full backup (DB + files);
- **Database only** — DB dump only, fast (under a minute on most shops);
- **Files only** — files archive only.

The backup runs in the background in its own PHP process: the page does not block, and a progress card streams the logs in real time with an estimated percentage (DB dump, files archiving, encryption, checksum, upload, rotation). You can leave the page — the backup keeps running server-side.

## Scheduling

Under **Settings > Scheduling**, three frequencies are available:

- **Daily** — every day at the target time (e.g. 03:00);
- **Weekly** — a day of the week + time;
- **Monthly** — a day of the month + time.

A 30-minute tolerance window and 60-minute deduplication avoid double triggers. Two execution mechanisms coexist:

### Native PrestaShop cron

The `actionCronJob` hook fires on shop visits. Sufficient for shops with steady traffic, but not guaranteed at night.

### Web-cron (recommended)

A token-signed URL is displayed in Settings, in the format:

```
https://your-shop.com/index.php?fc=module&module=dfbackup&controller=webcron&token=YOUR_TOKEN
```

Configure a free external service like [cron-job.org](https://cron-job.org) or EasyCron to call this URL every hour (or every 15 minutes). The module internally checks whether the target time has been reached and replies instantly with `QUEUED | id=N` when a backup is triggered, or `Not scheduled now.` otherwise. The response is immediate — no timeout risk on the cron service side.

The **Regenerate token** button immediately invalidates the old URL. Remember to update your external cron service after regenerating.

## Storage destinations

Each backup can be uploaded to **multiple destinations simultaneously** — the 3-2-1 rule (three copies, two media, one off-site). Tick the destinations you want under **Settings > Storage**:

### Local

Archives stay in `var/dfbackup/` under the PrestaShop root, protected by an .htaccess Deny. Always active as the working copy.

### Amazon S3 and compatibles

Fill in Access Key, Secret Key, bucket, region. The **Endpoint** field lets you use any S3-compatible service:

- Amazon S3: leave the endpoint empty, set the region (e.g. `eu-west-3`);
- Cloudflare R2: `https://ACCOUNT_ID.r2.cloudflarestorage.com`, region `auto` — 10 GB free, zero egress cost;
- Self-hosted MinIO: `https://minio.your-domain.com`;
- OVH Object Storage, Scaleway, Wasabi, Backblaze B2: endpoint provided by your host.

Multipart upload triggers automatically above 100 MB (10 MB parts) — multi-GB archives transfer without saturating PHP memory.

### FTP / FTPS

Host, port, credentials, remote directory (created automatically if missing), FTPS and passive mode toggles.

### Dropbox

Paste an access token generated from the [Dropbox developer console](https://www.dropbox.com/developers/apps) (`files.content.write` permission). Archives above 150 MB automatically switch to a chunked upload_session.

Every destination has a **Test** button that verifies the connection and write permissions before the first real backup.

## Replication to a staging PrestaShop

Replication pushes every backup to a second PrestaShop installation running dfbackup — ideal for keeping a pre-production environment in sync every night.

### Configuration

1. **On the target shop (staging)**: install dfbackup, then store a shared secret (32+ random characters) under the `DFBACKUP_REPLICATION_SECRET` configuration key (via Settings or Advanced Parameters > Configuration).
2. **On the source shop (prod)**: under **Settings > Storage > PrestaShop replication**, enter the staging URL (e.g. `https://staging.example.com`) and the same secret. Tick **Replication** among the destinations.
3. Click **Test replication target**: the target must answer OK.

### Automatic restore (optional)

To make the staging automatically apply each received archive, enable the `DFBACKUP_REPLICATION_AUTO_RESTORE = 1` key on the **target** and tick the matching option on the source. The next morning, your staging mirrors yesterday's production.

Auto-restore overwrites the staging's DB and files on each reception. Never enable it on a production shop. The target-side flag is deliberately a separate protection from the shared secret.

### Transport security

Archives are transferred in 8 MB chunks, each signed HMAC-SHA-256 (the signature covers the parameters and the body hash). An anti-replay check rejects any request whose timestamp deviates by more than 5 minutes.

## AES-256 encryption

Under **Settings > Encryption**, tick the box and set a passphrase. Archives are then encrypted with AES-256-CBC plus HMAC-SHA-256 (encrypt-then-MAC pattern, PBKDF2 derivation with 120,000 iterations).

- The passphrase is **never stored in plaintext** — only its hash is kept for verification at restore time.
- An encrypted archive whose passphrase is lost is **permanently unrecoverable**. Store the passphrase in a password manager (Bitwarden, 1Password) before enabling the option.
- The SHA-256 checksum is computed on the archive before encryption and verified at restore.

## Restore

From **History**, each backup offers three actions: **Verify** (recomputes the SHA-256), **Restore** and **Delete**.

### How a restore works

1. A **safety DB snapshot** is created automatically before anything else.
2. You choose the scope: everything, DB only, or files only.
3. If the archive is encrypted, the passphrase is requested.
4. The DB is restored statement by statement; files are extracted in batches.
5. The `dfbackup*` tables are **always preserved**: your backup history survives the restore.

### Migration mode (domain change)

Tick **Migration mode** and enter the new domain: the module updates `PS_SHOP_DOMAIN`, `PS_SHOP_DOMAIN_SSL`, the `shop_url` table, and rewrites hardcoded URLs in CMS, product and meta contents. Handy for cloning a shop to pre-prod or moving domains.

After a restore, always clear the cache (Performance > Clear cache) and check the homepage in private browsing.

## Rotation and retention

Two cumulative rules under **Settings > Retention**:

- **Keep N backups** — beyond that, the oldest are deleted;
- **Delete after X days** — regardless of the count.

Only backups with a `completed` or `verified` status are counted and purged; pre-restore and pre-upgrade snapshots follow the same rules.

## Notifications and alerts

- **Email** — sent via `Mail::Send` (your PrestaShop SMTP settings are respected) on success and/or failure, FR/EN/ES/DE templates.
- **Webhook** — paste a Slack, Discord or Microsoft Teams URL: the format is auto-detected. Any other URL receives generic JSON.
- **Back-office alert** — a banner appears at the top of all admin pages if the last backup failed (red) or is more than 7 days old (yellow).
- **Pre-upgrade snapshot** — a DB backup runs automatically before every module update (`actionAdminModulesUpgradeBefore` hook), can be disabled in Settings.

## File exclusions

The module always excludes `var/dfbackup`, `var/cache`, `.git`, `node_modules` and the autoupgrade folder. You can add your own paths and glob patterns (e.g. `img/tmp/*`, `*.log`) under **Settings > Exclusions**. The incremental mode (changed files only, detected by path + size + date fingerprint) drastically reduces the size of intermediate backups.

## Troubleshooting

### A backup stays stuck in "running"

If the process was killed (server restart), the row will be marked as failed on the next run thanks to the `flock` lock. You can also delete it from History.

### "Another backup is already running"

A file lock prevents two simultaneous backups. Wait for the current backup to finish (visible in the Dashboard) or check that an external cron isn't firing at the same time as a manual run.

### The backup fails on a large shop

Increase **Max execution time** and **Memory limit** in Settings (the module applies them to its own process). Enable incremental mode for files and exclude unnecessary large directories (exports, logs).

### Module changes don't seem to apply

It's almost always the PHP opcache serving stale bytecode. Clear the PrestaShop cache _and_ restart PHP-FPM (or wait for the opcache to expire).

### The web-cron URL returns a 404

Use the dispatcher-format URL (`index.php?fc=module&module=dfbackup&controller=webcron`) shown in Settings — some hosts block direct access to PHP files under `/modules/`.

## Uninstall

Uninstalling drops the four tables and deletes all configurations. Archives in `var/dfbackup/` are **not** removed automatically — download your recent backups before uninstalling if you plan to reinstall later.