DfBackup SW — Complete Guide

DfBackup SW is a production-grade backup system for Shopware 6.5, 6.6 and 6.7 with zero external dependencies: no mysqldump, no shell_exec, no Amazon SDK. It backs up the database and files in pure PHP, encrypts archives with authenticated AES-256, pushes them to Local, S3, FTP or Dropbox, and can even replicate every backup to a second Shopware staging. Restore is one click away, with an automatic safety snapshot. This guide covers installation, background execution, encryption, storage backends, replication, restore, scheduling and troubleshooting.

Installation

1. Download the DfBackup-SW-1.0.0.zip archive from your DataFirefly account.
2. Copy the unzipped DfBackup folder into your Shopware custom/plugins/, or install the ZIP via Administration → Extensions → My extensions → Upload extension.
3. Install and activate:

   bin/console plugin:refresh
   bin/console plugin:install --activate DfBackup
   bin/console cache:clear

4. On installation, the plugin creates its four tables (df_backup, df_backup_log, df_backup_filemap, df_backup_audit) and registers its ScheduledTask.

Where to find the plugin in the administration

After activation, a dedicated DfBackup administration module appears in the menu. It gathers the backup list, the Backup now button, real-time progress, and the per-backup actions (verify, download, protect, restore, delete). Configuration (scheduling, encryption, backends, replication, notifications) is done in the plugin config via Extensions → My extensions → DfBackup → ⋯ → Configure.

Background execution: Messenger, ScheduledTask and web-cron

A backup never blocks the interface. Clicking Backup now pre-allocates a row, dispatches an asynchronous Symfony Messenger message and returns the ID immediately. The actual work runs in the worker, and the administration shows live progress through 15 milestones (start, database dump, archiving, encryption, checksum, per-backend upload, rotation).

Recommended worker in production

For production shops, run a permanently supervised Messenger consumer:

bin/console messenger:consume async --time-limit=300 --memory-limit=512M

Place it under systemd or supervisor so it restarts automatically. This is the setup that lets backups run without any web time limit.

ScheduledTask

A native ScheduledTask runs every 10 minutes and acts as the scheduling gate: it checks whether a scheduled backup is due and, if so, dispatches the message. It relies on the Shopware scheduler, itself driven by the worker or the Shopware cron.

Fallback web-cron

On hostings without CLI access or a permanent worker, enable the web-cron: a token-signed URL (regenerable from the config) that an external service such as cron-job.org calls every 10 to 15 minutes. The internal scheduling gate (30-minute window, 60-minute deduplication) prevents double triggers.

The database dump, built for Shopware

A naive SQL dump breaks on Shopware. DfBackup SW handles the schema’s particularities natively:

• Generated columns (STORED or VIRTUAL) are excluded from the INSERTs, because MySQL refuses writes to them.
• Binary columns — including the BINARY 16 UUID primary keys used everywhere in Shopware — are emitted as 0x… hexadecimal literals for a perfectly faithful re-import.
• Keyset pagination on the integer primary key lets very large tables (order, log_entry) be dumped without exhausting memory.
• Views are recreated last, after all tables.

The dump is chunked (500 rows per batch) and the resulting file re-imports cleanly, statement by statement, with FOREIGN_KEY_CHECKS disabled during import.

The file backup

Files are archived via ZipArchive with configurable glob exclusions (by default var/cache, var/log, node_modules, thumbnails…). The optional incremental mode relies on a sha1 of path + size + mtime tracked in the database: only files changed since the last full backup are re-archived.

AES-256 encryption

Encryption is optional but strongly recommended for off-site archives. DfBackup SW applies an AES-256-CBC plus HMAC-SHA-256 scheme using the encrypt-then-MAC pattern:

• The passphrase goes through PBKDF2-SHA256 with 120,000 iterations to derive separate encryption and HMAC keys.
• Encryption is streamed in 1 MiB blocks: a multi-GB archive encrypts with constant memory footprint.
• On read, the HMAC is verified before any decryption (protection against padding oracle and bit-flip attacks).
• An independent SHA-256 guarantees raw file integrity (verified or corrupted status in the database).

Storage backends

Each backup can be sent to one or several backends simultaneously, to apply the 3-2-1 rule:

• Local: under var/df-backup, with anti-listing protection.
• Amazon S3 and compatibles: native AWS V4 signature (no SDK), automatic multipart upload above 100 MB (10 MB parts). Compatible with MinIO, Wasabi, Cloudflare R2, OVH, Scaleway, Backblaze B2 via endpoint and region override.
• FTP and FTPS: passive mode, automatic remote directory creation.
• Dropbox v2: REST with chunked upload_session for archives above 150 MB.

Replication to a Shopware staging

This is the feature that sets DfBackup SW apart: pushing every backup to a second Shopware installation running the same plugin.

1. Install DfBackup SW on production and on staging.
2. Generate a shared secret (long random string) and enter it on both sides.
3. On production, enable Replication as a destination and provide the staging URL.

On every backup, the archive is uploaded in 8 MB chunks signed with HMAC-SHA-256 to dedicated endpoints on the target (chunk, commit, delete, ping), with timestamp anti-replay at a 5-minute tolerance. If auto-restore is enabled on staging, the archive is applied automatically — your staging mirrors yesterday’s production the next morning.

One-click restore

From the backup list, the Restore button opens a modal:

1. Choose the scope: everything, database only or files only.
2. To confirm, type the word RESTORE — a guard against accidental clicks.
3. Optionally, enable domain migration mode and enter the new domain.

Before any restore, a protected database snapshot is created automatically: if the restore fails halfway, you return to the initial state in minutes. The plugin’s tables (df_backup*) are never overwritten — your backup history is preserved even when restoring a six-month-old version.

Domain migration

In migration mode, the plugin rewrites the sales_channel_domain entries and applies a best-effort replacement on the text columns of the translation tables (CMS, products, categories) as well as on seo_url, so the clone is immediately browsable on its own domain.

Scheduling, rotation and maintenance mode

• Frequencies: daily (target hour), weekly (day + hour), monthly (day of month + hour). 30-minute tolerance window and 60-minute deduplication.
• Rotation: by number of backups to keep and by age in days. Backups marked protected (notably pre-restore snapshots) are never rotated.
• Optional maintenance mode: switches the sales channels to maintenance during the database dump for perfect transactional consistency, useful on shops with very high order volume.

Notifications and audit

• Email via Symfony Mailer (success, failure, or both as you choose).
• Webhook with format auto-detection: Slack, Discord, Microsoft Teams or generic JSON.
• Alert in the module when no successful backup for N days.
• Audit log: every sensitive action (run, restore, deletion, verification, download) is traced with admin user, IP and timestamp.

FAQ and troubleshooting

Does the plugin work without shell_exec? Yes. No calls to shell_exec, exec, passthru or mysqldump. Everything is pure PHP (DBAL, ZipArchive, cURL, native ftp functions).

My backups don’t run automatically. Check that a Messenger worker is running (or that the web-cron is called regularly) and that the DfBackup ScheduledTask is active in Shopware. Without a worker or web-cron, scheduling cannot run.

The dump fails on a large table. Keyset pagination normally handles large tables; make sure the integer primary key is present and increase the worker memory if needed (--memory-limit).

An archive comes out as corrupted. The SHA-256 doesn’t match: the upload or write was truncated. Re-run the backup and check disk space and remote backend quotas.

How do I verify a backup without restoring it? The Verify button recomputes the SHA-256 and, for encrypted archives, checks the HMAC — without restoring anything.

What happens on uninstall? With the data-removal option, the four df_backup* tables are dropped and the configuration erased. Files under var/df-backup are not deleted automatically: download your recent backups before uninstalling.