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 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.

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 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.

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 (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.

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.

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.