Backup del filesystem e dei database di server web

In un progetto di migrazione infrastrutturale per una PMI ho trovato, come "sistema di backup", esattamente ciò che andava di moda quindici anni fa: uno script PHP che a notte fonda comprimeva l'intera webroot e il dump del database in un unico archivio e lo spediva via email a una casella di posta. Sulla carta funzionava. Nella realtà era un disastro che aspettava di accadere: la password di root del database era in chiaro dentro un file di configurazione servito dallo stesso web server, gli archivi non erano cifrati, la casella email aveva un limite di dimensione che il backup aveva superato da mesi senza che nessuno se ne accorgesse, e l'unica copia "offsite" era in una mailbox a cui chiunque avesse compromesso quel server poteva accedere.

Quel caso è il punto di partenza perfetto per spiegare come si fa davvero il backup di un server web nel 2026, perché ogni errore di quello script corrisponde a un principio che oggi è imprescindibile. Il backup di un server web non è un programma da installare, è una strategia, e la prima cosa da capire è che mette insieme due mondi che vanno trattati in modo diverso.

TL;DR

Cosa salvare: i dati generati dagli utenti che non stanno in Git (upload, allegati) e i database. Il codice è già in Git; la configurazione del sistema gestiscila come Infrastructure as Code.
Filesystem: backup deduplicato, incrementale e cifrato con restic o borg, non tar + email.
Database: non copiare i file a caldo; usa un dump consistente (vedi l'articolo dedicato a mysqldump), poi includilo nello stesso flusso cifrato.
Regola d'oro: un backup non testato non è un backup. Prova il ripristino, periodicamente e in un ambiente separato.
Dove: regola 3-2-1, offsite, e almeno una copia immutabile/append-only contro il ransomware.

Cosa bisogna salvare davvero in un backup di server web?

In un backup di server web non vai a salvare "tutto in un colpo": salvi i dati irreversibili che esistono solo lì, cioè i file generati dagli utenti e i database, e tratti queste due categorie in modo diverso. Il codice dell'applicazione di norma non si salva dal server (sta già in Git), e la configurazione di sistema si gestisce come codice anziché copiarla. L'errore concettuale del "backup tutto in un colpo" è proprio non distinguere ciò che si sta salvando: su un server web ci sono almeno tre categorie di dati, con criticità e frequenze diverse.

La prima è il codice dell'applicazione. In un progetto gestito bene, il codice vive in un repository Git, quindi la fonte di verità non è il server: è il repository. Fare un backup del codice dal server è ridondante, perché quel codice si ripristina con un git clone. Se invece il codice esiste solo sul server e da nessun'altra parte, il vero problema non è il backup, è l'assenza di version control, e va risolto prima.

La seconda, e la più critica, sono i dati generati dall'applicazione che non stanno in Git: i file caricati dagli utenti, gli allegati, le immagini di un catalogo, i documenti. Questi esistono solo sul server, cambiano di continuo, e la loro perdita è irreversibile. Sono il vero bersaglio del backup del filesystem.

La terza sono i database, che hanno regole tutte loro e che vanno trattati con strumenti specifici, mai copiando i file a freddo mentre il database scrive.

E ce n'è una quarta che quasi tutti dimenticano: lo stato di configurazione del sistema, cioè la configurazione del web server, i job cron, i certificati, le regole del firewall. Non sono "dati" nel senso comune, ma se il server muore e devi ricostruirlo, sono ciò che fa la differenza fra ripartire in un'ora o in tre giorni. La risposta migliore a questa categoria non è copiarli, ma gestirli come codice (Infrastructure as Code), così che il server sia ricostruibile da una definizione versionata.

Il backup del filesystem, fatto con gli strumenti del 2026

Per i dati del filesystem, lo strumento del 2009 era tar e zip; lo strumento del 2026 è un sistema di backup deduplicato, incrementale e cifrato. I due riferimenti sono restic e BorgBackup, entrambi open source, maturi e progettati esattamente per questo. La differenza rispetto a un archivio compresso è sostanziale: salvano solo i blocchi cambiati dall'ultimo backup (incrementale), non duplicano i dati identici (deduplica), e cifrano tutto a riposo per impostazione predefinita. Questo significa backup veloci, che occupano poco spazio anche conservando molti recovery point, e illeggibili per chiunque non abbia la chiave.

# Inizializzazione di un repository restic cifrato su uno storage remoto (una volta sola)
restic -r sftp:backup@server-backup:/srv/backups/webserver init

# Backup incrementale della directory dei dati utente, escludendo cache e file temporanei
restic -r sftp:backup@server-backup:/srv/backups/webserver backup \
  /var/www/uploads \
  --exclude /var/www/uploads/cache \
  --exclude '*.tmp'

# Applicare una politica di retention e liberare spazio
restic -r sftp:backup@server-backup:/srv/backups/webserver forget \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

Nota cosa fa già di serie questo approccio rispetto allo script del 2009: la cifratura è integrata, quindi i dati personali contenuti nei file caricati, che sotto GDPR vanno protetti, sono al sicuro anche sullo storage di destinazione; la destinazione è una macchina remota separata, non la stessa che stai salvando; e la rotazione con forget mantiene una finestra sensata di recovery point senza far crescere lo spazio all'infinito. La chiave di cifratura, ovviamente, va custodita fuori dal server di produzione, perché un backup cifrato la cui chiave sta sulla stessa macchina compromessa non protegge da nulla.

Se gestisci un server web e ti accorgi che il tuo "backup" assomiglia più a quello che ho trovato io che a questo, è esattamente il tipo di intervento su cui lavoro: nel mio profilo professionale trovi l'esperienza concreta su strategie di backup e disaster recovery testate per infrastrutture in produzione, non semplicemente configurate e dimenticate.

I database: stesso obiettivo, strumenti diversi

I database non si salvano copiando i loro file mentre sono in esecuzione, perché si otterrebbe una copia incoerente, catturata a metà di una scrittura. Vanno esportati con gli strumenti dedicati, che garantiscono uno snapshot consistente senza bloccare la produzione. Per MySQL e MariaDB questo significa un dump logico con le opzioni giuste per la consistenza delle tabelle InnoDB, oppure, oltre una certa scala, un backup fisico con strumenti come Percona XtraBackup, che copia i file InnoDB a caldo senza un lock globale e produce un ripristino molto più rapido del dump logico sui dataset grandi. È un tema con sufficiente profondità da meritare un articolo a sé, e l'ho trattato in dettaglio in quello su come fare il backup di MySQL senza lock sulle tabelle su un server di produzione, che spiega perché serve --single-transaction e quando il dump logico lascia il posto a quello fisico.

Il punto della strategia complessiva è che il dump del database, una volta prodotto, diventa a sua volta un file che entra nel flusso di backup del filesystem: lo si genera, lo si scrive in una directory, e lo si include nello stesso sistema cifrato e remoto che salva i dati utente. Così le due categorie, file e database, confluiscono in un'unica catena coerente, cifrata e versionata, invece di vivere in due meccanismi scollegati come accadeva nello script monolitico.

La regola che vale più di tutte le altre

C'è una verità che ripeto a ogni cliente e che vale più di qualsiasi scelta di strumento: un backup non è un backup finché non lo hai ripristinato. Lo script del 2009 produceva diligentemente i suoi archivi ogni notte, e tutti erano convinti di essere protetti, ma nessuno aveva mai provato a ripristinarne uno, e quando è servito si è scoperto che erano troncati dal limite della casella email. Un backup che non viene mai testato è una scommessa travestita da garanzia.

La prova di ripristino va fatta periodicamente e in un ambiente separato: si prende un backup, lo si ripristina su una macchina di test, e si verifica che l'applicazione riparta e che i dati siano completi e coerenti. È l'unico modo per sapere davvero che la catena funziona end-to-end, dalla cifratura al trasferimento al ripristino. A questo si aggiunge un monitoraggio minimo ma indispensabile: un alert che scatta se il backup di stanotte non si è completato, è di dimensione anomala, o non è partito affatto. Lo scenario peggiore non è il backup che fallisce con un errore visibile, è quello che fallisce in silenzio per mesi, esattamente come la casella email piena del mio cliente.

C'è anche una decisione a monte che determina quanto spesso fare i backup e quanti tenerne, ed è una decisione di business prima che tecnica: gli obiettivi di tempo e di punto di ripristino. Il punto di ripristino, l'RPO, risponde alla domanda "quanti dati posso permettermi di perdere?": se la risposta è "al massimo un'ora di lavoro", allora un backup giornaliero non basta e serve una frequenza più alta o un meccanismo continuo per il database. Il tempo di ripristino, l'RTO, risponde a "quanto a lungo posso restare fermo?": se il business non può stare giù più di poche ore, un backup logico enorme che impiega mezza giornata a ripristinarsi non rispetta l'obiettivo, e va affiancato a una strategia più rapida. Definire questi due numeri con il cliente è il primo passo che faccio, perché senza di essi "fare i backup" è un'attività senza un bersaglio, e si finisce per fare troppo dove non serve e troppo poco dove conta.

Tutto questo si automatizza, ma l'automazione va costruita con criterio, non lanciata e dimenticata. Su come trasformare una serie di comandi in una strategia di backup e rotazione affidabile ho scritto nell'articolo sulla rotazione e retention dei backup automatizzati, e su come collocare tutto questo dentro un piano di continuità con obiettivi di tempo e punto di ripristino definiti, in quello sulla strategia di backup aziendale legata al rischio di business.

Backup e ransomware: perché la copia deve essere a prova di manomissione

C'è una minaccia che nel 2009 era marginale e nel 2026 è la prima a cui penso quando progetto un backup: il ransomware. Gli attacchi moderni non si limitano a cifrare i dati di produzione; cercano deliberatamente i backup e li distruggono o li cifrano per primi, perché sanno che un'azienda con backup intatti non paga il riscatto. Questo cambia il modo in cui un backup va protetto: non basta più che esista una copia offsite, serve che quella copia non possa essere cancellata o alterata nemmeno da chi ha ottenuto le credenziali del server di produzione.

La risposta tecnica è il backup immutabile o append-only. Sia restic sia Borg supportano una modalità in cui la chiave o l'account usato dal server di produzione può solo aggiungere nuovi dati al repository, ma non cancellare o sovrascrivere quelli esistenti; la stessa documentazione ufficiale di restic raccomanda di servire il repository in modalità append-only proprio per impedire a un client compromosso di distruggere i backup. La cancellazione dei backup vecchi, quella necessaria per la rotazione, viene eseguita separatamente da un altro contesto, con credenziali diverse che non vivono sul server esposto. Così, anche se un attaccante compromette completamente la produzione, può al massimo smettere di produrre nuovi backup, ma non può toccare quelli già fatti: la finestra di recovery point precedente all'attacco resta intatta e ti permette di ripartire senza pagare nulla.

Questo principio ha fatto evolvere la regola classica del 3-2-1 nella sua versione più moderna, a volte indicata come 3-2-1-1-0: tre copie, due supporti, una offsite, una immutabile (a prova di manomissione), e zero errori verificati, cioè con i ripristini testati e privi di problemi. La separazione delle credenziali è il cuore di tutto: chi scrive i backup non deve poterli cancellare, e chi li ruota non deve essere lo stesso identità che opera sul server di produzione. È una distinzione che lo script monolitico del 2009 non poteva nemmeno concepire, perché aveva un solo insieme di credenziali per fare tutto, ed è la ragione per cui, in caso di compromissione, quei backup sarebbero stati i primi a sparire. Progettare il backup pensando a chi vuole distruggerlo, e non solo a chi vuole salvarlo, è ciò che separa una strategia del 2026 da una del 2009.

Dove conservare i backup, e perché conta quanto come li fai

L'ultimo principio, quello su cui lo script originale falliva nel modo più grave, è la destinazione. La regola operativa è la 3-2-1: tre copie dei dati, su due supporti diversi, di cui almeno una fuori sede. Una copia di backup conservata sullo stesso server che salva, o peggio in una casella di posta accessibile da quel server, non sopravvive allo scenario per cui esiste il backup, cioè la compromissione o la perdita di quel server. La copia offsite deve stare su un'infrastruttura separata, che non condivide credenziali né superficie di attacco con la produzione.

Per il nodo di backup offsite non serve un'altra macchina di produzione: serve storage separato, economico e fuori dal perimetro di attacco del server che stai salvando. Qui la scelta del provider conta, perché la destinazione di backup deve vivere su un'infrastruttura diversa, con credenziali diverse e idealmente in un datacenter diverso da quello della produzione.

Per un nodo di backup offsite a basso costo presso un provider UE, lo Storage Box di Hetzner è una destinazione SSH/SFTP pensata esattamente per questo: supporta restic e Borg, sta in datacenter europei (utile sotto GDPR) ed è separato dal tuo server di produzione. Se invece l'infrastruttura va tenuta gestita, NIS-compliant e con il dato che non lascia l'Italia, la mia prima scelta è RHX, con datacenter a Milano e Padova e gestione sistemistica inclusa, dove i backup automatizzati e il ripristino fanno parte del servizio gestito invece di essere lasciati a uno script notturno dimenticato.

Su questo terreno ho costruito anche uno strumento open source, ArkHive, che mette insieme proprio questi requisiti, backup cifrato AES-256, invio offsite via SSH e gestione della retention, perché sono esattamente gli stessi tre principi che tornano in ogni progetto: cifrare, portare fuori sede, ruotare.

Fare il backup del filesystem e dei database di un server web, nel 2026, non significa cercare il programma magico che fa tutto in un colpo, come prometteva lo script che ho trovato dal mio cliente. Significa costruire una strategia che distingue ciò che salva (i dati irreversibili, non il codice che è già in Git), usa gli strumenti giusti per ogni categoria (backup deduplicati e cifrati per i file, dump consistenti per i database), li unisce in un'unica catena cifrata e remota, rispetta la regola del 3-2-1, e soprattutto si verifica ripristinando davvero. Lo script che zippa tutto e te lo manda via email può averti dato per anni l'illusione di essere protetto, fino al giorno in cui scopri che non lo eri. Se vuoi sapere se la tua strategia di backup reggerebbe una prova di ripristino reale, contattami per un confronto diretto: di solito basta provare a ripristinare un backup per capire se la tua è una protezione o solo una collezione di file che nessuno ha mai aperto.