DfBackup SW — Guida completa

DfBackup SW è un sistema di backup di livello produzione per Shopware 6.5, 6.6 e 6.7 senza dipendenze esterne: niente mysqldump, niente shell_exec, niente SDK Amazon. Esegue il backup del database e dei file in PHP puro, cifra gli archivi con AES-256 autenticato, li invia a Local, S3, FTP o Dropbox e può perfino replicare ogni backup verso un secondo Shopware staging. Il ripristino è a un clic, con uno snapshot di sicurezza automatico. Questa guida copre l’installazione, l’esecuzione in background, la crittografia, i backend di archiviazione, la replica, il ripristino, la pianificazione e la risoluzione dei problemi.

Installazione

1. Scarica l’archivio DfBackup-SW-1.0.0.zip dal tuo account DataFirefly.
2. Copia la cartella decompressa DfBackup in custom/plugins/ del tuo Shopware, oppure installa lo ZIP via Amministrazione → Estensioni → Le mie estensioni → Carica estensione.
3. Installa e attiva:

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

4. All’installazione, il plugin crea le sue quattro tabelle (df_backup, df_backup_log, df_backup_filemap, df_backup_audit) e registra la sua ScheduledTask.

Dove trovare il plugin nell’amministrazione

Dopo l’attivazione, nel menu compare un modulo di amministrazione dedicato DfBackup. Raccoglie l’elenco dei backup, il pulsante Backup ora, l’avanzamento in tempo reale e le azioni per backup (verifica, download, protezione, ripristino, eliminazione). La configurazione (pianificazione, crittografia, backend, replica, notifiche) si fa nella configurazione del plugin via Estensioni → Le mie estensioni → DfBackup → ⋯ → Configura.

Esecuzione in background: Messenger, ScheduledTask e web-cron

Un backup non blocca mai l’interfaccia. Il clic su Backup ora pre-alloca una riga, invia un messaggio asincrono Symfony Messenger e restituisce subito l’ID. Il lavoro vero gira nel worker, e l’amministrazione mostra l’avanzamento in tempo reale attraverso 15 milestone (avvio, dump del database, archiviazione, crittografia, checksum, upload per backend, rotazione).

Worker consigliato in produzione

Per i negozi in produzione, esegui un consumer Messenger supervisionato in modo permanente:

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

Mettilo sotto systemd o supervisor affinché si riavvii automaticamente. È la configurazione che permette di eseguire i backup senza alcun limite di tempo web.

ScheduledTask

Una ScheduledTask nativa viene eseguita ogni 10 minuti e funge da porta di pianificazione: controlla se deve partire un backup pianificato e, in tal caso, invia il messaggio. Dipende dallo scheduler di Shopware, a sua volta azionato dal worker o dal cron di Shopware.

Web-cron di riserva

Sugli hosting senza accesso CLI né worker permanente, attiva il web-cron: un URL firmato con token (rigenerabile dalla configurazione) che un servizio esterno come cron-job.org chiama ogni 10-15 minuti. La porta di pianificazione interna (finestra di 30 minuti, deduplicazione di 60 minuti) evita i doppi avvii.

Il dump del database, pensato per Shopware

Un dump SQL ingenuo si rompe su Shopware. DfBackup SW gestisce nativamente le particolarità dello schema:

• Le colonne generate (STORED o VIRTUAL) sono escluse dagli INSERT, perché MySQL rifiuta le scritture su di esse.
• Le colonne binarie — incluse le chiavi primarie UUID in BINARY 16, onnipresenti in Shopware — vengono emesse come letterali esadecimali 0x… per una reimportazione perfettamente fedele.
• La paginazione keyset sulla chiave primaria intera permette di dumpare tabelle molto grandi (order, log_entry) senza esaurire la memoria.
• Le viste vengono ricreate alla fine, dopo tutte le tabelle.

Il dump è fatto a blocchi (500 righe per lotto) e il file prodotto si reimporta in modo pulito, istruzione per istruzione, con FOREIGN_KEY_CHECKS disattivato durante l’importazione.

Il backup dei file

I file vengono archiviati via ZipArchive con esclusioni glob configurabili (per default var/cache, var/log, node_modules, miniature…). La modalità incrementale opzionale si basa su uno sha1 di path + size + mtime tracciato in database: solo i file modificati dall’ultimo backup completo vengono ri-archiviati.

Crittografia AES-256

La crittografia è opzionale ma fortemente consigliata per gli archivi conservati fuori sede. DfBackup SW applica uno schema AES-256-CBC più HMAC-SHA-256 secondo il pattern encrypt-then-MAC:

• La passphrase passa per PBKDF2-SHA256 con 120.000 iterazioni per derivare chiavi di crittografia e HMAC separate.
• La crittografia avviene in streaming a blocchi di 1 MiB: un archivio di diversi GB si cifra con un’impronta di memoria costante.
• In lettura, l’HMAC viene verificato prima di qualsiasi decrittazione (protezione contro attacchi padding oracle e bit-flip).
• Uno SHA-256 indipendente garantisce l’integrità del file grezzo (stato verified o corrupted in database).

Backend di archiviazione

Ogni backup può essere inviato a uno o più backend simultaneamente, per applicare la regola 3-2-1:

• Local: sotto var/df-backup, con protezione anti-listing.
• Amazon S3 e compatibili: firma AWS V4 nativa (senza SDK), multipart automatico oltre i 100 MB (parti da 10 MB). Compatibile con MinIO, Wasabi, Cloudflare R2, OVH, Scaleway, Backblaze B2 tramite override di endpoint e regione.
• FTP e FTPS: modalità passiva, creazione automatica della directory remota.
• Dropbox v2: REST con upload_session a chunk per archivi oltre i 150 MB.

Replica verso uno Shopware staging

È la funzione che distingue DfBackup SW: inviare ogni backup verso una seconda installazione Shopware con lo stesso plugin.

1. Installa DfBackup SW sulla produzione e sullo staging.
2. Genera un segreto comune (lunga stringa casuale) e indicalo da entrambe le parti.
3. Sulla produzione, attiva Replica come destinazione e indica l’URL dello staging.

A ogni backup, l’archivio viene caricato in chunk da 8 MB firmati con HMAC-SHA-256 verso endpoint dedicati sulla destinazione (chunk, commit, delete, ping), con anti-replay per timestamp e tolleranza di 5 minuti. Se l’auto-restore è attivo sullo staging, l’archivio viene applicato automaticamente — il tuo staging riflette la produzione del giorno prima già la mattina dopo.

Ripristino 1-clic

Dall’elenco dei backup, il pulsante Ripristina apre una modale:

1. Scegli l’ambito: tutto, solo database o solo file.
2. Per confermare, digita la parola RESTORE — protezione contro le manovre accidentali.
3. Facoltativamente, attiva la modalità migrazione di dominio e indica il nuovo dominio.

Prima di ogni ripristino, viene creato automaticamente uno snapshot protetto del database: se il ripristino fallisce a metà, torni allo stato iniziale in pochi minuti. Le tabelle del plugin (df_backup*) non vengono mai sovrascritte — il tuo storico dei backup è preservato anche ripristinando una versione di sei mesi fa.

Migrazione di dominio

In modalità migrazione, il plugin riscrive i sales_channel_domain e applica una sostituzione best-effort sulle colonne di testo delle tabelle di traduzione (CMS, prodotti, categorie) e su seo_url, affinché il clone sia immediatamente navigabile sul proprio dominio.

Pianificazione, rotazione e modalità manutenzione

• Frequenze: daily (ora obiettivo), weekly (giorno + ora), monthly (giorno del mese + ora). Finestra di tolleranza di 30 minuti e deduplicazione di 60 minuti.
• Rotazione: per numero di backup da conservare e per età in giorni. I backup contrassegnati come protetti (in particolare gli snapshot pre-ripristino) non vengono mai ruotati.
• Modalità manutenzione opzionale: mette i sales channels in manutenzione durante il dump del database per una coerenza transazionale perfetta, utile sui negozi con un volume di ordini molto alto.

Notifiche e audit

• Email via Symfony Mailer (successo, fallimento, o entrambi a scelta).
• Webhook con autorilevamento del formato: Slack, Discord, Microsoft Teams o JSON generico.
• Avviso nel modulo se non c’è alcun backup riuscito da N giorni.
• Registro di audit: ogni azione sensibile (avvio, ripristino, eliminazione, verifica, download) è tracciata con utente admin, IP e timestamp.

FAQ e risoluzione dei problemi

Il plugin funziona senza shell_exec? Sì. Nessuna chiamata a shell_exec, exec, passthru né mysqldump. Tutto è PHP puro (DBAL, ZipArchive, cURL, funzioni ftp native).

I miei backup non partono automaticamente. Verifica che un worker Messenger sia in esecuzione (o che il web-cron sia chiamato regolarmente) e che la ScheduledTask DfBackup sia attiva in Shopware. Senza worker né web-cron, la pianificazione non può essere eseguita.

Il dump fallisce su una tabella grande. La paginazione keyset gestisce normalmente le tabelle grandi; assicurati che la chiave primaria intera sia presente e aumenta la memoria del worker se necessario (--memory-limit).

Un archivio risulta in stato corrupted. Lo SHA-256 non corrisponde: l’upload o la scrittura è stata troncata. Rilancia il backup e verifica lo spazio su disco e le quote del backend remoto.

Come verificare un backup senza ripristinarlo? Il pulsante Verifica ricalcola lo SHA-256 e, per gli archivi cifrati, controlla l’HMAC — senza ripristinare nulla.

Cosa succede alla disinstallazione? Con l’opzione di rimozione dei dati, le quattro tabelle df_backup* vengono eliminate e la configurazione cancellata. I file sotto var/df-backup non vengono eliminati automaticamente: scarica i tuoi backup recenti prima di disinstallare.