Come proteggere i backup dell'hosting senza lacune

Pubblicato il 31 luglio 2026

Un backup è utile solo se è ancora lì, ancora leggibile e ancora inaccessibile alla persona o al processo che ha causato il problema originale. Questa è la risposta pratica a come proteggere i backup dell'hosting: separarli dalla produzione, crittografarli, limitare l'accesso e dimostrare che possono essere ripristinati prima che un incidente non ti lasci tempo per la teoria.

Un'esportazione notturna del database archiviata sullo stesso VPS è meglio di niente, ma non è un piano di ripristino per ransomware, un account root compromesso, uno storage guasto o un'eliminazione accidentale del server. Se produzione e backup condividono le stesse credenziali, lo stesso host e gli stessi punti deboli, possono sparire insieme. Molto efficiente, ma non nel senso buono.

Inizia da una progettazione del ripristino, non da una casella di spunta per il backup

Per prima cosa, identifica ciò che deve essere ripristinabile. Per il sito web di una piccola impresa, può trattarsi dei file del sito, di un database, della configurazione email, dei record DNS e delle impostazioni relative a SSL. Per un negozio e-commerce o un'applicazione SaaS, includi object storage, configurazione relativa ai pagamenti, job in coda, segreti dell'applicazione, definizioni dell'infrastruttura e qualsiasi dato di servizio esterno che non possa essere ricostruito rapidamente.

Poi definisci due obiettivi operativi. Il tuo recovery point objective, o RPO, indica quanti dati recenti puoi permetterti di perdere. Se un negozio non può perdere più di un'ora di ordini, un backup del database una volta al giorno non è sufficiente. Il tuo recovery time objective, o RTO, indica per quanto tempo il servizio può rimanere non disponibile durante il ripristino. Questi numeri determinano la frequenza dei backup, la conservazione, la scelta dello storage e se hai bisogno di un'infrastruttura standby.

La nota regola del 3-2-1 rimane una base sensata: conserva tre copie dei dati, su due diversi tipi di storage, con una copia conservata offsite. Per i carichi di lavoro a rischio più elevato, usa l'approccio 3-2-1-1-0. Quello extra è una copia immutabile o offline, e zero significa zero errori di backup non verificati dopo test regolari.

Questo non significa che ogni azienda abbia bisogno di una grande piattaforma di backup enterprise. Un sito WordPress gestito e una piattaforma SaaS multi-node hanno esigenze diverse. Significa però che ogni carico di lavoro ha bisogno di una progettazione del ripristino che corrisponda al costo del downtime.

Come proteggere i backup dell'hosting con la separazione

La debolezza più comune dei backup è collocare le copie troppo vicino alla produzione. Una directory di backup montata all'interno dello stesso server è comoda, ma la comodità non è isolamento. Un guasto del disco, un comando distruttivo o un account amministratore compromesso possono influire su entrambe le posizioni.

Conserva almeno una copia di backup in un account, sistema di storage o ambiente del provider separato. Idealmente, la destinazione del backup usa credenziali diverse da quelle del server di produzione. Non consentire all'applicazione web, all'utente di deployment o al normale processo del server di eliminare i backup storici, a meno che non vi sia una ragione specifica e controllata.

Per VPS e ambienti con server dedicati, separa anche i livelli. Uno snapshot a livello di provider può aiutare a ripristinare una macchina completa dopo un guasto del sistema operativo. I backup application-aware proteggono database e file in uno stato coerente. Spesso servono entrambi. Uno snapshot grezzo del disco può acquisire un database mentre sta scrivendo dati, il che può complicare il ripristino. Dump del database, backup del transaction log o snapshot nativi del database forniscono un punto di ripristino più pulito.

Le copie offsite non dovrebbero essere montate in modo permanente come unità scrivibile sul server di produzione. Se il ransomware raggiunge un server e può esplorare la destinazione del backup come normale storage, potrebbe crittografare i backup prima che qualcuno se ne accorga. Usa invece un trasferimento pianificato con credenziali dall'ambito strettamente limitato. Al server dovrebbe essere consentito scrivere un nuovo oggetto di backup, non ispezionare e rimuovere l'intero archivio.

Crittografa i dati e proteggi le chiavi separatamente

La crittografia dovrebbe coprire i dati in transito e a riposo. I trasferimenti tra il server e lo storage di backup dovrebbero usare un trasporto sicuro come SFTP, strumenti basati su SSH o una connessione API crittografata. Gli archivi di backup dovrebbero anche essere crittografati prima o durante la conservazione, soprattutto quando contengono record dei clienti, password, documenti privati o contenuti del database.

La chiave di crittografia merita almeno la stessa attenzione del backup stesso. Se l'unica copia di una chiave è conservata sul server che deve essere ripristinato, l'archivio crittografato diventa una scatola molto sicura senza maniglia. Conserva le chiavi di ripristino in un gestore di password protetto, in un servizio dedicato di gestione delle chiavi o in un'altra posizione controllata separata dalla produzione.

Usa credenziali forti e uniche per lo storage di backup e abilita l'autenticazione a più fattori per l'account amministrativo. Dove supportato, crea un account di servizio specificamente per i job di backup. Dovrebbe avere solo le autorizzazioni necessarie per scrivere e verificare i backup. Non dovrebbe avere ampi diritti di amministrazione dell'account.

Per i team, evita password root condivise e accessi condivisi allo storage. Assegna a ogni amministratore un account nominativo, quindi rimuovi immediatamente l'accesso quando cambiano le responsabilità. Anche i log ora raccontano la stessa storia: una chiara titolarità rende le revisioni di sicurezza e la risposta agli incidenti molto meno dolorose.

Rendi i backup difficili da modificare o eliminare

La crittografia protegge la riservatezza. L'immutabilità protegge la cronologia.

Un backup immutabile non può essere modificato o eliminato finché non scade un periodo di conservazione. Questo è particolarmente prezioso contro il ransomware e contro un attaccante che abbia ottenuto credenziali privilegiate. Molte piattaforme di storage offrono object lock, conservazione write-once o controlli di versioning. Configura queste opzioni con attenzione, perché una policy di conservazione troppo lunga può creare costi inutili e rendere più difficili da gestire gli obblighi di eliminazione dei dati.

Imposta la conservazione in base alla realtà aziendale. Per molti siti, un modello ragionevole prevede backup frequenti a breve termine per un ripristino rapido, copie giornaliere per diverse settimane, copie mensili per esigenze storiche più lunghe e una copia immutabile separata per i carichi di lavoro critici. La pianificazione esatta dipende dal tasso di variazione dei dati, dai requisiti legali e dal budget di storage disponibile.

Non conservare per impostazione predefinita ogni backup per sempre. La conservazione fa parte della sicurezza. I backup vecchi possono contenere dati di ex clienti, file di applicazioni vulnerabili o credenziali che non dovrebbero più esistere. Definisci i periodi di conservazione, automatizza la scadenza dove possibile e documenta qualsiasi eccezione di conformità.

Il versioning è utile ma non è identico all'immutabilità. Il versioning può conservare oggetti precedenti dopo una sovrascrittura accidentale. Un attaccante con autorizzazioni sufficienti potrebbe comunque essere in grado di rimuovere quelle versioni. Controlla il comportamento della protezione dall'eliminazione invece di presumere che la parola "versioned" risolva il problema.

Verifica i ripristini, non solo i job di backup

Uno stato di backup verde conferma solo che un job è stato completato. Non conferma che l'archivio contenga i file corretti, che il database sia coerente, che la chiave funzioni o che l'applicazione si avvierà dopo il ripristino.

Pianifica test di ripristino. Per un sito vetrina, può essere sufficiente un ripristino mensile in un ambiente di test isolato. Per negozi attivi, agenzie che gestiscono siti dei clienti e operatori SaaS, esegui test più spesso e includi una sequenza di ripristino realistica: ripristina i dati, applica la configurazione, ruota le credenziali esposte se necessario, porta i servizi online e convalida le transazioni principali.

Un test utile non consiste semplicemente nell'estrarre un file ZIP. Ripristina un database ed esegui un controllo dell'applicazione. Conferma che gli utenti possano accedere, che esista un ordine o record recente, che le attività pianificate vengano eseguite e che i file caricati corrispondano alle aspettative. Registra quanto tempo ha richiesto il processo. Quel numero è il tuo RTO effettivo, non quello ottimistico scritto in un documento di policy.

Anche i controlli di integrità automatizzati aiutano. Genera checksum per gli archivi di backup e verificali dopo il trasferimento. Monitora job non riusciti, backup insolitamente piccoli, capacità di storage e pianificazioni mancate. Un backup che improvvisamente si riduce da 30 GB a 200 MB può avere successo dal punto di vista tecnico pur essendo operativamente inutile.

Proteggi i sistemi che eseguono il backup

Il software di backup, i pannelli di controllo e i sistemi operativi necessitano di patch perché dispongono di accessi potenti. Mantieni aggiornati l'agente di backup e le sue dipendenze, ma prepara le principali versioni in anticipo se il carico di lavoro è sensibile. Un aggiornamento non riuscito dello strumento di backup durante un intenso periodo di vendite non è cinema drammatico, ma resta comunque un brutto martedì.

Proteggi il server con account a privilegi minimi, chiavi SSH invece dell'accesso con password dove pratico, regole firewall e accesso amministrativo monitorato. Limita l'amministrazione del backup a reti fidate o all'accesso VPN quando possibile. Esamina gli audit log per tentativi di accesso non riusciti, modifiche alla conservazione, job disabilitati ed eliminazioni impreviste.

Anche la configurazione ha bisogno di backup. Conserva pianificazioni dei backup, script, impostazioni di conservazione e runbook di ripristino in una posizione controllata. Se l'ingegnere che ha costruito il sistema non è disponibile, un'altra persona autorizzata dovrebbe essere in grado di capire dove si trovano le copie, chi può accedervi e come ripristinarle senza andare a tentativi.

Per i clienti che usano infrastruttura gestita, fai una domanda diretta: che cosa viene sottoposto esattamente a backup, con quale frequenza, dove viene conservato e chi esegue il ripristino? Un servizio di backup gestito può ridurre il lavoro operativo, ma le responsabilità dovrebbero comunque essere chiare. In kodu.cloud, l'obiettivo pratico è semplice: assicurarsi che il percorso di ripristino sia noto prima che serva, non assemblato mentre il servizio è già inattivo.

Mantieni un piccolo runbook di ripristino

Il tuo runbook può essere breve, ma dovrebbe essere specifico. Includi la posizione delle copie di backup, l'attuale pianificazione della conservazione, la posizione della chiave di ripristino, l'ordine del ripristino, i contatti chiave e i passaggi di convalida. Tieni i segreti sensibili fuori dal documento stesso e fai invece riferimento alla posizione sicura approvata.

Rivedi il runbook dopo le modifiche all'infrastruttura. Un passaggio a un nuovo VPS, a una versione del database, a un provider di storage o a un processo di deployment può invalidare silenziosamente una vecchia procedura di ripristino. Non è il lavoro di documentazione più bello, ma di solito è la differenza tra un ripristino controllato e una lunga serata passata a cercare tra vecchi messaggi.

Proteggere i backup dell'hosting non significa accumulare più copie di quante chiunque possa gestire. Significa mantenere punti di ripristino indipendenti, crittografati, monitorati e testati che funzionino sotto pressione. Costruisci ora questa disciplina, e i tuoi server potranno tornare a essere tranquilli anche quando una parte dello stack non lo è.

Andres Saar Customer Care Engineer