# Backup WordPress: Strategia, Retention e Ripristino | KLC Tipo: articolo informativo Sito: KLC (www.klc.it) URL canonico: https://www.klc.it/blog/siti-web/backup-wordpress-strategia-retention-e-ripristino/ Autore: KLC Pubblicato: 31 Luglio 2026 Ultimo aggiornamento: 2 Agosto 2026 Lingua: it-IT Categoria: Siti web ## Sintesi Un backup non è una spunta verde nel pannello. È utile soltanto se contiene i dati necessari, è disponibile quando serve e può essere ripristinato entro un tempo compatibile con il rischio. ## Punti chiave - l’ambito è documentato; - frequenza e retention derivano da RPO e rischio; - almeno una copia è separata dall’infrastruttura primaria; - errori e mancati backup generano avvisi; - accessi e cifratura sono controllati; - esiste un runbook; - un ripristino completo è stato provato; - tempi e lacune emersi dal test sono stati corretti; - owner e data della prossima prova sono definiti. ## Backup WordPress: come progettare copie realmente ripristinabili Scritto da KLC il 31 Luglio 2026. Pubblicato in Siti web. 31 Luglio 2026 · Siti web Un backup non è riuscito perché il pannello mostra una spunta verde. È riuscito quando permette di riportare il sito a uno stato coerente entro tempi compatibili con il business. File incompleti, database non sincronizzato, credenziali mancanti o copie conservate sullo stesso server possono rendere inutile un sistema apparentemente attivo. Progettare backup WordPress significa decidere che cosa salvare, quanto si può perdere, dove conservare le copie e come provarne il ripristino. ## Capire che cosa compone realmente il sito WordPress separa contenuti e configurazioni tra database e file. Un set di backup completo può includere: - database WordPress; - core, anche se reinstallabile; - wp-content con temi, plugin e upload; - file di configurazione; - regole server come .htaccess o configurazioni Nginx; - mu-plugin e codice personalizzato; - media conservati su storage esterno; - configurazione CDN e DNS; - certificati o segreti, con protezione adeguata; - cron e processi esterni; - integrazioni, webhook e impostazioni non presenti nel database; - documentazione di versioni e dipendenze. La documentazione ufficiale WordPress ricorda che database e file sono componenti distinti. Salvare soltanto gli upload non conserva articoli, utenti e impostazioni; salvare soltanto il database non recupera media, plugin e codice. ## Definire RPO e RTO in termini comprensibili Due concetti aiutano a scegliere la strategia. - RPO, Recovery Point Objective : quanta informazione l’azienda può accettare di perdere. Se l’ultimo backup è di 24 ore fa, ordini e modifiche successive possono andare persi. - RTO, Recovery Time Objective : entro quanto tempo il servizio deve tornare disponibile. Non sono valori tecnici astratti. Devono derivare dal sito. | Sito | Possibile esigenza | Implicazione | | --- | --- | --- | | sito istituzionale aggiornato raramente | perdita tollerabile di alcune ore o un giorno | backup giornaliero e copia prima dei rilasci | | blog con pubblicazione frequente | contenuti e commenti da proteggere | frequenza maggiore durante l’attività | | e-commerce | ordini, account e stock cambiano continuamente | backup frequenti o incrementali e procedure sugli ordini | | area riservata | documenti e attività degli utenti | RPO e controlli di accesso più rigorosi | | sito di lead generation | invii possono vivere in sistemi esterni | verificare database, email e CRM | “Backup giornaliero” non è sempre sufficiente e “backup ogni cinque minuti” non è sempre necessario. ## Usare più livelli di copia Una strategia robusta evita un unico punto di fallimento. Può combinare: - snapshot dell’hosting per recuperi rapidi; - backup applicativi o infrastrutturali indipendenti; - copia offsite su un provider separato; - versioni con retention differente; - backup manuale prima di aggiornamenti e migrazioni; - repository del codice personalizzato. La regola 3-2-1 — più copie, su supporti o sistemi differenti, con almeno una offsite — è un riferimento utile, ma va adattata. Se pannello, credenziali e storage dipendono dallo stesso account compromesso, le copie non sono davvero indipendenti. ## Progettare la retention contro gli errori scoperti tardi Conservare soltanto l’ultima copia protegge poco da corruzioni, malware o errori rimasti invisibili per settimane. Una retention può prevedere: - copie frequenti per pochi giorni; - giornaliere per alcune settimane; - settimanali o mensili per periodi più lunghi; - copie speciali prima di release importanti; - conservazione estesa per obblighi o progetti specifici. La durata deve considerare spazio, rischio, dati personali e politiche di cancellazione. Conservare tutto per sempre non è automaticamente corretto. ## Garantire coerenza tra file e database Su siti dinamici, file e database cambiano durante il backup. Una copia effettuata mentre arrivano ordini o vengono caricati media può produrre uno stato incoerente. Il sistema deve chiarire: - se usa snapshot consistenti; - se mette temporaneamente il sito in manutenzione; - come gestisce tabelle molto grandi; - se database e file appartengono allo stesso punto temporale; - come tratta upload su storage esterno; - come verifica l’integrità dell’archivio. Per e-commerce e aree transazionali, il ripristino deve anche gestire ciò che è avvenuto dopo il punto scelto: ordini, pagamenti, email, stock e sistemi esterni non possono essere ignorati. ## Cifrare, limitare e monitorare gli accessi Le copie possono contenere dati personali, credenziali e configurazioni sensibili. Devono essere protette almeno quanto il sito di produzione. Controlli utili: - cifratura durante trasferimento e conservazione; - account dedicati e autenticazione forte; - permessi minimi; - separazione dagli accessi ordinari WordPress; - log di creazione, download e cancellazione; - avvisi in caso di backup fallito; - protezione dalla cancellazione immediata o malevola; - rotazione delle credenziali; - policy di conservazione e distruzione. Un link pubblico a un archivio .zip annulla buona parte della sicurezza del sito. ## Testare il ripristino in un ambiente isolato La prova non dovrebbe sovrascrivere la produzione. Si ripristina una copia in un ambiente separato e si verifica: 1. possibilità di scaricare e decifrare gli archivi; 2. integrità di file e database; 3. compatibilità di versioni PHP, database e server; 4. accesso amministrativo; 5. visualizzazione di pagine, media e contenuti; 6. funzionamento di plugin e codice personalizzato; 7. moduli, email, login e permessi; 8. ordini o funzioni critiche; 9. configurazioni di URL e ricerca-sostituzione; 10. assenza di comunicazioni reali dall’ambiente di prova; 11. tempo impiegato e passaggi manuali. Il test deve produrre un verbale con esito, problemi, tempi e azioni correttive. “Il database è stato importato” non significa che il sito sia ripristinato. ## Preparare un runbook leggibile anche durante un incidente La procedura deve indicare: - chi dichiara l’incidente; - chi sceglie il punto di ripristino; - dove si trovano copie e credenziali; - come mettere in sicurezza l’infrastruttura compromessa; - ordine di ripristino; - controlli prima della riapertura; - gestione di DNS, cache e CDN; - riconciliazione dei dati successivi al backup; - comunicazioni interne ed esterne; - criteri per chiudere l’incidente. Le credenziali non vanno inserite in chiaro nel runbook, ma deve essere chiaro come ottenerle anche se il referente abituale non è disponibile. ## Backup, staging e alta disponibilità non sono la stessa cosa - Lo staging serve a provare modifiche; può contenere dati obsoleti e non è una copia di recupero affidabile. - L’ alta disponibilità riduce i tempi di fermo dovuti a guasti, ma può replicare cancellazioni o corruzioni. - Il backup permette di tornare a uno stato precedente. - Il disaster recovery comprende persone, infrastruttura, priorità e procedure per ristabilire il servizio. Confondere questi controlli crea un falso senso di protezione. ## Un esempio di fallimento evitabile Un sito e-commerce ha backup giornalieri sullo stesso account hosting. Un attacco compromette pannello e sito e cancella anche gli archivi. L’azienda scopre che non esistono copie esterne e che i record degli ordini più recenti non sono presenti nel gestionale. Una strategia migliore avrebbe previsto copia offsite con account separato, retention, esportazione o replica degli ordini e test periodico. Il problema non era il plugin scelto, ma l’assenza di indipendenza e verifica. ## Checklist di accettazione Un piano può essere considerato operativo quando: - l’ambito è documentato; - frequenza e retention derivano da RPO e rischio; - almeno una copia è separata dall’infrastruttura primaria; - errori e mancati backup generano avvisi; - accessi e cifratura sono controllati; - esiste un runbook; - un ripristino completo è stato provato; - tempi e lacune emersi dal test sono stati corretti; - owner e data della prossima prova sono definiti. ## Il principio finale Il backup è una capacità di recupero, non un archivio. La sua qualità si misura nel momento in cui file, database, persone e procedure devono ricostruire un servizio coerente. Finché il ripristino non è stato provato, esiste soltanto una speranza ben confezionata. ## Fonti ufficiali - WordPress Developer Resources, Backups: https://developer.wordpress.org/advanced-administration/security/backup/ - WordPress Developer Resources, Hardening WordPress: https://developer.wordpress.org/advanced-administration/security/hardening/ Approfondisci il servizio: Hosting gestito. --- Versioni alternative di questo contenuto: - HTML completo: https://www.klc.it/blog/siti-web/backup-wordpress-strategia-retention-e-ripristino/ - JSON strutturato: https://www.klc.it/blog/siti-web/backup-wordpress-strategia-retention-e-ripristino.json Fonte: KLC Licenza: All rights reserved Generato da AI Discovery Bridge v1.9.3