Kopie zapasowe hostingu. Dwie warstwy, każdej nocy.

1. Un backup che funziona già prima ancora che ti serva.

Una copia di backup è utile solo se esiste al momento del guasto, non quando qualcuno ha promesso che ci sarà. Su Saplo, il backup di Box è un'istantanea dell'intero container LXC eseguita automaticamente ogni notte alle 4:00, senza alcun intervento da parte tua. Quindi non devi ricordarti di esportare manualmente il database prima di ogni aggiornamento rischioso.

La conservazione, cioè il numero di giorni per cui viene mantenuta la copia, aumenta con il piano: Box L prevede 7 giorni, Box XL 14 e Box XXL 30, più una copia offsite aggiuntiva realizzata ogni notte alle 1:00 da un meccanismo separato (borg) verso una località remota a Helsinki, indipendentemente dall'istantanea locale sullo stesso server.

Box S e Box M non includono il backup nel prezzo, perché sono piani base per progetti nei quali il costo del backup dovrebbe far aumentare il prezzo dell'intero piano per tutti i clienti, anche per quelli che non ne hanno bisogno, come un sito di test o un portfolio senza dati variabili.

2. Due livelli di backup, non uno

L'istantanea LXC locale (backup_limit in giorni) protegge dallo scenario più comune: un errore durante l'aggiornamento, un plugin corrotto o la cancellazione accidentale dei dati da parte del cliente stesso. Il ripristino di un'istantanea del genere è rapido, perché avviene sullo stesso server fisico, senza trasferire dati via rete.

La copia offsite, disponibile da Box XXL, protegge da uno scenario molto più raro, ma più grave: il guasto dell'intero server fisico o del centro dati. La copia a Helsinki è fisicamente separata dal server di produzione a Falkenstein, quindi anche la perdita totale del server non comporta la perdita dei dati del cliente.

La distinzione tra questi due livelli è importante nella scelta del piano: se il progetto è critico per l'azienda, ad esempio un negozio con transazioni reali o un'app SaaS con clienti paganti, valuta un piano con backup offsite, non soltanto un'istantanea locale.

3. Backup offerti dalla concorrenza: cosa è incluso e cosa va acquistato separatamente

Competitor A, sui piani VPS di tipo root, offre un backup fino a 28 giorni, ma il ripristino viene eseguito su richiesta ed è a pagamento, perché il cliente amministra autonomamente il server e il backup viene trattato come servizio aggiuntivo, non come processo completamente automatizzato (listini pubblici, descrizione del piano del competitor, dati al 2026-10-10).

Nei piani Windows VPS dello stesso fornitore, il backup completo del server viene trasferito ogni giorno su un server esterno, con una conservazione da 7 a 28 giorni a seconda del piano scelto e delle funzioni aggiuntive (listini pubblici, dati al 2026-10-10). Il modello è simile a quello di Saplo, ma richiede la scelta di un piano VPS adeguato e più costoso.

Presso molti fornitori di hosting condiviso il backup è disponibile, ma il ripristino è spesso a pagamento oppure limitato a un numero prestabilito di ripristini al mese. In pratica, il backup protegge dalla perdita di dati, ma non è sempre gratuito proprio quando ti serve davvero.

Nei piani Saplo che includono il backup (Box L, Box XL e Box XXL), il ripristino da snapshot non comporta alcun costo aggiuntivo, perché fa parte dello stesso meccanismo automatico e non richiede un intervento di supporto a pagamento.

4. Per chi è adatto

Per un progetto di test o un portfolio senza dati dinamici, il backup non è cruciale: in caso di problemi basta ripristinare il sito dal codice o dal repository Git.

Per un negozio, un CRM o un'applicazione con dati reali dei clienti, il backup non è più un'opzione, ma diventa un requisito: perdere gli ordini o i contatti comporta un costo diretto per l'azienda, non solo un disagio.

Per i progetti critici, come SaaS con clienti a pagamento o sistemi finanziari, valuta Box XXL con una copia off-site: uno snapshot locale sullo stesso server non protegge dal guasto del server fisico.

5. Come funziona in pratica il ripristino da una copia di backup?

Il ripristino da uno snapshot locale avviene tramite il pannello Saplo: selezioni la data della copia e confermi il ripristino. Nel caso tipico non devi contattare il supporto, perché il ripristino fa parte del meccanismo di backup automatizzato.

Poiché lo snapshot include l'intero container, il ripristino coinvolge tutto in una sola operazione: file, database e configurazione dell'applicazione. È più semplice che ripristinare manualmente database e file separatamente, da due fonti diverse.

Il ripristino da una copia off-site (Box XXL) conservata a Helsinki è più lento di quello da uno snapshot locale, perché richiede il trasferimento dei dati via rete. È però l'unica soluzione in caso di guasto totale del server di produzione.

Conviene testare il processo di ripristino prima di averne bisogno, ad esempio su una copia di test dell'applicazione, per sapere quanto tempo richiede e cosa aspettarsi, invece di impararlo durante un guasto reale.

La cronologia dei backup è visibile nel pannello con le date di esecuzione, così puoi scegliere il giorno specifico da ripristinare, per esempio il giorno precedente a un aggiornamento errato di un plugin che ha compromesso il sito.

6. Backup, GDPR e dati personali dei clienti

Il backup del database con dati personali dei clienti (ad esempio gli ordini dello store o i contatti CRM) è soggetto alle stesse regole GDPR previste per i dati in produzione. È quindi utile sapere dove si trova fisicamente la copia e per quanto tempo viene conservata.

La conservazione dei backup per 7, 14 o 30 giorni, a seconda del piano, implica che i dati eliminati dal cliente dall'ambiente di produzione possano rimanere nella copia per l'intero periodo. Questo aspetto conta quando si esercita il diritto alla cancellazione.

La copia off-site conservata a Helsinki si trova fisicamente in una sede separata dal server di produzione a Falkenstein. Questo aspetto va tenuto in considerazione quando valuti dove sono realmente conservati i dati personali dei clienti inclusi nei backup.

Per le aziende che trattano dati personali su larga scala, come negozi, CRM e sistemi medici, un piano superiore con un periodo di conservazione più lungo e una copia off-site offre una protezione migliore contro la perdita di dati. Devi però essere consapevole di dove si trovano fisicamente queste copie.

7. Scenari di guasto e ciò che il backup protegge davvero

Il caso più comune contro cui il backup ti protegge è l'errore umano: la cancellazione accidentale del sito, un aggiornamento non riuscito di un plugin che ha danneggiato il database o una modifica al codice dell'applicazione pubblicata in produzione senza test.

Il secondo scenario è un attacco: un sito violato con codice malevolo iniettato. Ripristinare da una copia precedente all'infezione è di solito più rapido che pulire manualmente ogni file e ogni record del database alla ricerca del codice malevolo.

Il terzo scenario, il più raro ma anche il più grave, è il guasto del server fisico o del data center. Solo una copia off-site, fisicamente separata dal server di produzione, protegge da questo evento, perché uno snapshot locale sullo stesso disco non sopravvive al guasto del disco.

Per la maggior parte dei piccoli progetti, i primi due scenari sono molto più probabili del terzo. Perciò uno snapshot locale (Box L, Box XL) offre una protezione concreta a un prezzo ragionevole, mentre una copia off-site (Box XXL) ha senso solo per progetti in cui anche il guasto, raro ma catastrofico, di un server è inaccettabile.

Vale la pena ricordare che il backup non protegge dagli errori commerciali, come un prezzo sbagliato in uno store o un contenuto errato inviato ai clienti tramite un'automazione, perché il backup copia fedelmente questi dati insieme al resto, senza distinguere l'errore dallo stato corretto.

Controllare regolarmente, anche solo di sfuggita, che il backup venga effettivamente eseguito, ad esempio tramite la data dell'ultima copia visibile nel pannello, è un semplice passo che intercetta un problema del meccanismo prima che diventi evidente nel momento peggiore, proprio quando il backup serve di più.

8. Come Saplo comunica lo stato del backup al cliente

La trasparenza sul meccanismo di backup è importante quanto l'esistenza stessa del backup: dovresti poter controllare in qualsiasi momento quando è stata eseguita l'ultima copia, senza dover chiedere al supporto lo stato del backup della tua applicazione.

Il pannello Saplo mostra la cronologia dei backup eseguiti con le relative date, così puoi verificare autonomamente che il meccanismo funzioni correttamente, invece di fidarti soltanto della dichiarazione nel regolamento secondo cui il backup viene eseguito regolarmente ogni notte.

In caso di problemi al meccanismo di backup, per esempio se uno snapshot non è stato creato durante una notte a causa di un guasto tecnico, il team Saplo comunica l'accaduto. È coerente con il principio che le prove valgono più delle rassicurazioni sul corretto funzionamento.

Per i progetti critici per l'azienda, come negozi o applicazioni con clienti a pagamento, controllare regolarmente e manualmente lo stato del backup nel pannello, almeno una volta al mese, è una buona pratica, indipendentemente da quanto bene funzioni il meccanismo automatico nel quotidiano.

Un'informazione chiara su quali piani includono il backup e quali richiedono un servizio aggiuntivo ti consente di scegliere Box in modo consapevole, senza scoprire l'assenza del backup solo quando ormai ti serve.

9. Il backup come parte della valutazione del rischio del progetto, non un extra da aggiungere in seguito

Quando pianifichi un nuovo progetto, valuta subito quanto sarebbe costosa la perdita di dati in quel momento dello sviluppo. Per un sito in costruzione il costo è basso, perché codice e contenuti si possono ripristinare dal repository. Per un negozio con ordini reali, invece, perdere anche un solo giorno di dati può comportare una perdita finanziaria significativa.

Questa valutazione dovrebbe influenzare la scelta del piano Box fin dall'inizio, senza essere rimandata al momento in cui il progetto ha già un valore aziendale concreto. In quel caso, infatti, la migrazione a un piano con backup richiederebbe un ulteriore passaggio amministrativo, seppur semplice, anziché far parte fin da subito della scelta iniziale.

Per i progetti che crescono per fasi (partono da una semplice pagina e aggiungono poi un negozio o un sistema di prenotazioni), il momento naturale per valutare il backup è proprio quello in cui l'applicazione inizia a conservare dati la cui perdita avrebbe un impatto reale, non il solo contenuto estetico del sito.

Vale anche la pena confrontare il costo del backup incluso in un piano Box superiore con quello della creazione manuale di copie proprie (esportazione del database, archiviazione dei file). La gestione manuale, sebbene tecnicamente possibile su qualsiasi piano, richiede costanza e disciplina, un onere che il meccanismo automatico di backup elimina completamente.

La decisione finale sulla necessità del backup dovrebbe sempre basarsi su una valutazione realistica del valore dei dati conservati nell'applicazione, non sul prezzo dell'opzione aggiuntiva o del piano superiore. Il vero fattore di rischio è infatti il valore dei dati che andrebbero persi, non il costo del backup.

10. Sintesi: il backup è una scelta consapevole, non un caso

La scelta di un piano con backup incluso (Box L e superiori) o l'acquisto del backup come opzione aggiuntiva a un piano di base dovrebbe derivare da una valutazione consapevole del valore dei dati conservati in una determinata applicazione, non deve dipendere dal caso né dall'ignoranza di quali piani includano il backup e quali no. Per un progetto di test o un portfolio, il rischio è limitato; per un negozio, un CRM o un'applicazione con clienti paganti, il backup non è più un'opzione, ma diventa parte della responsabilità fondamentale verso l'attività, proprio come un'assicurazione o altre forme standard di protezione dal rischio operativo. Il costo di un piano adeguato con backup incluso è di solito modesto rispetto al costo di un solo giorno di dati transazionali persi, il che rende questa decisione una delle più facili da giustificare nel budget di qualsiasi progetto online gestito con serietà.