Velocità di backup del sito web: perché i tuoi backup sono lenti e come risolverli

Il tuo backup è in esecuzione da 45 minuti. Nulla è rotto, ma una barra di avanzamento continua a muoversi.

O forse il tuo sito rallenta fino a bloccarsi ogni notte alle 3 del mattino, e non riesci a capire perché. Controlli le impostazioni dei tuoi plugin, esegui un test di velocità e non trovi nulla di ovvio. Poi qualcuno menziona i backup, e ti viene in mente.

I backup lenti del sito web sono un problema reale. Il processo di backup stesso potrebbe richiedere troppo tempo o fallire silenziosamente prima di finire. D'altra parte, il tuo backup potrebbe completarsi correttamente, ma le risorse che consuma durante l'esecuzione stanno rallentando il tuo sito live.

La soluzione è diversa a seconda del problema che stai affrontando. Questo tutorial li illustra entrambi.

Alla fine, avrai affrontato la scarsa velocità dei backup del sito web, lavorato attraverso le impostazioni di Duplicator Pro che la affrontano e impostato una pianificazione dei backup che non compete con il tuo traffico reale.

Ecco i punti chiave:

• Ci sono due distinti problemi di velocità dei backup: un processo di backup lento o rotto e un backup che rallenta il tuo sito live durante la finestra di backup. La soluzione è diversa per ciascuno, e questo post li copre entrambi.
• Un backup che sembra completo ma non riesce a ripristinare è un problema di timeout PHP, non un problema di corruzione. Il formato DupArchive di Duplicator Pro previene questo elaborando i file in blocchi invece che in un'unica operazione continua.
• Ridurre le dimensioni del tuo archivio è la leva più veloce. Le directory della cache, i file di log e gli archivi di backup residui di altri plugin possono essere esclusi in sicurezza e spesso rappresentano la maggior parte del peso non necessario del backup.
• I backup completi giornalieri del sito sono solitamente eccessivi. Un backup giornaliero solo del database (meno di 30 secondi) abbinato a un backup settimanale completo del sito riduce il tempo di creazione e il carico del server senza sacrificare la copertura del ripristino.
• Il cron di WordPress non viene eseguito secondo una pianificazione reale. I backup pianificati per le 3 del mattino possono spostarsi silenziosamente nelle ore di punta del traffico. Sostituire WP-Cron con un vero job cron del server è ciò che rende i backup pianificati veramente affidabili.
• Prova un ripristino prima di averne bisogno. La maggior parte delle persone scopre un backup rotto durante un vero disastro. Verificare un ripristino su un sito di staging richiede 20 minuti ed è l'unico passaggio che separa un recupero rapido da uno doloroso.

Indice

Quanto dovrebbe durare un backup di WordPress?

Su un sito ben configurato con hosting decente, un backup completo dovrebbe completarsi in due o dieci minuti. Siti di grandi dimensioni su hosting condiviso potrebbero impiegare da 30 a 45 minuti, a volte di più. E il tempo varia non solo in base alle dimensioni del sito, ma anche a come viene eseguito il backup, a cosa consente il tuo host e se il tuo server è sotto carico quando il processo inizia.

Quattro fattori guidano la maggior parte della variazione.

• Limiti I/O dell'host

L'hosting condiviso limita il numero di operazioni di lettura e scrittura che il tuo account può eseguire al secondo. Un backup legge ogni file del tuo sito e li scrive in un archivio. Su un server limitato, questo processo rallenta fino a bloccarsi e può compromettere il tempo di risposta del tuo sito mentre è in esecuzione.

• Dimensione del sito

Una libreria multimediale di grandi dimensioni, un database gonfio o anni di file di plugin accumulati prolungano il tempo di creazione. Un sito da 500 MB e un sito da 5 GB non verranno sottoposti a backup allo stesso modo.

• Metodo di backup

I backup completi comprimono tutto da zero ogni volta. I backup incrementali salvano solo ciò che è cambiato dall'ultima esecuzione, rendendoli significativamente più veloci dopo il completamento del primo backup. Duplicator Pro supporta entrambi gli approcci e la strategia a due pianificazioni di questo tutorial ti offre la maggior parte dei vantaggi di velocità dei backup incrementali senza la complessità.

• Timeout PHP

La maggior parte degli host condivisi imposta limiti di tempo di esecuzione PHP tra 30 e 60 secondi. Un backup che supera questo limite viene interrotto a metà processo. Il file sembra completo. Non lo è. Questa è una delle cause più comuni di backup che sembrano riusciti ma falliscono durante un ripristino.

Cosa Ti Serve Prima di Iniziare

Prima di modificare qualsiasi impostazione, assicurati di avere quanto segue a disposizione.

• Un plugin di backup WordPress installato e attivo. Questo tutorial utilizza Duplicator Pro per tutti i passaggi specifici e i riferimenti all'interfaccia utente. Duplicator Pro è un plugin di backup, migrazione e ripristino di emergenza per WordPress utilizzato da oltre 1,5 milioni di professionisti WordPress. Gestisce backup, migrazioni di siti, staging e ripristini, incluso un formato di archivio basato su blocchi progettato specificamente per sopravvivere ai limiti di timeout PHP comuni nell'hosting condiviso.
• Accesso all'amministrazione di WordPress (ti servirà per accedere alle impostazioni del tuo plugin di backup)
• Accesso al pannello di controllo dell'hosting (cPanel o l'equivalente del tuo host, necessario per la configurazione dei cron del server e le modifiche ai limiti PHP)
• La dimensione attuale del tuo backup (trovala nella schermata del pacchetto o della cronologia dei backup del tuo plugin)
• Il tuo tipo di hosting: condiviso, VPS, WordPress gestito o dedicato. Questo è importante perché alcune correzioni in questo tutorial richiedono la collaborazione del tuo host. Nell'hosting condiviso, non sempre puoi modificare tu stesso le impostazioni PHP.
• Accesso al supporto di hosting (chat dal vivo o un sistema di ticket di supporto, potresti averne bisogno per i passaggi 3 e 8)

Conoscere il tuo tipo di hosting prima di iniziare ti farà risparmiare tempo. Gli aumenti di Shell Exec e del limite di memoria PHP sono controllati a livello di server. Ciò che puoi modificare tu stesso dipende interamente dal tuo piano.

Come velocizzare i backup del tuo sito web

Seguendo questi passaggi otterrai i risultati più rapidi. Il primo passo è una diagnosi, in modo da sapere quali correzioni si applicano effettivamente alla tua situazione prima di iniziare a modificare le impostazioni.

Ecco cosa farai:

• Passaggio 1: Identifica il problema di prestazioni del tuo backup: diagnostica se il tuo processo di backup è lento o interrotto o se i backup completati stanno rallentando il tuo sito live, poiché la correzione è diversa per ciascuno
• Passo 2: Riduci ciò che viene sottoposto a backup: escludi le directory della cache, i file di log e gli archivi di plugin residui per ridurre le dimensioni del tuo archivio, che è il modo più veloce per ridurre il tempo di compilazione
• Passo 3: Passa a un motore di archiviazione più veloce: sostituisci ZipArchive basato su PHP con Shell Exec per la velocità o DupArchive per la resilienza su host con limiti di esecuzione PHP ristretti
• Passo 4: Correggi i backup lenti del database: passa la modalità SQL a Codice PHP ed esegui una pulizia del database per ridurre il tempo di esportazione su database superiori a 20 MB
• Passo 5: Sostituisci il cron di WordPress con un vero job cron del server: fai in modo che i backup pianificati vengano eseguiti all'ora esatta impostata invece di attivarsi ogni volta che arriva il primo visitatore
• Passo 6: Imposta una strategia di backup a due pianificazioni: esegui backup giornalieri solo del database e backup settimanali dell'intero sito separatamente in modo che le compilazioni pesanti avvengano il meno frequentemente possibile
• Passo 7: Richiedi limiti di risorse del server più elevati: aumenta i limiti di memoria PHP e tempo di esecuzione come ultima risorsa quando tutte le altre impostazioni sono già ottimizzate

Passaggio 1: Identifica il tuo problema di prestazioni del backup

Ci sono due problemi diversi nascosti dietro "il mio backup è lento."

• Problema A: Il processo di backup stesso è lento o interrotto. I segnali includono compilazioni che richiedono più di 20 minuti, una barra di avanzamento che si blocca a una percentuale specifica o un backup che sembra completarsi ma fallisce durante un ripristino.
• Problema B: I tuoi backup stanno rallentando il tuo sito live. I segnali includono visitatori o amministratori che segnalano lentezza durante una finestra temporale ricorrente o uno strumento di monitoraggio che mostra un picco nel tempo di risposta che si verifica secondo una pianificazione prevedibile.

Per distinguerli, inizia con il log di compilazione del tuo plugin di backup. Per Duplicator, vai su Duplicator Pro » Strumenti » Log di Duplicator. Trova il log del tuo backup più recente.

Altri plugin hanno log simili: controlla le impostazioni avanzate del tuo plugin.

Scorri fino in fondo. Se vedi un errore di timeout, un errore di memoria o una riga che si interrompe a metà processo, quello è il Problema A. Se il log mostra che è stato completato, ma il tuo sito sta ancora rallentando, quello è il Problema B.

Un altro scenario degno di nota prima di procedere: se il tuo log di compilazione dice che il backup è stato completato ma il backup fallisce durante un ripristino, un limite di tempo di esecuzione PHP probabilmente ha interrotto silenziosamente la compilazione prima che finisse.

Il file esiste, ma è stato troncato. Sembra il Problema A, ma la causa principale è un limite di risorse dell'hosting. Il Passo 3 copre questo direttamente.

Se hai bisogno di aiuto per leggere i log di backup di Duplicator, leggi questa guida.

Passaggio 2: Riduci ciò che viene sottoposto a backup

Ogni megabyte in più nel tuo backup estende il tempo di compilazione. Su hosting condiviso, dove CPU e I/O del disco sono già limitati, un archivio gonfio rende i backup più lenti e ti avvicina alla soglia di timeout in cui i backup iniziano a fallire.

Il modo più veloce per ridurre il tuo backup è smettere di includere file che non devono esserci.

I trasgressori più comuni:

• Directory della cache
• File di log
• File temporanei
• Archivi di backup lasciati da altri plugin
• File multimediali di grandi dimensioni come video che memorizzi anche su un CDN o un servizio esterno

Nessuna di queste influisce sulla tua capacità di ripristinare un sito funzionante. Le cache si rigenerano automaticamente quando i visitatori caricano le pagine. I log non fanno parte del tuo sito. I vecchi archivi di backup di altri plugin aggiungono solo peso.

Ecco come personalizzare i backup in Duplicator Pro. Crea un nuovo backup andando su Duplicator Pro » Backups » Add New.

Nella sezione Backup, vedrai preset e filtri.

Abilita i filtri dei file. Escludi prima la tua directory della cache selezionando il filtro della cache.

Se utilizzi un plugin di caching come WP Rocket o W3 Total Cache, potrebbe esserci anche una sottocartella specifica del plugin all'interno di wp-content. Aggiungi il percorso completo per ciascuna di esse.

Quindi aggiungi eventuali directory di log. Le posizioni comuni includono wp-content/debug.log e cartelle di log specifiche del plugin.

Non escludere wp-content/uploads a meno che tu non memorizzi tutti i tuoi media in una CDN separata e disponga di una copia confermata e aggiornata di ogni file. Escludi solo estensioni di file specifiche di cui sei certo che siano sottoposte a backup altrove. Un errore qui con i tuoi media significa un ripristino riuscito ma privo della metà delle tue immagini.

Una volta aggiunti i filtri, procedi con il backup. Duplicator Pro analizzerà il tuo sito e segnalerà eventuali altri file di grandi dimensioni.

Passaggio 3: Passa a un Motore di Backup Più Veloce

Una volta che il tuo file di backup è il più snello possibile, la variabile successiva è come viene creato il backup. Per impostazione predefinita, utilizza ZipArchive integrato di PHP. Funziona, ma viene eseguito interamente all'interno di PHP, il che significa che è soggetto a ogni limite di risorse impostato dal tuo host: tempo di esecuzione, memoria e limitazione della CPU.

Su un server capace, probabilmente va bene. Su hosting condiviso, potrebbe creare colli di bottiglia.

Hai due alternative, e quale usare dipende dal tuo host.

Opzione A: Shell Zip

Questo cambia il motore di archiviazione di backup da PHP al binario zip nativo del tuo sistema server. Lo strumento zip del sistema operativo è più veloce di PHP per la maggior parte delle attività di compressione e non viene conteggiato nel limite di tempo di esecuzione di PHP allo stesso modo.

Per cambiare, vai su Duplicator Pro » Settings » Backups » Archive e seleziona Shell Zip.

Prima di effettuare il cambio, sappi questo: alcuni host condivisi economici disabilitano shell_exec a livello di server. Se cambi l'impostazione e la tua prossima build fallisce immediatamente allo 0%, è successo questo.

Torna a ZipArchive nella stessa schermata delle impostazioni, quindi contatta il tuo host e chiedi loro di abilitare shell_exec per il tuo account. Se non possono aiutarti, passa all'Opzione B.

Opzione B: DupArchive

Questo è il formato di archivio di Duplicator e funziona in modo diverso da ZIP standard. Invece di un'unica operazione di compressione continua, DupArchive elabora i tuoi file in blocchi più piccoli. Ogni blocco viene completato prima che inizi il successivo.

Nei piani di hosting condiviso con limiti di tempo di esecuzione PHP da 30 a 60 secondi, un backup ZIP standard che richiede più tempo di quel limite viene interrotto a metà della build. Il processo si ferma, ma il file è già stato scritto sul disco.

Il tuo backup sembra completo. Poi, quando provi a ripristinarlo, fallisce. Il file è stato troncato prima che fosse finito.

DupArchive evita questo interamente. Poiché ogni blocco reimposta l'orologio di esecuzione di PHP, il backup sopravvive ai limiti che ucciderebbero una build ZIP standard. Ho visto questa correzione risolvere problemi su hosting condiviso più di una volta.

Per passare, vai su Duplicator Pro » Impostazioni » Backup » Archivio e scegli DupArchive.

Dopo aver selezionato una delle due opzioni, esegui un backup di prova. Crea un piccolo backup, quindi controlla il log al termine. Scorri fino in fondo al log e conferma che sia stato completato con successo.

Passaggio 4: Correggi i backup lenti del database

Un database di grandi dimensioni rallenta l'intera build di backup, non solo la porzione in cui il database viene esportato. Se il tuo database è gonfio, lo sentirai in tutto il processo.

Per trovare la dimensione del tuo database, avvia un nuovo backup in Duplicator Pro e lascia che la procedura guidata di configurazione esegua la scansione. Elencherà la dimensione del tuo database prima che tu decida di creare il backup.

Se è superiore a 20 MB, queste correzioni possono fare una differenza notevole.

Correzione 1: Passa la modalità SQL al codice PHP

Vai su Duplicator Pro » Impostazioni » Backup » Modalità SQL e cambia l'impostazione da dump MySQL a Codice PHP. Questo cambia il metodo che Duplicator utilizza per esportare le tabelle del tuo database.

Il metodo Codice PHP è generalmente più affidabile sull'hosting condiviso perché è meno probabile che attivi timeout di blocco della tabella che bloccano l'esportazione. È un piccolo cambiamento con un effetto significativo sui database più grandi.

Correzione 2: Pulisci il database prima del prossimo backup

Questo richiede qualche minuto, ma vale la pena farlo prima di qualsiasi backup importante.

Installa WP-Optimize o un plugin di pulizia del database simile ed eseguilo per rimuovere revisioni dei post, commenti spam, transienti scaduti e metadati orfani. Questi si accumulano silenziosamente sui siti attivi e possono rappresentare dal 30 al 50 percento del gonfiore del database senza contenere nulla che sia necessario ripristinare.

Sul mio sito personale, ho eseguito un backup prima e dopo una rapida pulizia del database con WP-Optimize. Ha ridotto il mio tempo di backup di 30 secondi e le dimensioni del file.

Tuttavia, non pulire il tuo database ed eseguire immediatamente un backup critico per la prima volta. Esegui la pulizia, quindi naviga sul tuo sito e verifica che tutto funzioni normalmente, quindi esegui il backup. Le pulizie sono sicure se eseguite con uno strumento affidabile, ma vuoi confermare che il tuo sito sia sano prima di bloccare quello stato in un backup.

Dopo aver apportato entrambe le modifiche, esegui un nuovo backup e confronta il tempo di build con il tuo baseline precedente. Sui database superiori a 20 MB, la differenza è solitamente visibile.

Passaggio 5: Sostituisci WordPress Cron con un vero job cron del server

Se i tuoi backup sono pianificati ma continuano a essere eseguiti all'ora sbagliata, o se il tuo sito rallenta durante le ore lavorative invece che nella finestra tranquilla che hai impostato, cron di WordPress è probabilmente il motivo.

WP-Cron non viene eseguito secondo una pianificazione reale. Si attiva solo quando qualcuno visita il tuo sito.

Quando arriva il traffico, WordPress controlla se ci sono attività pianificate in ritardo e le esegue in quel momento. Un backup che hai pianificato per le 3 del mattino viene eseguito quando arriva il primo visitatore, il che potrebbe essere proprio nel bel mezzo della tua finestra di traffico di punta.

Sostituire WP-Cron con un cron job del server garantisce che i tuoi backup vengano eseguiti all'ora esatta impostata, ogni volta, indipendentemente dal traffico.

Inizia creando un account su https://cron-job.org/. Quindi, crea un nuovo cron job.

Dai un nome al nuovo cron job. Imposta questo come URL, sostituendolo con il dominio del tuo sito: https://example.com/wp-admin/admin-ajax.php?action=duplicator_process_worker

Imposta la Pianificazione di esecuzione su Ogni 1 minuto.

Una volta che il cron job del server è attivo e salvato, aggiungi questa riga al tuo file wp-config.php, sopra la riga che dice "That's all, stop editing!":

define('DISABLE_WP_CRON', true);

Questo dice a WordPress di smettere di eseguire il proprio sistema cron.

Aggiungi la riga define a wp-config.php solo dopo che il cron job del server è stato confermato e salvato. Se disabiliti WP-Cron per primo, tutte le attività pianificate sul tuo sito si interrompono immediatamente. Backup pianificati, post pianificati, qualsiasi cosa che dipenda da WP-Cron si ferma finché il cron del server non è attivo.

Se sei su un hosting WordPress gestito come WP Engine, Kinsta o Flywheel, consulta la documentazione del tuo host prima di modificare wp-config.php. Alcuni host gestiti gestiscono il cron del server in modo diverso o lo gestiscono per tuo conto.

Dopo l'impostazione, torna a Duplicator Pro » Impostazioni » Backup Pianificati e verifica che l'ora del prossimo backup pianificato rifletta esattamente ciò che hai configurato. Quella conferma è il tuo segnale che il passaggio è avvenuto con successo.

Passaggio 6: Imposta una strategia di backup a due pianificazioni

I backup giornalieri dell'intero sito sono una delle cause più comuni sia di backup lenti che di siti lenti su hosting condiviso. Sono anche, per la maggior parte dei siti WordPress, più di quanto tu abbia effettivamente bisogno.

Il tuo database cambia costantemente, con nuovi post, ordini, invii di moduli, commenti e attività dei plugin. Al contrario, i tuoi file, temi, plugin e caricamenti vengono aggiornati occasionalmente.

Eseguire un backup completo ogni giorno significa comprimere e archiviare gigabyte di file che non sono stati modificati di recente.

La soluzione è costituita da due pianificazioni di backup separate.

• Pianificazione A: backup giornaliero solo del database. Un backup solo del database cattura ogni modifica ai tuoi contenuti, ordini e impostazioni senza toccare i tuoi file. Sulla maggior parte dei siti si completa in meno di 30 secondi. Esegui questo backup giornalmente.
• Pianificazione B: backup settimanale dell'intero sito. Inclusi i file, esegui una volta alla settimana durante la tua finestra di traffico più bassa. Questo è il backup che ripristini se qualcosa va molto male.

Prima di impostare la pianificazione, trova la tua finestra di traffico reale più bassa. Cerca il blocco di due ore con il minor numero di sessioni in una settimana tipica.

Per la maggior parte dei siti, questo si colloca tra le 2 e le 5 del mattino, ma verifica con i tuoi dati. Il tuo modello di traffico non è uguale a quello di nessun altro.

Quindi, vai su Duplicator Pro » Pianificazione Backup » Aggiungi Nuovo. Dai un nome alla pianificazione come Backup Database. Aggiungi un nuovo modello di backup.

Dai un nome al modello. Scegli il preset di backup Solo Database e salvalo.

Torna alla nuova pianificazione e scegli il modello di backup del database che hai appena creato. Scegli una posizione di archiviazione e impostala per l'esecuzione giornaliera.

Salva. Quindi crea una seconda pianificazione e ripeti il processo, ma con un modello di backup dell'intero sito. Lasciala eseguire settimanalmente.

Entrambe le pianificazioni appariranno in Duplicator Pro » Pianificazioni backup con i relativi orari di esecuzione successivi.

Passaggio 7: Aggiungi backup incrementali

I backup completi comprimono l'intero sito da zero ogni volta che vengono eseguiti. Va bene per i backup settimanali dell'intero sito, ma è più di quanto la maggior parte dei siti necessiti per la protezione giornaliera.

I backup incrementali adottano un approccio diverso: dopo il primo backup completo, salvano solo ciò che è cambiato dall'ultima esecuzione. Il backup viene completato più velocemente perché non rielabora file che non sono cambiati.

Duplicator Pro non esegue veri backup incrementali, ma la strategia a due pianificazioni del Passaggio 6 offre la maggior parte dello stesso beneficio. I backup giornalieri solo del database catturano tutto ciò che cambia su un tipico sito WordPress, completandosi in meno di 30 secondi. Il backup settimanale dell'intero sito gestisce tutto il resto.

Per la maggior parte dei siti, questa divisione copre la necessità pratica che i backup incrementali sono progettati per risolvere.

Se il tuo sito è abbastanza grande da rendere i backup settimanali dell'intero sito costantemente lenti o fallimentari, i backup incrementali dei file potrebbero valere la pena di essere implementati. Strumenti come BlogVault elaborano i backup sui loro server anziché sui tuoi, il che elimina il problema del carico del server.

Passaggio 8: Richiedi limiti di risorse del server più elevati

I limiti di memoria e tempo di esecuzione di PHP sono vincoli reali, ma modificarli richiede la collaborazione del tuo host e non risolve problemi sottostanti come un archivio gonfio o una pianificazione mal sincronizzata.

Prima affronta i passaggi precedenti. Se i backup continuano a scadere, il limite potrebbe essere le risorse del tuo piano di hosting.

Due impostazioni sono fondamentali per la velocità di backup: memory_limit e max_execution_time.

memory_limit controlla quanta RAM PHP può utilizzare durante un singolo processo. I backup richiedono molta memoria. Se il tuo limite è impostato su 64 MB o 128 MB, le build di grandi dimensioni esauriscono lo spazio e si interrompono prima di finire.

Richiedi almeno 256 MB. Se il tuo host offre 512 MB, richiedi quello invece.

max_execution_time controlla per quanto tempo un processo PHP può essere eseguito prima che il server lo termini. L'impostazione predefinita su molti host condivisi è da 30 a 60 secondi. Un backup di grandi dimensioni richiede significativamente più tempo. Richiedi 300 secondi.

Contatta il team di supporto del tuo host e sii specifico nella tua richiesta. Richiedi un memory_limit di 512 MB e un max_execution_time di 300 secondi.

Se il tuo host non può o non vuole aumentare questi limiti, DupArchive dal Passaggio 3 è la tua strada pratica da percorrere. È specificamente progettato per funzionare entro limiti PHP ristretti suddividendo il processo. È più lento di Shell Exec su un server capace, ma finisce dove una normale build ZIP non riuscirebbe.

Dopo qualsiasi modifica ai limiti, esegui un backup di prova e apri il log di build. Conferma che il backup è stato completato senza errori di timeout o di memoria.

Risoluzione dei problemi: quando i backup sono ancora lenti o interrotti

Affrontare i passaggi precedenti risolve la maggior parte dei problemi di velocità dei backup del sito web. Se qualcosa non va ancora, ecco cosa stai più probabilmente riscontrando e come superarlo.

Il backup si completa ma non riesce a ripristinare

Vedi un backup, il log di build non mostra errori evidenti, ma quando esegui l'installer, questo genera un errore o ripristina un sito vuoto.

Ciò accade perché un limite di tempo di esecuzione PHP ha interrotto la build prima che fosse effettivamente completata. Il file è stato scritto sul disco fino a quel punto e poi si è fermato.

Passa a DupArchive (coperto nel Passaggio 3), quindi elimina il backup fallito e creane uno nuovo. Esegui l'installer e verifica che il ripristino venga completato prima di fare affidamento su di esso.

Il backup è bloccato a una percentuale specifica

La barra di avanzamento si blocca in un punto specifico e rimane lì per più di dieci minuti senza muoversi.

Un file di grandi dimensioni o una tabella di database bloccata sta bloccando il processo in quel punto esatto della build. Vai al log di backup e scorri per trovare l'ultimo file o tabella elencati prima che il log si interrompa. Quello è il colpevole.

Se si tratta di un file, aggiungilo ai tuoi filtri di esclusione (Passaggio 2) e ricostruisci. Se si tratta di una tabella di database, passa la modalità SQL a Codice PHP (Passaggio 4) e riprova.

Il sito rallenta ogni notte alla stessa ora

I visitatori o il tuo strumento di monitoraggio segnalano lentezza durante una finestra specifica. La tempistica corrisponde al tuo backup programmato.

Il tuo backup viene eseguito durante un periodo di traffico attivo e compete per le stesse risorse CPU e disco che servono i tuoi visitatori. Controlla la tua finestra di traffico basso effettiva in Google Analytics e riprogramma il backup in quel momento.

Se stai eseguendo backup giornalieri dell'intero sito, passa alla strategia di due pianificazioni dal Passaggio 6. I backup solo del database vengono completati abbastanza velocemente che l'impatto sulle prestazioni è minimo anche durante traffico moderato.

Shell Exec causa un fallimento immediato della creazione

Hai cambiato il motore di archiviazione in Shell Exec e la build successiva fallisce allo 0% con un errore immediato.

Il tuo host ha disabilitato shell_exec a livello di server. Torna a ZipArchive o DupArchive. Quindi contatta il tuo host e chiedi specificamente se shell_exec può essere abilitato per il tuo account.

Se dicono di no, DupArchive è il tuo motore di archiviazione a lungo termine. Gestisce gli stessi problemi di timeout che Shell Exec avrebbe risolto, solo attraverso un metodo diverso.

I backup funzionano in staging ma falliscono sul server live

I tuoi backup hanno successo su siti di staging o locali, ma vanno in timeout o producono file corrotti sulla produzione.

Il tuo server live ha limiti PHP più restrittivi o è soggetto a throttling attivo della CPU che il tuo ambiente di staging non ha. Confronta le impostazioni PHP tra gli ambienti: controlla memory_limit e max_execution_time in entrambi. Richiedi limiti più alti al tuo host live (Passaggio 7) o passa a DupArchive per lavorare entro i limiti esistenti.

Se nessuna delle soluzioni precedenti risolve il tuo problema, il team di supporto di Duplicator Pro è il passo successivo corretto. Vai su duplicator.com e apri un ticket di supporto. Includi il tuo log di build, le tue impostazioni PHP e il tuo ambiente di hosting. Questi tre elementi ti porteranno a una risoluzione più velocemente di una descrizione generica del problema.

Domande frequenti (FAQ)

Una build ZIP standard che richiede più tempo del limite del tuo host viene interrotta a metà processo e produce un pacchetto danneggiato. DupArchive sopravvive a questi limiti perché ogni blocco reimposta l'orologio.

Non è sempre più veloce di ZIP su server capaci, ma è significativamente più affidabile su ambienti di hosting condiviso con risorse limitate.

La domanda più importante è se hai testato un ripristino di recente. Un backup che non hai mai testato è un backup che in realtà non sai se funziona. Scegli un ambiente di staging, ripristina il tuo backup più recente e verifica che il sito si carichi correttamente.

Esegui il tuo prossimo backup senza chiederti se funzionerà

Un backup lento è un inconveniente. Un backup che sembra completo ma non può essere ripristinato è un problema completamente diverso, ed è più comune di quanto la maggior parte delle persone si aspetti.

Le impostazioni in questo tutorial esistono perché l'hosting condiviso non è stato progettato pensando ai backup di WordPress. Duplicator Pro lo è stato.

Oltre 1,5 milioni di professionisti WordPress utilizzano Duplicator Pro per gestire backup, migrazioni, staging e disaster recovery su siti di ogni dimensione. Il formato DupArchive, la strategia a due pianificazioni e i filtri di esclusione dei file ti aiutano a evitare backup lenti o che consumano molte risorse.

Se questo tutorial ti è stato utile, anche queste guide meritano di essere aggiunte ai preferiti.

• Come i backup di WordPress influiscono sulle prestazioni del sito (e come risolverlo)
• Smetti di indovinare perché i backup falliscono (Controlla invece questi log)
• Sito appena bloccato? Ecco il tuo piano completo di ripristino del sito web
• Perché il tuo sito WordPress ha bisogno del monitoraggio dei backup (non solo dei backup)
• Come visualizzare il tuo backup WordPress come sito web funzionante