Un VPS ti dà il controllo totale del server, il che significa che i backup sono anche un tuo compito. Ecco cosa salvare, come si applica la regola 3-2-1 su un VPS, come automatizzare la pianificazione e perché un test di ripristino è l'unica vera prova.
Un backup VPS è una copia dei dati del tuo server conservata in un punto che il server stesso non può raggiungere, cosicché, quando il server si guasta, viene eliminato per errore o viene cifrato da un ransomware, puoi riportare gli stessi dati su una macchina nuova. Sull'hosting condiviso è il fornitore a prendere queste copie per te; su un VPS controlli l'intero stack, quindi la responsabilità dei backup e del ripristino passa a te. Lo standard pratico è la regola 3-2-1 — tre copie dei dati, su due tipi di archiviazione diversi, con una copia fuori sede — e l'unica prova che qualcosa funzioni è un ripristino che hai eseguito davvero.
Sull'hosting condiviso il fornitore fa istantanee dell'intera macchina e tu apri un ticket quando qualcosa si rompe. Il VPS rimuove quel soffitto: scegli tu il sistema operativo, il database, il firewall e la cadenza degli aggiornamenti, ed è proprio questo il punto di averne uno — ma significa anche che nessuno prende una copia per te. Il fornitore protegge ancora l'hardware e un fornitore serio sopravvive a un disco guasto senza che tu te ne accorga, ma questo copre solo lo strato fisico. Non copre l'operatore che installa un aggiornamento e rompe il database, lo script che sovrascrive la cartella sbagliata, l'attaccante che cifra tutto e chiede un riscatto, o l'account del fornitore compromesso da cui un intero progetto sparisce. Questi quattro scenari hanno un tratto in comune: sono invisibili al datacenter e finiscono tutti allo stesso modo a meno che non esista una copia da qualche altra parte.
La regola è tre copie dei dati, su due supporti diversi, una fuori sede, ed è sopravvissuta perché è semplice e copre ogni singolo punto di guasto. Su un VPS si mappa direttamente sull'infrastruttura che hai già. La prima copia è il server in produzione stesso. La seconda è una copia su un'archiviazione diversa nello stesso progetto — un'istantanea di volume scollegata, un dump del database scritto in un bucket di object storage, o un servizio di backup dallo stesso fornitore ma su dischi separati. La terza è la copia fuori sede, e "fuori sede" deve significare un dominio di guasto completamente diverso: un altro fornitore, un altro datacenter, o un account di object storage in una regione separata. Due supporti contano perché un intero array di archiviazione può guastarsi; una sede separata conta perché un intero account o fornitore può guastarsi. Due numeri decidono la forma di tutta l'installazione: il tuo recovery point objective, la quantità di dati che puoi permetterti di perdere, misurata nel tempo, e il tuo recovery time objective, quanto l'azienda può sopravvivere senza il servizio. Rispondi prima a queste due domande e ogni decisione di backup successiva si prende da sola.
Non tutto su un server ha bisogno di una copia, e trattare tutto allo stesso modo è il motivo per cui i budget dei backup esplodono. I database vengono per primi, perché contengono il lavoro: fai un dump logico ogni notte con pg_dump o mysqldump — un singolo file compresso che si ripristina ovunque — e per i database più grandi aggiungi un recupero continuo point-in-time, così un'importazione sbagliata si può annullare all'ora invece che fino a mezzanotte del giorno prima. Il codice dell'applicazione non ha bisogno di backup, perché il repository è il backup; fare il deploy da git significa che ricostruire l'applicazione è un singolo comando. Quello che va coperto è tutto ciò che il repository non può ricreare: i file caricati e i media degli utenti, i file d'ambiente con i segreti e le chiavi di terze parti, la configurazione di nginx e dei servizi, i job cron e lo script di backup stesso. Anche i certificati e i record DNS sono in lista, perché un dominio i cui record vanno persi può richiedere giorni per essere ricostruito. Tieni i segreti cifrati a riposo ovunque siano conservati — il backup di un file .env in un bucket pubblico è una violazione dei dati che aspetta solo di essere trovata.
Un backup che dipende da qualcuno che se ne ricorda verrà dimenticato proprio il giorno in cui conta. Automatizzalo e rendi l'automazione onesta: lancia il job da cron o systemd con una cadenza fissa, fai sì che ogni passo scriva su un log e, cosa più importante, che lo script esca con un codice non zero quando un passo fallisce; poi invia quel codice dove un essere umano lo legge — un'email, un canale di chat, un sistema di monitoraggio. Un job di backup che per sei mesi ha prodotto silenziosamente un file vuoto è il resoconto di un incidente classico, e il codice di uscita è la guardia economica contro tutto ciò. Aggiungi controlli di integrità: verifica che il dump non sia vuoto, controlla il checksum dell'archivio e conferma che la copia fuori sede sia davvero arrivata leggendo il listato del bucket invece di fidarti del comando di caricamento. Poi imposta la conservazione in modo deliberato invece di tenere tutto per sempre — un ciclo nonno di copie quotidiane per una settimana, settimanali per un mese e mensili per un anno copre ogni necessità realistica a una frazione del costo di archiviazione, e costringe i dati vecchi a uscire di scena invece di accumularsi fino a raddoppiare il budget in silenzio.
Un backup è una teoria finché non viene ripristinato. Una volta per trimestre scegli una copia recente, provisioninga un server monouso della stessa dimensione e ripristina l'intero stack da zero: l'applicazione, la configurazione, il database, i file caricati. Cronometra l'esercizio, perché un backup che richiede nove ore per il ripristino è una proposta diversa da uno che ne richiede venti minuti, e il divario si vede solo quando lo misuri. Poi confronta record reali con i dati ripristinati — un totale, un conteggio di righe, una transazione recente — perché un ripristino che va a buon fine senza la settimana scorsa non è un successo. A esercizio finito, scrivi cosa è successo in un runbook che vive fuori dal server: i comandi in ordine, la fonte delle credenziali, i record DNS da scambiare e chi fa ogni passo. Un runbook conservato sulla macchina che deve salvare è inutile proprio quando serve, e un ingegnere calmo con un runbook testato recupera in un'ora ciò che un ingegnere nel panico riscopre in una giornata.
Backup automatici giornalieri sono il minimo per un sito aziendale, con dump del database più frequenti se i dati cambiano costantemente — ogni poche ore, o un recupero continuo point-in-time se perdere un'intera mattinata di transazioni sarebbe doloroso. L'intervallo giusto è fissato dal tuo recovery point objective: la risposta a "quanto nuovo lavoro possiamo permetterci di perdere?" misurata in ore, non da una regola generale.
I backup del fornitore sono un primo strato utile e su una piattaforma seria sono affidabili, ma non sono un piano di disaster recovery. Vivono di solito nello stesso account e nello stesso dominio di guasto del server, spesso sono un costo extra che viene tagliato quando i budget si stringono, e se l'account del fornitore viene compromesso server e backup spariscono insieme. Tieni il backup del fornitore e aggiungi una copia che controlli al di fuori di quell'account — questa è la copia fuori sede che la regola 3-2-1 esiste per imporre.
Li ripristini. Un job di backup che segnala successo prova solo che lo script è girato e che un file è stato scritto; non dice nulla sul fatto che il file sia completo, integro o ripristinabile. L'unico test affidabile è un esercizio di ripristino in un ambiente monouso — provisioninga un server nuovo, ricostruisci lo stack dal backup e confronta dati reali con l'originale. Fallo almeno una volta per trimestre e cronometralo, perché un ripristino che funziona ma impiega un'intera giornata cambia i tuoi piani di recupero.
Server VPS consegnati con una storia di recupero che funziona — backup giornalieri del database, copie fuori sede e ripristini testati come parte del servizio gestito.
La metà prevenzione di questa guida — chiavi SSH, firewall, aggiornamenti automatici e TLS, perché meno incidenti arrivino al backup.
Dove sta il tuo server decide la latenza e il suo dominio di guasto — la stessa domanda da farsi prima di collocare una copia fuori sede.
EGYmass si occupa di hosting, sicurezza e gestione continuativa - così tu puoi concentrarti sul tuo prodotto.
Consulenza gratuita