Come fare il backup di un VPS su storage offshore cifrato

Quasi nessuno configura i backup il giorno in cui distribuisce un server. Succede dopo — dopo che un disco si riempie durante un aggiornamento, dopo una cancellazione nella directory sbagliata, dopo che una migrazione lascia un database che si avvia pulito e risponde male, dopo che qualcuno è entrato. Il divario tra far girare una macchina che conta e avere una copia che le sopravvive è la finestra più pericolosa nel self-hosting, e la maggior parte delle persone ci vive dentro per mesi senza accorgersene, perché per molto tempo non va storto nulla e poi va storto tutto insieme. Chiuderlo non è difficile né costoso. Quello che lo fa sembrare difficile è che la parola "backup" viene usata per quattro cose diverse, e solo una di queste sarà ancora lì il giorno brutto.

Le quattro cose che non sono un backup

Ognuna di queste è genuinamente utile e vale la pena averla. Nessuna di esse è un backup, e credere il contrario è il motivo più comune per cui le persone perdono dati che pensavano al sicuro. La distinzione non è pedanteria — ognuna di queste fallisce esattamente nella situazione in cui hai più bisogno di un backup.

• Il RAID è uptime, non un backup. Un array sopravvive a un disco morto senza andare offline, ed è per questo che i nostri server di storage girano su RAID-6 e tollerano due guasti contemporanei. Non sopravvive a una directory cancellata, un aggiornamento andato male, un albero di file cifrato da qualcun altro o una tabella eliminata — ognuno di questi eventi viene scritto fedelmente su tutti i dischi nello stesso istante.
• Gli snapshot sono un "annulla", non un backup. Vivono sullo stesso storage dei dati, sono di solito visibili a root sulla stessa macchina, e qualsiasi cosa distrugga il volume o l'host si porta via anche gli snapshot. Veloci da ripristinare, inutili quando la macchina non c'è più.
• La sincronizzazione è replica, non un backup. Uno strumento di sync esiste per far corrispondere il lato remoto a quello locale, quindi una cancellazione o una corruzione si propaga alla copia tanto velocemente quanto lo permette la rete. Nextcloud, Dropbox e rclone sync si comportano tutti così per progettazione.
• Il versionamento e il cestino sono comodità, non un backup. Sono funzioni dell'applicazione, conservate nel suo stesso database, con una finestra di conservazione misurata in giorni. Quando è l'applicazione stessa a rompersi, la sua cronologia si rompe insieme a lei.
• Una copia sullo stesso server non è offsite. Se il guasto riguarda la macchina, l'account del provider, l'hypervisor o un sequestro, ogni file su quella macchina si trova nello stesso dominio di guasto, indipendentemente dalla directory in cui si trova.

Un backup è una copia separata nello spazio, separata nel tempo e separata nel controllo. Separata nello spazio perché un incendio o un sequestro non si porti via entrambe. Separata nel tempo perché tu possa tornare a prima del danno invece che a una copia fedele di esso. Separata nel controllo perché credenziali rubate dalla macchina live non possano raggiungerla. Tutto ciò a cui manca una di queste tre proprietà è una funzione di comodo travestita da backup.

La regola del 3-2-1, e la versione che sopravvive al 2026

La vecchia regola prevede tre copie dei dati, su due tipi diversi di storage, con una di esse offsite. Ha retto bene il tempo perché in realtà è una regola sul guasto non correlato, non sui nastri. Da allora si sono guadagnate un posto due aggiunte, ed entrambe esistono per cose che non capitavano comunemente quando la regola fu scritta.

• Tre copie. I dati live, più altre due. Due copie significano un guasto di distanza da un singolo punto di rottura, e i singoli punti di rottura hanno la tendenza a rompersi proprio mentre hai ancora intenzione di sistemare il primo.
• Due tipi di storage. Hardware diverso, software diverso, idealmente un provider diverso. Due volumi sullo stesso host condividono un hypervisor, un pannello di controllo e un account — il che significa che condividono anche i modi in cui un account si perde.
• Un'offsite. Fisicamente altrove, su un'infrastruttura che non va giù quando la tua lo fa. È la copia che conta per incendi, furti, sequestri e un account chiuso senza preavviso.
• Un'immutabile o offline. Il ransomware e un root compromesso cercano entrambi i backup per primi, e una destinazione su cui il tuo server può scrivere è una destinazione che il tuo server può cancellare. Credenziali append-only o un'architettura basata su pull trasformano tutto questo da catastrofe a semplice fastidio.
• Zero ripristini mai verificati. Un backup che non hai mai ripristinato è un'ipotesi. È l'aggiunta che le persone saltano più spesso e di cui si pentono più amaramente, perché un job di backup che ha segnalato successo per due anni può aver scritto archivi inutilizzabili per due anni.

Cosa mettere in backup: lo stato, non l'intera macchina

L'istinto è fare un'immagine dell'intero server. Di solito è la forma sbagliata: i backup a immagine sono grandi, lenti, scomodi da ripristinare in modo selettivo, e la maggior parte di quello che contengono è un sistema operativo standard che puoi reinstallare in un minuto. Quello che non puoi rigenerare è lo stato — le cose che esistono solo per merito di quello che hai fatto tu.

• I database, con un dump, non copiati. Un file di database live copiato mentre il motore sta scrivendo è un file "strappato" che potrebbe ripristinarsi, potrebbe ripristinarsi in modo sbagliato, e non ti dirà quale dei due casi sia successo. Usa lo strumento di dump nativo del motore, oppure ferma il servizio, oppure crea uno snapshot del filesystem e fai il dump da lì.
• Le directory dei dati applicativi. File caricati, media, risorse generate — l'albero di file a cui punta un database. Deve essere catturato nello stesso momento del suo database, altrimenti ripristini un indice che descrive file che non ci sono.
• La configurazione e le cose che hai modificato a mano. La configurazione del web server e del reverse proxy, le unit systemd, le voci cron, le regole del firewall, le venti piccole correzioni che hai fatto alle due di notte e che non ricorderai.
• I segreti e le chiavi, gestiti separatamente e con più cura. I certificati TLS e le loro chiavi private, le chiavi host SSH, i token API e soprattutto i file wallet e le seed. Meritano una copia cifrata propria che non stia solo su una macchina noleggiata.
• Le definizioni dei container e i volumi. I file compose e i file di ambiente, più i volumi con nome — la parte che le persone dimenticano, perché i container in sé si ricreano banalmente, i loro volumi no.
• L'elenco di ciò che è installato, non l'installazione in sé. Un breve inventario di pacchetti, versioni e di cosa gira dove si ripristina più in fretta e occupa meno spazio di un'immagine dell'intero filesystem di root.

Il confine è semplice: se puoi rigenerarlo da uno script o da un gestore di pacchetti in dieci minuti, non metterlo in backup — scrivi come si fa. Se esiste solo per qualcosa che hai fatto tu o un utente, gli serve una copia. Questo principio si applica, in scala, da un piccolo sito fino a un'istanza BTCPay, dove il wallet e il database sono tutto e il resto è reinstallabile, fino a un server Nextcloud, dove l'albero dei file e il suo database devono essere catturati insieme o nessuno dei due vale granché.

Dimensionare la destinazione, e quanto costa davvero

Le persone lo sovrastimano parecchio, di solito calcolando il prezzo della prima copia completa e poi moltiplicandolo per quanti giorni intendono conservarla. Uno strumento di backup moderno non funziona così. Divide i dati in chunk, memorizza ogni chunk unico una sola volta, e comprime quello che si lascia comprimere — quindi il secondo snapshot di un server rimasto per lo più invariato costa quasi nulla, e trenta snapshot giornalieri non sono nemmeno lontanamente trenta volte il primo.

• Metti a budget all'incirca la dimensione del tuo stato live, più il trenta-cinquanta percento per la cronologia, per una policy di conservazione tipica su un server che cambia a un ritmo normale.
• La conservazione guida la crescita molto più della frequenza. Snapshot orari tenuti per due giorni costano meno di snapshot giornalieri tenuti per tre anni. Decidi fino a quanto indietro andresti davvero, poi fai la potatura automaticamente fino a quel punto.
• I dati già compressi non si comprimono una seconda volta. Video, foto, archivi e blob cifrati arrivano vicino alla loro dimensione originale, quindi un server pieno di media ha bisogno di capacità reale, non di impostazioni furbe.
• I database deduplicano male tra un dump e l'altro, perché il dump compresso di un database anche solo leggermente diverso è un flusso di byte completamente diverso. Fai il dump non compresso e lascia che sia lo strumento di backup a occuparsi della compressione, e il costo dello storage crolla.
• Il primo caricamento è l'unica parte lenta. Dopo di che un'esecuzione notturna sposta solo il delta, che sulla maggior parte dei server sono megabyte. Qui il trasferimento è illimitato, quindi il primo passaggio è una questione di pazienza, non di budget.

In pratica questa è l'assicurazione più economica del tuo stack. Un server di storage parte da $7.99/mo per 1 TB su RAID-6, molto più di quanto occuperà lo stato di una manciata di istanze VPS, e STO-2 a $12.99/mo lo raddoppia. Le librerie multimediali e le conservazioni lunghe sono dove la capacità conta davvero: STO-4 a $22.99/mo ti dà 4 TB, STO-8 a $39.99/mo te ne dà 8. La destinazione parla rsync, SFTP e un'API compatibile S3, quindi ogni strumento di backup diffuso ci dialoga senza bisogno di un plugin, e i volumi sono cifrati in AES-256 a riposo con la possibilità di usare chiavi proprie — anche se, come sostiene la prossima sezione, dovresti comunque cifrare prima che i dati lascino la sorgente.

Scegliere uno strumento, e a cosa serve davvero ciascuno

Non c'è bisogno di tormentarsi qui. Tre strumenti coprono praticamente ogni caso, sono tutti gratuiti, e la differenza tra loro conta meno della differenza tra averne uno e non averne nessuno. Scegli in base alla forma del tuo problema, non ai benchmark.

• restic — la raccomandazione di default per la maggior parte dei server. Cifrato lato client, con deduplicazione, un singolo binario statico senza demone, e scrive nativamente su SFTP, endpoint compatibili S3 e directory semplici. La sua modalità append-only è la strada più semplice verso una destinazione che un server compromesso non può cancellare.
• BorgBackup — deduplicazione e compressione eccellenti, molto efficiente su collegamenti lenti, maturo e ampiamente collaudato. Per i repository remoti vuole un suo agente disponibile sulla destinazione, un piccolo vincolo in cambio di un peso sullo storage sensibilmente più leggero.
• rclone — lo strumento giusto quando il lavoro è davvero spostare dati tra object store, o quando vuoi un mirror invece di una cronologia versionata. Abbinalo al suo layer crypt se lo usi direttamente, e ricorda che una sync semplice propaga anche le cancellazioni.
• Gli strumenti di dump nativi, sempre, per i database. mysqldump, pg_dump e i loro equivalenti producono una copia logica coerente che il motore può sicuramente rileggere. Fai il dump su un file, poi lascia che sia restic o Borg a raccoglierlo — non provare a sostituire il dump con una copia furba a livello di file.
• Gli snapshot del provider solo come layer locale veloce. Usali per rollback rapidi intorno ad aggiornamenti rischiosi, e non contarli mai come una delle tue tre copie.

Passo dopo passo: un backup cifrato funzionante in un'unica seduta

1. 01Distribuisci la destinazione e blindalaUn server di storage in una regione diversa da quella dei server che protegge. SSH solo a chiavi, un suo utente dedicato, e nessun riutilizzo delle credenziali delle macchine che ci scriveranno.
2. 02Decidi l'elenco dello stato prima di toccare un toolScrivi ogni percorso e ogni database che deve sopravvivere. Dieci minuti con un file di testo ora evitano il ripristino in cui scopri la directory che nessuno aveva elencato.
3. 03Inizializza un repository cifratoGenera una password di repository robusta, inizializza il repo via SFTP o S3, e conserva quella password da qualche parte che non sia il server di cui stai facendo il backup. Un repository la cui chiave esiste solo sulla macchina morta non è recuperabile.
4. 04Fai prima il dump dei database, poi archiviaUno script wrapper che fa il dump di ogni database in una directory di staging e poi esegue un unico passaggio di backup su dump e albero dei file insieme. È quest'ordine a rendere il database e i suoi file coerenti tra loro.
5. 05Esegui il primo backup e guardalo finireIl passaggio iniziale è quello lungo. Eseguilo in un terminal multiplexer così una connessione caduta non lo interrompe, e annota quanto ci ha messo — ora conosci anche la tua finestra di ripristino.
6. 06Imposta la conservazione e fai la potatura in automaticoQualcosa come sette snapshot giornalieri, quattro settimanali e sei mensili va bene per la maggior parte dei server. Configura la potatura nello stesso job, oppure il repository cresce fino al giorno in cui smette di funzionare.
7. 07Pianificalo, poi rendi rumoroso il fallimentoUn timer notturno o una voce cron, più un avviso quando il job non segnala successo. Un job di backup silenzioso è indistinguibile dal nessun job di backup per tutti i mesi che ci vogliono ad accorgersene.
8. 08Ripristina qualcosa oggi, dal backup, su una macchina diversaNon un elenco dell'archivio — un ripristino vero di un file reale e un database reale su un server usa e getta. Finché non lo hai fatto almeno una volta, hai uno script di backup, non un backup.

Far sopravvivere la copia a ciò che ha ucciso il server

Questa è la parte che distingue un backup da un semplice fastidio per un attaccante. Se il server custodisce credenziali che possono cancellare i backup, allora un root compromesso, un'infezione ransomware o uno script andato male raggiungono entrambe le copie nello stesso minuto. La correzione è strutturale, non una questione di password più forti.

• Usa credenziali append-only dal lato sorgente. restic e Borg supportano entrambi una modalità in cui la macchina che scrive può creare nuovi snapshot ma non può cancellare o potare quelli esistenti. La potatura gira allora da un'altra parte, secondo una pianificazione, con una chiave separata.
• Preferisci un'architettura pull dove puoi. Una destinazione che si allunga nella sorgente e recupera i dati, invece di una sorgente che li spinge fuori, significa che la sorgente non detiene mai alcuna credenziale verso l'archivio.
• Non riutilizzare mai chiavi SSH o password di repository tra server diversi. Una macchina compromessa dovrebbe costarti i backup di quella macchina, non l'intero parco server.
• Tieni almeno una copia in una giurisdizione diversa e in un dominio di guasto diverso. La diversità di regione non è paranoia — è la differenza tra un incidente hardware e una perdita totale.
• Conserva la chiave del repository completamente fuori dall'infrastruttura. Un password manager, un token hardware, carta in una cassaforte. Ovunque tranne le macchine che il repository protegge.
• Fai attenzione ai backup che iniziano ad avere successo in modo sospettosamente veloce. Un job che prima impiegava venti minuti e ora ne impiega quaranta secondi di solito sta facendo il backup di una directory vuota o non montata, e continuerà a segnalare successo mentre lo fa.

Qui la scelta della regione è una vera decisione, non un dettaglio, perché il tuo backup e il tuo server di produzione non dovrebbero poter essere sequestrati nella stessa azione. Se questo conta per quello che gestisci, scegliere la posizione con criterio vale qualche minuto, e mettere la destinazione in un regime legale diverso da quello della sorgente è proprio il punto dell'esercizio.

Il ripristino: la parte che nessuno prova mai

I ripristini falliscono per motivi banali, e falliscono nel momento peggiore possibile perché è l'unico momento in cui la maggior parte delle persone ne tenta uno. Ognuno dei problemi qui sotto si scopre in pochi minuti durante un'esercitazione e in ore durante un'interruzione reale.

• La password del repository stava solo sul server che è morto, quindi gli archivi sono intatti e permanentemente illeggibili.
• Il database si è ripristinato ma l'albero dei file proveniva da un'esecuzione di tre ore dopo, così l'applicazione mostra record i cui file non esistono.
• Il backup catturava una directory che aveva silenziosamente smesso di essere montata, così ha archiviato fedelmente una cartella vuota ogni notte per un anno.
• Nessuno conosceva l'ordine di ripristino — prima il database o prima i file, servizio fermo o attivo — e lo stato ripristinato a metà è dovuto essere buttato via e ricominciato da capo.
• Il ripristino richiede undici ore sul collegamento disponibile, che nessuno aveva mai misurato, e il piano di recovery ne presupponeva una.
• La proprietà e i permessi dei file sono tornati sbagliati, così tutto è presente ma l'applicazione si rifiuta di partire.
• È sempre stato testato solo lo snapshot più recente, e la corruzione da cui si sta cercando di riprendersi era iniziata sei settimane prima.

Un'esercitazione due volte l'anno risolve tutto questo. Distribuisci un VPS usa e getta, ripristina al suo interno dal repository reale, avvia il servizio, guarda i dati, distruggi la macchina. Costa un paio di dollari e un'ora, e trasforma l'intero sistema di backup da una convinzione in un fatto. Fallo una volta con il runbook aperto e correggi il runbook ovunque ti abbia mentito.

Il livello privacy: un backup può disfare la tua anonimità

Questo punto è specifico dell'operare offshore, ed è facile farlo bene solo se ci pensi prima del primo caricamento e non dopo. Un backup è una copia completa, indicizzata e di lunga durata della tua infrastruttura che risiede da qualche altra parte, il che lo rende sensibile esattamente quanto l'originale e considerevolmente più facile da dimenticare.

• I nomi dei file e la struttura delle directory sono metadati anche quando il contenuto è cifrato. La cifratura lato client di restic e Borg copre anche i nomi; un semplice mirror rsync no, e un elenco di directory basta spesso per identificare cos'è un server e chi lo gestisce.
• L'account di destinazione fa parte della storia. Un vault di backup noleggiato con una carta intestata al tuo nome legale lega quel nome a tutto ciò che il vault contiene, per quanta cura tu abbia messo a tenere pulita la macchina sorgente.
• Il traffico di backup è un collegamento persistente, pianificato e ad alto volume tra due indirizzi. È uno dei pattern più leggibili che un server produce, e punta verso la destinazione ogni singola notte.
• I vecchi snapshot sopravvivono alle decisioni che li hanno creati. Qualcosa che hai smesso di conservare un anno fa è ancora nell'archivio se la conservazione non lo ha mai potato, una proprietà utile per il recovery e negativa per l'esposizione.
• I log e la cronologia della shell finiscono travolti insieme a tutto il resto. L'archivio contiene spesso gli indirizzi IP, i comandi e le credenziali con cui eri stato attento sulla macchina live.

I rimedi sono ordinari. Usa uno strumento che cifra i nomi oltre ai contenuti. Noleggia la destinazione allo stesso modo in cui hai noleggiato la sorgente — da un host che non ti ha mai chiesto chi sei, finanziato da un saldo in crypto, con una ricarica in Monero se vuoi chiudere anche la traccia dei pagamenti. Instrada il trasferimento su un tunnel WireGuard se è il pattern in sé a preoccuparti. E applica alla macchina di storage lo stesso hardening dei primi dieci minuti che hai applicato alla produzione, perché una macchina che custodisce una copia di tutto non è un bersaglio meno prezioso dell'originale — spesso lo è di più.

Errori che costano alle persone i propri dati

• Fidarsi del RAID, degli snapshot o di una cartella sincronizzata come backup, e scoprire a quale categoria appartenevano davvero proprio il giorno in cui contava.
• Tenere l'unica copia sullo stesso server, lo stesso account o lo stesso provider della cosa che si sta proteggendo.
• Copiare un file di database live invece di farne il dump, e ripristinare un archivio che è sbagliato in modo sottile e silenzioso.
• Fare il backup dell'albero dei file e del database in momenti diversi, così al ripristino nessuno dei due corrisponde all'altro.
• Conservare la password del repository sulla stessa macchina che il repository protegge.
• Dare alla sorgente pieni diritti di cancellazione sulla destinazione, così una singola compromissione si porta via anche gli archivi.
• Non fare mai potatura, finché la destinazione si riempie e il job notturno ha fallito in silenzio per settimane.
• Fare il backup di centinaia di gigabyte di dati pubblici della blockchain mentre il file wallet non si trova in nessuno degli archivi.
• Configurare avvisi sul fallimento ma mai sull'assenza, così un job che ha smesso del tutto di girare non segnala assolutamente nulla.
• Testare solo lo snapshot più recente, e scoprire durante un incidente reale che la corruzione è precedente anche a quello.

I backup sono la cosa meno interessante che configurerai, e l'unica la cui assenza è irrecuperabile. Tutto il resto su un server si può ricostruire con un gestore di pacchetti e un pomeriggio; lo stato no. Dedicagli una seduta: elenca cosa deve sopravvivere, fai il dump dei database, invia un archivio cifrato a un server di storage in un altro paese, fai la potatura secondo una pianificazione, avvisa in caso di silenzio, e ripristina qualcosa di vero prima di chiudere il terminale. Poi lascialo stare. La misura di un buon sistema di backup è che te ne dimentichi, finché un mattino non trasforma una catastrofe in un'ora solo leggermente fastidiosa.