Un backup che usi davvero
La maggior parte delle aziende scopre che il proprio backup non funziona solo quando arriva il disastro. Per questo consigliamo di trattare il backup come un processo, non come una casella da spuntare: copie automatiche, conservate lontano dal server di produzione, e ripristini testati con regolarità. Su cPanel il backup giornaliero parte in automatico e lo ripristini dal pannello; su VPS e server dedicati il team DevOps può impostare test di ripristino programmati con le tue ore incluse.
Quale backup include ogni piano
L'hosting cPanel ha un backup giornaliero automatico che ripristini dal pannello. Un VPS ha gli snapshot, copie complete dello stato del server, senza una frequenza garantita. I server dedicati non includono alcun backup per impostazione predefinita: i dischi NVMe sono in coppia e il RAID viene configurato all'installazione, ma il RAID non è un backup. Backup esterno, PITR per i database e test di ripristino sono impostati dal nostro team con le ore DevOps incluse (5-10 h/mese sui dedicati).
| Piano | Backup | Ripristino | Ubicazione |
|---|---|---|---|
| Hosting cPanel | Backup giornaliero automatico | Dal pannello cliente | UE (Francoforte) |
| VPS | Snapshot, senza frequenza garantita | Da uno snapshot | UE (Francoforte) |
| VPS: backup esterno | Su richiesta, con le ore DevOps | In base alla strategia configurata | Concordata con il team |
| Server dedicato | Non incluso per impostazione predefinita: configurato su richiesta | In base alla strategia (3-2-1, PITR) | UE (Francoforte) + storage esterno su richiesta |
RPO e RTO: i valori che devi fissare tu
Invece di «backup il prima possibile», conviene fissare due valori concreti. L'RPO (Recovery Point Objective) indica quanti dati puoi permetterti di perdere. L'RTO (Recovery Time Objective) indica quanto può durare un ripristino. Il team costruisce la strategia attorno a questi valori.
La perdita massima di dati che puoi accettare. Un backup giornaliero significa fino a un giorno perso; con lo streaming dei WAL un database scende sotto il minuto, configurato su richiesta.
Il tempo di ripristino dipende dal volume di dati e dalla strategia scelta. Non garantiamo un RTO: l'unico valore affidabile è quello misurato in un test di ripristino.
Scenari di disastro e come proteggersi
I disastri sono rari ma ad alto impatto. Ecco gli scenari più comuni e la protezione che consigliamo per ciascuno. Su VPS e server dedicati il team imposta queste misure con le ore DevOps incluse.
Guasto hardware (disco, RAM)
La causa più frequente di perdita di dati. I server dedicati hanno dischi NVMe in coppia con RAID configurato all'installazione, più RAM ECC sulle fasce EPYC e Xeon. Il RAID mantiene il server attivo quando un disco si guasta, ma non sostituisce il backup: serve comunque una copia esterna.
Protezione: RAID + backup esternoRansomware o compromissione dell'account
L'attaccante cifra i file del server e ogni copia che il server può raggiungere. Per questo almeno una copia dovrebbe stare fuori dal server, dove l'account di produzione non può modificarla (immutabile oppure offline). La configuriamo su richiesta, con le ore DevOps.
Protezione: copia isolataCancellazione accidentale dei dati
«DROP TABLE users» eseguito in produzione. L'errore umano più comune. Se il database ha il point-in-time recovery (PITR) configurato, torni a un istante appena prima dell'errore; un backup giornaliero ti riporta soltanto all'ultima copia.
Protezione: PITR su richiestaInterruzione totale del DC
Incendio, alluvione, lunga interruzione dell'operatore. La protezione è una copia in un'altra sede, ad esempio un secondo DC. Replica e failover non sono inclusi per impostazione predefinita; il team li configura su richiesta, con le ore DevOps.
Protezione: copia in un'altra sedeUn bug dell'app corrompe i dati
Un deploy introduce un bug che corrompe i record del database. Con un backup separato del database ripristini solo il DB (non l'intero server): i file dell'app restano, i dati tornano indietro.
Protezione: backup separato del DBMigrazione a un altro server
Il piano attuale non basta più. Un VPS passa a una fascia superiore con più vCPU, RAM e disco; per il passaggio a un altro server pianifichiamo la migrazione in anticipo per contenere il downtime.
Consiglio: pianifica presto la migrazioneBackup dei database: strategie per ogni motore
Un backup completo del VPS non sempre basta. I database hanno propri meccanismi di point-in-time recovery (PITR): permettono di tornare esattamente al momento scelto, non solo all'ultimo snapshot. Li configuriamo su richiesta, con le ore DevOps incluse.
Cosa è incluso e cosa si configura su richiesta
Non esiste un «backup premium» venduto a parte: ciò che è incluso è indicato su ogni piano, e tutto il resto lo costruisce il team con le ore DevOps del tuo abbonamento. Le ore oltre la quota vengono fatturate a parte, a ore.
- cPanel: backup giornaliero automatico, ripristino dal pannello: incluso
- VPS: snapshot, senza frequenza garantita: incluso
- Server dedicati: dischi NVMe in coppia, RAID configurato all'installazione: backup non incluso per impostazione predefinita
- Backup esterno secondo la regola 3-2-1: su richiesta, con le ore DevOps (5-10 h/mese sui dedicati)
- PITR per i database (WAL, binlog, oplog): su richiesta, con le ore DevOps
- Test di ripristino e periodo di conservazione: concordati con il team e configurati con le ore DevOps
Ripristinare un backup in 4 passaggi
Apri il pannello
Accedi al pannello cliente. Su cPanel ripristini lì il backup giornaliero; su VPS scegli uno snapshot.
Scegli un punto nel tempo
Scegli la copia precedente al problema. L'ultima non è sempre quella giusta, se l'errore è presente da un po'.
Clicca su «Ripristina»
Un ripristino sovrascrive lo stato attuale. Se hai dubbi, chiedi al team di ripristinare prima su un ambiente separato, così da poter confrontare.
Controlla il risultato
Verifica che l'applicazione funzioni e che i dati siano al loro posto. La durata del ripristino dipende dal volume di dati.
Domande frequenti
Per fare uno snapshot bisogna fermare il server?
Di solito no: lo snapshot di un VPS viene eseguito a server acceso. Per un database, però, lo snapshot di un server in funzione non è sempre coerente, quindi consigliamo un backup separato del database (dump o WAL/binlog), che il team configura su richiesta.
Quanto tempo richiede il ripristino di uno snapshot molto grande (ad es. 500 GB)?
Dipende dal volume di dati, dal disco e da dove è conservata la copia: ripristinare da una copia esterna richiede più tempo che da una locale. Non promettiamo un tempo fisso: il valore realistico emerge da un test di ripristino, che possiamo eseguire insieme a te.
I backup sono cifrati?
La cifratura dei backup esterni fa parte della strategia che configuriamo su richiesta: ad esempio copie che lasciano il server solo in forma cifrata, con chiavi tenute separate dalla produzione. Indica i tuoi requisiti al team quando richiedi la configurazione.
E se voglio una conservazione superiore a 30 giorni?
La conservazione dei backup esterni viene definita quando il team configura la strategia, in base alle tue esigenze e ai tuoi obblighi legali di archiviazione. Lo storage per una conservazione più lunga si concorda con il team; i piani li trovi nella pagina dei prezzi.
Posso scaricare uno snapshot in locale?
Su VPS e server dedicati hai accesso root e copi i tuoi dati con gli strumenti che preferisci (rsync, tar). Il team può anche configurare copie automatiche su storage esterno con le ore DevOps, ad esempio AWS S3, Google Cloud Storage o Azure Blob.
I tuoi dati valgono troppo per lasciarli al caso
cPanel include il backup giornaliero e il VPS include gli snapshot. Sui server dedicati il team costruisce la strategia di backup con le ore DevOps incluse. Consulta i prezzi per i dettagli.
Vedi i piani →