Una strategia di backup non si testa mai la notte in cui il server muore. Si testa settimane prima, in tre decisioni silenziose che nessuno mette per iscritto: dove va a finire la copia, chi può cancellarla e se qualcuno abbia mai davvero provato a rileggerla.
Un hosting che non ha mai chiesto la tua identità cede qualcosa in cambio, ed è onesto dirlo subito. Non c'è un account manager da chiamare, nessun ticket che resuscita un volume cancellato, e la nostra stessa policy di conservazione è netta sul motivo: i dati del server vengono distrutti entro 24 ore dalla terminazione, i dischi vengono cancellati crittograficamente invece che formattati, e non viene conservato alcun backup. È la stessa caratteristica che rende la piattaforma valida, vista dal lato opposto. Tutto ciò che vorresti recuperare dopo una brutta notte deve già trovarsi altrove, e sei tu a doverlo mettere lì.
Cosa distrugge davvero i server
Quasi nessuno perde un server nel modo in cui se lo immagina. Il guasto hardware catastrofico è reale ma raro, ed è l'unico caso contro cui un host competente si è già premunito. Le perdite che accadono davvero sono più banali, e ognuna vince contro un tipo diverso di copia — per questo «ho un backup» non è una risposta finché non dici a quale di questi sopravvive.
| Cosa va storto | Come succede di solito | Cosa ti salva |
|---|---|---|
| La tua stessa mano | Un rm -rf con una variabile di shell vuota, una migrazione puntata in produzione, un deploy che ha cancellato la tabella sbagliata | Qualsiasi copia esterna precedente all'errore — il che significa che la retention deve coprire un periodo più lungo del tempo che impieghi ad accorgertene |
| Corruzione silenziosa | Un NVMe morente, una scrittura troncata durante un riavvio, un database che scrive righe danneggiate da una settimana | Copie versionate abbastanza profonde da raggiungere un punto integro noto. Una singola copia speculare rispecchia fedelmente il danno |
| Compromissione | Una chiave rubata, un'applicazione non aggiornata, una dipendenza avvelenata — e poi, deliberatamente, i tuoi backup | Una copia che la macchina compromessa non aveva il potere di cancellare. Qui non conta nient'altro |
| Un evento del provider o del paese | Perdita hardware, un'azione legale presso il datacenter, un account o token che non riesci più a raggiungere | Una copia che non si trova presso quel provider né sotto quella giurisdizione |
| Perdere la chiave | Una passphrase dimenticata, un keyfile cancellato insieme al server che proteggeva, un header LUKS che nessuno ha esportato | Niente. È l'unica riga senza colonna di recupero, ed è più comune del guasto hardware |
Leggi questa tabella come una checklist, non come un elenco di paure. Una copia notturna su un secondo disco della stessa macchina risponde solo alla prima riga. Uno snapshot nello stesso pannello risponde alla prima e alla seconda. Solo una copia conservata dove il server non può arrivare, protetta da una chiave che possiedi ancora, risponde a tutte e cinque.
Uno snapshot non è un backup, e nemmeno il tuo host lo è
Gli snapshot sono eccellenti in quello che fanno: annullano in pochi secondi e senza alcun trasferimento un aggiornamento andato male. Quello che non possono fare è sopravvivere a ciò che ha eliminato il server, perché condividono con esso ogni dominio di guasto — lo stesso provider, lo stesso account, lo stesso token di fatturazione, lo stesso paese, spesso lo stesso cluster di storage. Uno snapshot ti protegge da te stesso. Un backup ti protegge da tutto il resto.
Qui la distinzione conta più che presso un host tradizionale, perché le solite reti di sicurezza sono state rimosse di proposito. Nessuno accede ai server dei clienti, quindi nessuno si accorge che il tuo job di backup fallisce da marzo. Non c'è identità collegata all'account, quindi non esiste un percorso umano tipo «dimostra chi sei e te lo ripristiniamo». E la terminazione è davvero definitiva: un saldo scaduto è un evento di perdita dati, non un evento di fatturazione.
La clausola delle 24 ore è tutto l'argomento. Su questa piattaforma i dati di un server terminato vengono distrutti entro un giorno, e i dischi vengono cancellati crittograficamente invece che formattati. Non esiste ripristino della cancellazione, nessun livello di cold-storage nascosto, nessun esito del supporto che finisca in «abbiamo trovato una copia più vecchia» — perché conservarne una significherebbe trattenere i tuoi dati dopo che ci hai chiesto di non farlo. La rete di sicurezza e la privacy sono lo stesso compromesso, fatto una volta sola.
La regola 3-2-1, riscritta per chi non ha mai mostrato un documento
La regola classica dice tre copie, su due tipi di supporto, una delle quali fuori sede. Fu scritta per un'epoca di nastri e dischi rotanti, e la clausola sui supporti ha smesso silenziosamente di voler dire qualcosa: il tuo disco di produzione è NVMe, il disco del tuo target di backup è NVMe, e chiamarli «due supporti» è una storia che ti racconti da solo. La clausola che vale la pena conservare è quella sulla distanza, e per un'infrastruttura offshore la distanza non si misura in chilometri.
Riscrivila come tre copie, due provider, due giurisdizioni. I guasti che eliminano entrambe le copie insieme quasi mai sono fisici — sono un account a cui hai perso l'accesso, un provider che ha avuto una brutta settimana, oppure uno strumento legale che colpisce un paese e non ha portata in un altro. Due server nello stesso rack sono una copia con passaggi in più; due server sotto lo stesso regime legale sono a malapena meglio. La nostra guida alle giurisdizioni spiega come sceglierne una seconda che non rispecchi semplicemente l'esposizione della prima.
In pratica è economico. Un target di backup non ha bisogno di core, e ha appena bisogno di rete — serve disco e un indirizzo. Il piano VPS più piccolo in una delle nostre altre sette sedi è un endpoint restic o Borg all'altezza, e per archivi misurati in terabyte un server dedicato con dischi reali costa meno per terabyte di qualsiasi object storage. Dove i dati sono davvero grandi e raramente letti, l'economia favorisce il bare metal con ampio margine.
Una cosa che le persone fanno bene in produzione e sbagliano sul target di backup: pagarlo allo stesso modo. Un secondo server acquistato con una carta a tuo nome ricollega silenziosamente l'identità che ti sei sforzato di rimuovere dal primo, e ora contiene una copia completa di tutto ciò che vi si trova sopra. Se il server di produzione viene pagato in Monero, il server di backup merita lo stesso trattamento.
La terza copia è quella che quasi tutti saltano, ed è l'unica immune a ogni guasto remoto contemporaneamente: un disco che tieni fisicamente in mano, aggiornato di tanto in tanto, mantenuto offline. Una volta al mese basta per la maggior parte delle persone. Costa l'attenzione di un caffè ed è la copia che sopravvive agli scenari che le altre due condividono.
Push, pull, e l'errore che permette a una brutta notte di divorare entrambe le copie
Ecco la configurazione che quasi tutti costruiscono per primo. Un job sul server di produzione gira ogni notte, custodisce una chiave o un token per il target di backup, si connette e invia i dati. Funziona, è semplice, e ha una proprietà che diventa visibile solo nel giorno peggiore della vita del server: chi controlla la macchina di produzione controlla anche i backup.
Non è un'ipotesi teorica. Cancellare o cifrare i backup della vittima prima di farsi notare è prassi standard per chi lo fa a livello commerciale — le credenziali si trovano in un cron job o in un file di ambiente, e trovarle richiede circa un minuto. Una copia che il tuo attaccante può cancellare non è una seconda copia. È uno specchio della prima con un ritardo.
Ci sono due soluzioni pulite, e si combinano bene con l'hardening di base che dovresti aver già fatto.
- Target append-only. Entrambi gli strumenti principali supportano una modalità in cui un client può aggiungere dati ma non può rimuoverli. Borg lo fa fissando la chiave SSH sul target su
borg serve --append-only; restic lo fa con un server REST avviato con--append-only. Il server di produzione scrive ogni notte ed è strutturalmente incapace di distruggere la cronologia. La potatura dei vecchi snapshot avviene poi sul target, in una sessione che la macchina di produzione non può avviare. - Pull invece di push. Inverti la direzione: l'host di backup si connette alla produzione, legge e archivia. La produzione non custodisce alcuna credenziale per il target, quindi non c'è nulla da rubare. Limita la chiave usata lato produzione con
restricte uncommand=forzato, così una chiave di backup rubata non può diventare una shell.
Pull è il modello più solido e richiede un po' più di lavoro per funzionare; append-only è quasi gratis se usi già Borg o restic. Entrambi trasformano «l'attaccante ha cancellato i miei backup» da un fatto compiuto in un tentativo. Se porti via una sola cosa da questa guida, porta via questa sezione.
Cifra alla fonte, poi decidi chi custodisce la chiave
Entrambi gli strumenti seri cifrano sulla macchina di cui si sta facendo il backup, prima che qualsiasi cosa attraversi la rete. Il target memorizza blob che non può interpretare — ed è esattamente questo che rende sicura la copia tra provider diversi. Il tuo secondo host non deve essere affidabile, né tantomeno amichevole; deve solo essere raggiungibile e avere disco. È questa singola proprietà a trasformare «un server in un paese di cui non so nulla» da un rischio in infrastruttura.
Questo è un meccanismo diverso dal cifrare il disco del server stesso, e i due rispondono a domande diverse — la nostra guida sulla crittografia completa del disco su un VPS spiega cosa protegge e cosa non protegge la cifratura del disco mentre la macchina è in funzione. La cifratura dei backup è la più semplice e la più utile delle due, perché il modello di minaccia è onesto: i dati sono a riposo, su hardware che non controlli, e la chiave non arriva mai lì.
Il che sposta tutto il rischio sulla custodia della chiave. La passphrase è ora un singolo punto di perdita totale, ed è un punto singolo peggiore di quanto ci si aspetti, perché perderla è silenzioso — niente si rompe, i backup continuano a girare, e te ne accorgi esattamente nel momento in cui ne avevi bisogno. Tre abitudini risolvono il problema:
- Tieni la passphrase sul server solo come file leggibile dal solo root, richiamato con
--password-file, così non compare mai in un elenco processi o nella cronologia della shell. - Conserva una copia leggibile da un umano fuori da ogni macchina coinvolta. Carta in un cassetto batte davvero un password manager che si sincronizza con un account che potresti perdere anche tu.
- Aggiungi una seconda chiave al repository —
restic key add, oppure una chiave Borg esportata — così che una passphrase dimenticata sia un fastidio e non la fine dell'archivio.
La regola alla base di tutte e tre: se l'unica copia della chiave vive sulla macchina che il backup esiste per sostituire, non hai un backup. Hai un mucchio cifrato di blocchi e una storia su di essi.
Scegliere uno strumento, in una tabella
La scelta dello strumento conta meno della direzione della connessione e dello stato della tua chiave, per questo arriva al sesto posto e non al primo. Detto ciò, le differenze sono reali, e scegliere la forma sbagliata per il lavoro crea problemi più avanti.
| Strumento | Cifra prima di partire | Deduplica | Target append-only | Dove si usa |
|---|---|---|---|---|
| restic | Sì, l'intero repository | Sì | Sì, tramite il suo server REST | La scelta predefinita. Parla SFTP, object storage e il proprio server, quindi il target può essere quasi qualsiasi cosa |
| BorgBackup | Sì, l'intero repository | Sì, il migliore del gruppo | Sì, nativamente via SSH | Un unico target Linux raggiunto via SSH. Imbattibile quando i dati sono grandi e ripetitivi |
| rsync con rotazioni | No — il target vede tutto | Parziale, tramite hardlink | No | Mirroring verso una macchina che controlli interamente, quando i ripristini parziali istantanei contano più della privacy |
| rclone | Solo con rclone crypt | No | Dipende dal provider di storage | Spostare un archivio già esistente in object storage, o tra provider diversi |
| Replica ZFS | Solo con un dataset cifrato | Sì, a livello di blocco | Tramite permessi sugli snapshot | Replica tra due macchine ZFS. Molto veloce, molto rigida su entrambi i lati |
| tar con age o GPG | Sì, se cifri l'archivio | No | Non applicabile | Archivi piccoli, occasionali, da conservare per sempre, dove la semplicità batte l'efficienza |
Per un singolo server, restic verso un secondo VPS è la strada più breve per arrivare a qualcosa di corretto. Per un seedbox, un archivio multimediale o qualsiasi cosa con molti file grandi e simili, la deduplicazione di Borg è la differenza tra un disco pieno e uno vivibile — la guida al seedbox approfondisce il lato storage di quel carico di lavoro.
Tutto ciò che è in esecuzione non è un file
Il backup corrotto più comune al mondo è una copia diretta dei file di un database attivo. Si completa senza errori, pesa la quantità giusta, e al ripristino dà una tabella che il motore si rifiuta di aprire. Il database era a metà di una scrittura quando è passata la copia; quello che hai salvato è la fotografia di una pagina mentre viene voltata.
Tre vie d'uscita, in ordine crescente di sforzo. Dumpalo: mysqldump --single-transaction produce un dump InnoDB coerente senza bloccare chi scrive, e pg_dump fa lo stesso per PostgreSQL. Fanne uno snapshot: congela il filesystem o crea uno snapshot LVM o ZFS, copia dallo snapshot, rilascialo — è così che gestisci dataset troppo grandi per un dump notturno. Oppure fermalo: per un servizio piccolo, due minuti di downtime alle 04:00 sono una strategia di coerenza perfettamente rispettabile, ed è l'unica senza casi limite.
La stessa logica va oltre i database. Il layer scrivibile di un container è usa e getta, ma i suoi volumi no, e nemmeno lo è il file docker compose e l'ambiente che lo accompagna — un backup che ripristina i dati ma non la definizione ti lascia a ricostruire lo stack a memoria. Le code di messaggi, Redis con la persistenza attiva, e uno spool di posta scritto da un MTA meritano tutti lo stesso trattamento: metti in pausa, fai uno snapshot o un dump, ma non copiare mai a crudo sperando bene.
Cosa mettere nel backup, e le parti che tutti dimenticano
La maggior parte delle persone fa il backup del carico ovvio — il database e la directory dell'applicazione — e ricostruisce il resto a mano sotto pressione. È nella ricostruzione che si perdono le ore. Un backup che ti riporta a un sistema funzionante, e non a un mucchio di dati corretti, include il livello noioso:
/etcper intero, più le unit e i timer systemd che hai scritto, e qualsiasi crontab che vive fuori da esso.- I certificati TLS e le loro chiavi private, o come minimo la chiave account ACME, così i certificati si rinnovano invece di ripartire da zero.
- Le regole del firewall e l'elenco dei pacchetti, che insieme ricostruiscono la forma della macchina più in fretta di qualsiasi tuo ricordo.
- I segreti dell'applicazione e i file d'ambiente — quelli deliberatamente esclusi dal tuo repository di codice, e quindi presenti da nessun'altra parte.
- I record DNS esportati come testo, incluse le voci di reverse-DNS e PTR, che vivono presso il provider e non sul server.
Alcune chiavi non sono dati — sono identità. La chiave privata di un servizio onion di Tor è l'indirizzo: perdila e il sito non può tornare online allo stesso nome .onion, qualsiasi altra cosa tu abbia ripristinato. Una chiave server WireGuard significa riemettere ogni configurazione client che hai mai distribuito. La chiave DKIM di un mail server significa un nuovo selettore e un nuovo inizio per la deliverability. Il seed e lo stato dei canali di un nodo Lightning possono significare fondi, non file — la guida all'hosting di nodi crypto è esplicita su questo punto. Copia questi elementi separatamente, tienili offline, e trattali come più preziosi dei dati che proteggono.
Un ripristino che non hai testato è una voce di corridoio
Il software di backup riferisce su se stesso, e riferisce onestamente sulla cosa sbagliata. «Snapshot completato» significa che i dati sono stati scritti in un repository. Non dice nulla sul fatto che il repository possa essere letto su una macchina diversa da questa, da una persona che non ricorda cosa ha configurato undici mesi fa.
Comincia con i controlli di integrità economici — restic check --read-data-subset=5% oppure borg check --verify-data a intervalli regolari — e capisci che verificano l'archivio, non la tua capacità di usarlo. L'esercitazione vera è diversa e richiede un pomeriggio, una volta sola. Ordina un server nuovo a consumo orario in una sede che normalmente non usi. Ripristina su di esso con nient'altro che l'indirizzo del repository, la passphrase e i tuoi appunti. Fai ripartire il servizio. Cronometra tutto. Poi distruggi la macchina. Costo totale: pochi dollari, ed è l'unico esercizio che produce un numero di cui ti puoi fidare.
Quello che espone in modo affidabile non sono mai i dati. È il pacchetto mancante che nessuno ha annotato, la configurazione che viveva fuori dai percorsi coperti dal backup, la passphrase che è esistita solo nella cronologia della shell del server che stai cercando di sostituire, e la versione dello strumento che sa leggere il formato del tuo repository. Ognuno di questi è banale da correggere in anticipo e miserabile da scoprire durante un'interruzione.
Annota i due numeri che ti dà l'esercitazione: quanto è durato un ripristino, e quanto lavoro può perdere la pianificazione. Quella è la policy di backup. Tutto il resto sopra è dettaglio implementativo al loro servizio.
Automatizzarlo perché continui a succedere
Esegui il job da un timer systemd invece che da cron. Ottieni i log in un unico posto, un registro reale dell'ultima esecuzione, e una pianificazione che sopravvive ai riavvii — nessuna di queste cose te la dà cron senza lavoro extra. Tieni la passphrase fuori dal file unit stesso, che chiunque abbia accesso alla shell può leggere direttamente con systemctl cat.
Poi risolvi la modalità di guasto che colpisce davvero le persone, che non è un errore ma il silenzio. Un backup che ha smesso di girare sei settimane fa sembra esattamente identico a uno che ha funzionato perfettamente, perché entrambi non producono alcun output. Avvisa in caso di assenza, non solo di fallimento. Fai in modo che il job segnali un monitor in caso di successo e lascia che sia il monitor a lamentarsi quando il segnale non arriva — e posiziona quel monitor ovunque tranne che sul server che sorveglia, dato che una macchina spenta non può segnalare di essere spenta.
Imposta la retention deliberatamente e non per default. Qualcosa come --keep-daily 7 --keep-weekly 4 --keep-monthly 6 copre gli errori che noti stanotte e la corruzione che noti in primavera, senza crescere all'infinito. Esegui la potatura lato target se sei passato ad append-only, che è proprio il senso di esserci passato. Il volume di trasferimento raramente è il vincolo sulla nostra rete — la banda è illimitata su ogni piano — quindi pianifica per la coerenza e non per una quota, e verifica la tempistica rispetto alle tue ore di calma. Le abitudini più ampie attorno a tutto questo sono trattate nella guida all'OpSec del server.
La versione breve
Se non fai nient'altro con questa pagina, fai queste sei cose, più o meno in quest'ordine:
- Metti una copia presso un secondo provider, in una seconda giurisdizione, pagata nello stesso modo privato della prima.
- Rendi quella copia append-only, oppure recuperala dal target tramite pull, così un server compromesso non può distruggerla.
- Lascia che lo strumento cifri alla fonte, e tieni la chiave lontana da entrambe le macchine coinvolte.
- Fai il dump dei database e ferma o metti in snapshot tutto ciò che è in esecuzione; non copiare mai a crudo lo stato live.
- Fai il backup delle chiavi di identità separatamente — onion, WireGuard, DKIM, seed dei nodi — perché quelle non possono essere rigenerate.
- Ripristina una volta su un server usa e getta, cronometralo, e annota cosa mancava.
Niente di tutto questo è esotico, e niente di tutto questo richiede un weekend. È un pomeriggio di configurazione e un'esercitazione, contro una categoria di perdita che manda a monte i progetti. Su una piattaforma che deliberatamente non conserva nulla su di te, la copia che hai fatto tu stesso è l'unica che esiste — questo è il costo dell'accordo, ed è equo. Attiva un secondo server in una giurisdizione diversa dalla prima, e dai al backup di stanotte un posto dove atterrare.