Backup del sito web spiegato: cosa viene salvato e perché è importante?

Tempo di lettura ca.: 10 minuti

Un backup del sito web è una copia di sicurezza dei dati importanti del tuo account di hosting. Consente di ripristinare i dati a uno stato precedente se i file sono stati cancellati accidentalmente, se un sito web non funziona più dopo una modifica o se sono necessari i dati di una versione precedente.

Su un sito web moderno non basta proteggere unicamente le pagine visibili. Un sito web può essere composto da file, database, e-mail e numerosi altri dati che insieme formano l'intero account di hosting.

In questo articolo spieghiamo cos'è un backup di un sito web, quali dati possono essere salvati e quali sono i limiti di un backup.

Breve spiegazione: Un backup è una copia aggiuntiva dei tuoi dati risalente a un momento specifico. Con esso è possibile ripristinare i dati da una precedente versione salvata. Un backup non impedisce un errore o un attacco, ma può essere fondamentale se i dati sono necessari di nuovo dopo un simile evento.

Cos'è un backup? #

Un backup è una copia di sicurezza separata dei dati presenti in un determinato momento.

In sintesi:

Dati di produzione
      ↓
   Backup
      ↓
Stato del backup

Se un file viene cancellato o modificato in seguito, una versione precedente potrebbe essere recuperata da un backup esistente.

Il momento in cui viene effettuato il backup è determinante. Un backup contiene fondamentalmente lo stato dei dati salvati al rispettivo momento del salvataggio.

Perché sono importanti i backup? #

I siti web e gli account di hosting cambiano continuamente. I file vengono modificati, le e-mail ricevute, i database aggiornati, i plugin di WordPress installati e i contenuti pubblicati.

Ciò può comportare la presenza di errori.

Situazioni tipiche sono ad esempio:

  • Un file importante è stato eliminato o sovrascritto per errore.
  • Un sito web non funziona più dopo una modifica.
  • Un aggiornamento di WordPress sta causando problemi imprevisti.
  • I contenuti o i dati sono stati modificati involontariamente.
  • Sono necessari i dati di posta elettronica di un periodo precedente.
  • Un sito web è stato danneggiato o compromesso.

Un punto di salvataggio esistente può offrire in tali situazioni la possibilità di ripristinare i dati necessari da uno stato precedente.

Da quali componenti è composta una pagina web? #

Il termine „sito web“ viene spesso utilizzato come se si trattasse di un singolo file. In realtà, i siti web moderni sono solitamente costituiti da più componenti.

Nel caso di un sito Web WordPress, ad esempio, rientrano:

File di WordPress
Temi
Plugin
Caricamenti e immagini
File di configurazione
Database MySQL

I file e il database assolvono a compiti diversi.

Nei file si trovano, ad esempio, WordPress stesso, i plugin, i temi e i media caricati. Nel database vengono memorizzati, tra le altre cose, post, pagine, impostazioni e molte altre informazioni dinamiche.

Importante: Pertanto, un backup dei soli file di WordPress non costituisce automaticamente un backup completo del sito web. Nei siti basati su database, anche il database fa parte dei dati rilevanti.

Cosa può comprendere un backup di hosting? #

Un account di hosting completo comprende solitamente molto più del solo sito web effettivo.

A seconda dell'account e dei servizi utilizzati, possono essere presenti, tra gli altri, i seguenti dati:

  • File del sito web
  • Database
  • Dati e-mail
  • Dati di configurazione dell'account di hosting
  • altri dati relativi all'account

Ecco perché in un ripristino è importante distinguere, quali dati siano effettivamente necessari.

Non è sempre necessario ripristinare l'intero account #

Se manca anche solo un singolo file, sarebbe superfluo ripristinare automaticamente l'intero account di hosting a una versione precedente per questo motivo.

Dati protetti di un account di hosting in JetBackup 5

Lo stesso vale, ad esempio, per i dati delle e-mail.

A seconda della situazione, un ripristino può essere effettuato in modo mirato:

singolo file

dati email specifici

set di dati specifico

oppure

account hosting completo

Su CURIAWEB i ripristini possono quindi essere eseguiti in modo mirato a seconda del problema specifico.

Cosa significa lo stato di un backup? #

Un backup, spesso chiamato anche punto di ripristino o restore point, indica uno stato salvato di un determinato momento.

Stati dei backup giornalieri in JetBackup 5 su CURIAWEB

Un esempio semplificato:

30. agosto → stato del backup odierno
29. agosto → stato del backup precedente
28. agosto → stato del backup precedente
27. agosto → stato del backup precedente
...

Se, ad esempio, il 30 agosto ti accorgi che un file è stato modificato accidentalmente già il 28 agosto, un backup del 29 agosto potrebbe essere a sua volta già compromesso.

Per un ripristino con successo è quindi necessario selezionare un punto di salvataggio in cui i dati richiesti si trovavano ancora nello stato desiderato.

Il backup più recente non è automaticamente quello giusto #

Questo punto è particolarmente importante.

Supponendo che sia stata fatta una modifica errata lunedì, ma sia stata scoperta solo giovedì.

I backup di martedì, mercoledì e giovedì potrebbero già contenere la modifica errata.

In questo caso potrebbe essere necessario utilizzare un backup precedente a lunedì.

Consiglio pratico: Se hai bisogno di un ripristino, cerca di determinare il più precisamente possibile quando i dati erano ancora corretti. Questo aiuta a scegliere lo stato di backup adatto.

Come funzionano i backup su CURIAWEB? #

CURIAWEB crea backup giornalieri dei dati di hosting. Le versioni di backup vengono conservate a rotazione per 30 giorni.

Visualizzare i backup di JetBackup 5 in CURIAWEB Hosting

In parole semplici, questo significa:

backup giornaliero
↓
30 giorni di conservazione
↓
la versione più vecchia viene rimossa
↓
viene aggiunta la nuova versione di backup

In questo modo sono disponibili punti di ripristino di giorni diversi, purché rientrino nel periodo di conservazione e il rispettivo backup sia stato creato con successo.

I fusibili vengono forniti con JetBackup 5 gestito.

Perché i backup vengono memorizzati separatamente? #

Un backup non dovrebbe dipendere esclusivamente dallo stesso sistema di produzione di cui deve proteggere i dati.

CURIAWEB memorizza pertanto i backup su server di backup separati in un centro elaborazione dati separato.

In sintesi:

Server di hosting di produzione
            ↓
Trasferimento del backup
            ↓
Infrastruttura di backup separata
            ↓
Centro dati separato

In questo modo i backup sono separati a livello infrastrutturale dal sistema di hosting di produzione.

Perché è utile un'infrastruttura di backup separata? #

Se l'unico backup si trovasse esclusivamente sullo stesso server dei dati di produzione, un problema grave potrebbe interessare entrambi i set di dati contemporaneamente.

La memorizzazione separata riduce questa dipendenza comune.

Questo non significa tuttavia che un backup escluda qualsiasi rischio immaginabile. I backup sono una componente importante di un concetto di protezione e ripristino, ma non costituiscono una garanzia che i dati non possano mai andare persi.

La conservazione di 30 giorni non significa archiviazione illimitata #

I backup di CURIAWEB vengono conservati a rotazione per 30 giorni.

In questo modo, con il passare del tempo, i backup meno recenti vengono rimossi dalla rotazione dei backup.

Se, ad esempio, ti accorgi solo diversi mesi dopo che un determinato file è necessario, il relativo backup storico potrebbe non essere più disponibile.

Un backup regolare con un periodo di conservazione limitato non è quindi la stessa cosa di un archivio a lungo termine.

Il backup e l'archiviazione assolvono a compiti diversi #

Un backup serve principalmente a poter ripristinare i dati da uno stato di salvataggio precedente in seguito a errori, perdite o altri problemi.

Un archivio, d'altro canto, persegue tipicamente l'obiettivo di conservare in modo mirato determinati dati per un periodo di tempo più lungo.

In sintesi:

Backup
→ salvataggio di sicurezza

Archiv
→ conservazione a lungo termine di determinati dati

Se determinati file o dati devono essere conservati per mesi o anni, non ci si dovrebbe affidare esclusivamente alla conservazione dei backup a rotazione.

Posso vedere i miei backup su CURIAWEB? #

Sì. I punti di backup esistenti possono essere consultati tramite JetBackup 5 essere visionato.

In questo modo puoi verificare, ad esempio, quali punti di backup sono disponibili per il tuo account di hosting.

Tuttavia, il ripristino effettivo viene eseguito da CURIAWEB.

Perché i backup non possono essere ripristinati autonomamente? #

La funzione di ripristino per i clienti è stata deliberatamente disattivata in CURIAWEB.

Un ripristino può richiedere risorse del server notevoli, in particolare per account di hosting di grandi dimensioni. Se vengono eseguiti più ripristini di grandi dimensioni contemporaneamente o non necessari, ciò può causare un carico elevato sul server.

A ciò si aggiunge il rischio di un uso errato. Un ripristino completo scelto erroneamente può sostituire i dati produttivi attuali con una versione precedente.

CURIAWEB esegue pertanto i ripristini in modo controllato. In questo modo è possibile verificare prima del ripristino quale versione di backup e quale volume di dati siano effettivamente necessari.

Importante: La limitazione riguarda solo il ripristino autonomo. Puoi visualizzare i backup esistenti in JetBackup 5 e successivamente comunicare a CURIAWEB quali dati, da quale backup, sono necessari.

Perché un ripristino mirato è spesso migliore #

Immagina di aver cancellato accidentalmente un singolo file oggi.

Un ripristino completo dell'account allo stato di ieri potrebbe contemporaneamente resettare altri dati che da allora sono cambiati correttamente.

Ciò può riguardare, ad esempio, contenuti attuali del sito web o dati di posta elettronica.

Se tecnicamente possibile e opportuno per il caso specifico, è quindi preferibile un ripristino mirato dei dati effettivamente necessari.

Cosa succede durante un ripristino completo? #

Durante un ripristino completo, un set di dati più ampio viene riportato allo stato del momento di backup selezionato.

Ciò significa contemporaneamente che le modifiche successive a tale momento di backup potrebbero essere interessate.

Esempio:

Backup:
Lunedì ore 02:00

Ripristino:
Mercoledì

Le modifiche successive a Lunedì ore 02:00
potrebbero non essere incluse
nei dati ripristinati.

Prima di un ripristino completo, è quindi necessario chiarire con precisione quali conseguenze la ricostruzione possa avere sui dati attuali.

Particolarmente importante per i siti web dinamici #

Su un sito web statico, tra un giorno e l'altro potrebbe cambiare ben poco.

Nei sistemi dinamici, invece, possono essere generati continuamente nuovi dati.

Gli esempi sono:

  • Ordini WooCommerce
  • Conti clienti
  • Voci di modulo
  • Commenti
  • nuovi articoli e pagine
  • impostazioni modificate
  • Dati e-mail

Un ripristino completo a una versione precedente può quindi avere conseguenze molto più rilevanti rispetto al ripristino di un singolo file.

Un backup non impedisce un attacco #

I backup non sono un sostituto delle misure di sicurezza.

Un backup, ad esempio, non impedisce che:

una password viene rubata
viene sfruttata una vulnerabilità di sicurezza
viene introdotto codice dannoso
un file viene eliminato
un plugin causa un errore

Tuttavia, il backup può svolgere un ruolo importante nel ripristino a seguito di un tale evento.

Un backup può già contenere un errore #

Anche questo punto viene spesso trascurato.

Se, ad esempio, un sito Web è compromesso già da diversi giorni, i backup più recenti potrebbero contenere anch'essi lo stato compromesso.

Non è quindi sempre sufficiente ripristinare semplicemente il backup più recente.

Durante un incidente di sicurezza, bisogna innanzitutto determinare il più precisamente possibile quando si è verificato il problema e se il punto di backup selezionato potrebbe essere già compromesso.

Il ripristino e la risoluzione dei problemi non sono la stessa cosa #

Se un sito web è guasto o danneggiato a causa di una causa specifica, un ripristino non risolve necessariamente tale causa.

Per esempio:

plugin non sicuro
      ↓
sito web compromesso
      ↓
ripristino di un backup meno recente
      ↓
plugin non sicuro ancora presente
      ↓
nuova compromissione possibile

Dopo un ripristino, a seconda della causa, è quindi necessario risolvere anche il problema effettivo.

Backup prima di modifiche importanti #

Prima di eseguire lavori estesi su un sito web, è opportuno considerare le opzioni di ripristino.

Questo vale ad esempio prima di:

aggiornamenti importanti di WordPress

cambi di tema

modifiche estese ai plugin

lavori sul database

migrazioni di siti web

importanti modifiche strutturali

In particolare, si dovrebbe verificare se è disponibile un backup recente e idoneo e quali dati potrebbero subire ulteriori modifiche durante i lavori.

Cosa dovresti specificare il più precisamente possibile durante un ripristino? #

Se contatti CURIAWEB per un ripristino, sono d'aiuto informazioni quanto più possibile precise.

Sono particolarmente importanti:

  • quale account di hosting o quale dominio sia interessato,
  • quali dati ripristinare,
  • quale versione di backup o quale data sia necessaria,
  • è successo e
  • da quanto tempo persiste il problema.

Per un singolo file, se possibile, dovresti specificare anche il nome del file e il percorso.

Per i dati di posta elettronica, è necessario specificare l'account di posta interessato.

Ripristinare il backup #

Se hai bisogno di dati da un backup esistente, contatta il supporto di CURIAWEB. Comunicaci nel modo più preciso possibile quale versione di backup e quali dati ti servono.

Crea un ticket di supporto per un ripristino

Successivamente verifichiamo il ripristino desiderato ed eseguiamo il recupero in modo controllato per te.

Consiglio pratico: In caso di perdita di dati, modifica il meno possibile fino a quando non viene chiarito quale ripristino sia opportuno. Soprattutto nei siti web dinamici, modifiche successive possono rendere più difficile la decisione tra un ripristino completo e uno mirato.

Ciò che un backup non sostituisce #

Anche con backup regolari, rimangono necessarie ulteriori misure.

Ciò include, ad esempio, software aggiornato, credenziali di accesso sicure, diritti utente appropriati, un sito web ben curato e il monitoraggio dei sistemi importanti.

I backup costituiscono in questo caso il livello di ripristino:

Prevenire il più possibile gli errori
+
Riconoscere i problemi precocemente
+
Risolvere la causa
+
Poter ripristinare i dati

Solo l'interazione di queste misure dà vita a un concetto di sicurezza e operativo affidabile.

Riepilogo #

Un backup di un sito Web è una copia di sicurezza dei dati di un determinato momento. Per un account di hosting, questo può includere file del sito Web, database, dati di posta elettronica e altri dati dell'account.

CURIAWEB esegue il backup giornaliero dei dati di hosting con JetBackup 5 e conserva le copie di sicurezza in modo rotativo per 30 giorni. I backup si trovano su server di backup separati in un data center separato e sono quindi isolati dall'infrastruttura di hosting di produzione.

I clienti possono visualizzare i punti di backup esistenti in JetBackup 5. I ripristini vengono eseguiti deliberatamente da CURIAWEB. In questo modo è possibile decidere in modo mirato, a seconda della situazione, se ripristinare ad esempio singoli file, dati di posta elettronica o un intero account di hosting.

Un backup non è tuttavia né un archivio illimitato né un sostituto delle misure di sicurezza. Inoltre, non è automaticamente il backup più recente a costituire il punto di ripristino corretto. Ciò che è determinante è il momento in cui i dati necessari erano ancora presenti nello stato desiderato.

Più precisamente riesci a specificare cosa è necessario durante un ripristino e a quale periodo risalgono i dati, più mirata sarà la selezione del punto di backup appropriato.

Ultimo aggiornamento 30 agosto 2026
Questo articolo è stato utile?
Consenso ai cookie con Real Cookie Banner