Fare il backup di un VPS che puoi davvero ripristinare

Chiedi a chiunque perché fa il backup e la risposta è di solito “nel caso il disco muoia”. Su un VPS moderno, questo è quanto di più vicino esista alla cosa meno probabile che ti capiterà. Il tuo volume risiede su NVMe in un array ridondato con un hypervisor che ti migrerà via da un host in avaria prima ancora che tu te ne accorga; il guasto del disco è un problema del provider, ed è un problema già risolto. Costruire l'intera strategia di backup attorno a questo è come comprare un estintore per una casa che si allaga.

Ecco cosa porta via davvero i dati alle persone, all'incirca in ordine di frequenza. Primo, e con ampio margine: tu. Un rm -rf con una variabile che si è espansa nel nulla. Una DROP DATABASE sul terminale sbagliato perché due schede sembravano identiche. Uno script di migrazione lanciato due volte. Un docker compose down -v in cui la -v era pura memoria muscolare. Non sono casi esotici; sono un martedì qualunque.

Secondo, le applicazioni che cancellano i propri dati. Un aggiornamento che esegue una migrazione distruttiva e fallisce a metà strada. Un plugin che svuota una directory di cache che si scopre non essere affatto una cache. Una rotazione dei log configurata sul percorso sbagliato. Terzo, la compromissione — e nota che questo è ormai il caso in cui un attaccante vuole che i backup spariscano, il che cambia il progetto in modi su cui torniamo più avanti. Quarto, e facile da dimenticare su un host no-KYC: perdere l'account. Un saldo che è arrivato a zero mentre eri via, una voce del password manager che non hai mai annotato, un indirizzo email che hai abbandonato. Noi sospendiamo entro poche ore da un saldo a zero e distruggiamo sette giorni dopo, e questo è deliberatamente severo — è l'aritmetica che ci permette di non chiederti chi sei. Non esiste un operatore di supporto che possa cercare la tua identità e fare un'eccezione, perché non esiste un'identità da cercare.

Quest'ultima categoria è quella che separa un hosting privacy-first da quello mainstream, e dovrebbe plasmare il tuo piano. Ogni controllo che rende questo server difficile da attribuirti rende anche difficile, per chiunque — noi compresi — restituirtelo. Il backup è ciò che trasforma questo scambio da un rischio in una scelta.

Gli snapshot sono meravigliosi e dovresti usarli. Fanne uno prima di ogni aggiornamento del kernel, ogni migrazione di database, ogni volta che stai per fare qualcosa che preferiresti poter annullare. Si ripristinano in pochi secondi, costano quasi nulla, e ti salveranno un pomeriggio una dozzina di volte l'anno.

Non sono comunque backup, per tre ragioni strutturali che nessuna quantità di marketing del provider può cambiare. Vivono dentro lo stesso account: chiunque possa accedere al tuo pannello può cancellarli, e se l'account smette di funzionare gli snapshot smettono di esistere insieme a lui. Vivono nello stesso dominio di guasto: stesso provider, stesso control plane, spesso lo stesso cluster di storage, il che significa che un singolo evento negativo può plausibilmente portarsi via sia l'originale che la copia. E sono opachi: uno snapshot di una macchina in esecuzione cattura un database a metà scrittura con la stessa fedeltà con cui cattura tutto il resto, quindi il ripristino di uno snapshot di un server MySQL molto attivo ti dà uno scenario di crash-recovery invece di un database pulito.

La vecchia regola del 3-2-1 — tre copie, su due tipi di supporto, una delle quali off-site — viene di solito recitata senza notare che la clausola centrale è priva di senso su un'infrastruttura a noleggio. Non hai due tipi di supporto. Hai un dispositivo a blocchi virtuale, e un altro dispositivo a blocchi virtuale, ed entrambi sono la SAN di qualcun altro. Quello che sopravvive alla traduzione su un VPS è la parte che è sempre stata importante: almeno una copia deve stare in un posto che un singolo evento negativo non può raggiungere. Provider diverso o quantomeno regione diversa, credenziali diverse, account diverso, e — se il motivo per cui usi hosting offshore è legale piuttosto che tecnico — una giurisdizione diversa, in modo che un singolo ordine del tribunale non colpisca entrambe le copie in una volta.

Questa è la sezione che gli altri tutorial sul backup non hanno, ed è quella che conta di più se hai pagato questo server in Monero.

Il consiglio di default che si trova ovunque su internet è di spingere (push) i tuoi backup verso uno storage a oggetti: Backblaze B2, Amazon S3, Wasabi, un Google Drive via rclone. È economico, è durevole, funziona. Ma, con un solo comando, vanifica anche gran parte di ciò che stavi facendo. Aprire quell'account ha richiesto una carta e di solito un documento d'identità. Dal momento in cui viene caricato il primo snapshot, quel provider detiene un registro con marca temporale che associa il tuo nome e i tuoi dati di pagamento all'indirizzo IP del tuo server, aggiornato ogni ora, per sempre. Non hai verificato la tua identità con noi; l'hai verificata con loro, e poi hai tracciato una linea tra i due.

La seconda metà è peggiore, ed è la parte che sfugge a molti. La chiave API che autorizza quei caricamenti è un file sul server di produzione. Chiunque ottenga root su quella macchina — o chiunque acquisisca legalmente il disco — non ottiene soltanto i tuoi dati. Ottiene una credenziale che risolve, con una sola chiamata API, in un'identità di fatturazione. Il server anonimo è diventato un cartello indicatore che punta alla tua banca.

Niente di tutto questo rende sbagliato lo storage a oggetti. Lo rende una decisione anziché un default. Tre vie d'uscita, in ordine decrescente di quanto bene preservano ciò da cui sei partito:

• Un secondo VPS no-KYC, idealmente in una giurisdizione diversa dalla produzione, pagato dallo stesso saldo in cripto. La destinazione eredita le proprietà di anonimato della fonte invece di contraddirle. È quello che facciamo noi, ed è ciò che il resto di questa guida presuppone.
• Un provider di storage che accetta cripto senza identità. Esistono; sono più piccoli; verifica che il percorso di pagamento sia davvero privo di identità prima di fidarti del marketing, e controlla i costi di egress prima di scoprirli durante un ripristino.
• Una macchina che possiedi fisicamente, con un pull via WireGuard da dietro la tua stessa connessione. Eccellente per l'anonimato, scarsa per la disponibilità, e significa che la tua velocità di ripristino è la velocità di upload di casa tua. Ragionevole come terza copia, debole come unica copia.

Qualunque cosa tu scelga, l'account che detiene i backup non dovrebbe condividere credenziali, indirizzo email o percorso di recupero con l'account che detiene la produzione. Il punto è proprio che un login compromesso non deve raggiungerli entrambi. È la stessa disciplina del tenere le identità separate altrove, applicata all'angolo meno affascinante del sistema.

Quasi ogni tutorial sul backup produce la stessa architettura: un cron job sul server di produzione che si autentica su un repository remoto e ci scrive sopra. È semplice, funziona, e ha una proprietà che nessuno menziona — il server di produzione detiene una credenziale che può cancellare l'intero repository. Fare pruning dei vecchi snapshot richiede diritti di cancellazione, quindi la chiave che esegue il tuo job notturno è anche la chiave che svuota la cassaforte.

Pensa a cosa significa questo durante una compromissione. Un attaccante con root sulla macchina non ha bisogno di cercare i tuoi backup; gli hai gentilmente lasciato una credenziale funzionante e un file di configurazione che nomina il repository. Enumerare e distruggere i backup prima di far scattare qualcosa di visibile non è un raffinamento ipotetico — è prassi standard, perché è ciò che trasforma un incidente in una trattativa. Il tuo job notturno era la ricognizione.

Esistono tre schemi, e la differenza tra loro riguarda interamente quale macchina detiene quale chiave.

Push semplice è quello descritto sopra. La produzione ha lettura-scrittura-cancellazione. Comodo, e fallisce completamente esattamente nello scenario in cui hai più bisogno di un backup. Usalo solo se l'unica minaccia che ti interessa davvero sono le tue stesse dita.

Push append-only mantiene la stessa forma ma rimuove il verbo pericoloso. Il repository è servito da qualcosa che comprende il protocollo e rifiuta le cancellazioni: rest-server --append-only per restic, oppure borg serve --append-only forzato da authorized_keys. La produzione può creare nuovi snapshot e non può rimuovere quelli vecchi. Il pruning avviene più tardi, da un altro posto, usando una chiave diversa. È un grande miglioramento per circa venti minuti di lavoro, e per la maggior parte delle persone è il punto di arresto giusto.

Pull inverte la connessione. L'host di backup si allunga verso la produzione via SSH, copia ciò di cui ha bisogno, ed esegue lo strumento di backup localmente sul proprio disco. La produzione non detiene alcuna credenziale di backup — non c'è nulla da trovare su quella macchina, perché la macchina non sa nemmeno dove vivano i suoi backup. Questo è l'assetto più solido, ed è quello che la procedura passo-passo qui sotto costruisce.

Sii onesto su quanto costa il pull, perché non è gratis. Hai spostato la chiave invece di eliminarla: l'host di backup ora detiene una chiave SSH verso la produzione, quindi una compromissione dell'host di backup si propaga in avanti fino al sistema live. È uno scambio migliore — l'host di backup non esegue nulla, non espone altro che SSH, ed è un bersaglio molto più piccolo di un server web pubblico — ma resta uno scambio, e chiudi la maggior parte del divario residuo forzando quella chiave su un comando di sola lettura, così che non possa essere usata per nient'altro che leggere file.

Tre strumenti coprono essenzialmente ogni caso, e la scelta è molto meno tormentata di quanto suggeriscano i thread dei forum.

restic cifra di default, deduplica tra gli snapshot, parla SFTP, S3, REST e una dozzina di altri backend, e viene distribuito come un singolo binario statico che puoi far girare su qualsiasi cosa. Il suo formato di repository è content-addressed, quindi uno snapshot è economico e i dati identici vengono memorizzati una sola volta, indipendentemente da quante macchine li inviano. I costi sono reali ma modesti: vuole memoria proporzionale all'indice del repository, e un'esecuzione interrotta può lasciare un lock stantio che l'esecuzione successiva rifiuta di scavalcare finché non lo rimuovi con restic unlock. Questa è la raccomandazione di default, ed è ciò che usano i passaggi qui sotto.

Borg deduplica meglio, comprime meglio, ed è nettamente più veloce su repository con milioni di file piccoli. Il suo compromesso è l'accoppiamento: Borg deve essere installato su entrambi i lati e le versioni devono corrispondere da vicino, un repository è pensato davvero per un solo client, e non ha un backend nativo per lo storage a oggetti senza un livello di supporto aggiuntivo. Se la tua fonte è uno spool di posta corposo o un filesystem pieno di file piccoli, e controlli entrambe le macchine, Borg userà la metà dello spazio. La sua modalità --append-only è anche l'implementazione più pulita dell'idea tra i due strumenti.

rsync non è uno strumento di backup, e far finta del contrario è come si finisce con una copia fedelmente rispecchiata di una directory corrotta. Non ha versioning, non ha deduplicazione e non ha cifratura a riposo; rsync --delete propaga il tuo errore alla copia alla velocità del cavo. È comunque lo strumento giusto per spostare byte tra due macchine che controlli, che è esattamente il lavoro che svolge in un progetto a pull, con restic che fornisce il versioning e la cifratura una volta che i byte sono atterrati. Usa ciascuno per quello che è.

Una cosa da non fare: non inventarti una soluzione fatta in casa con tar e un nome file con data. Funziona per circa quattro mesi, fino al giorno in cui il disco si riempie perché niente è mai scaduto, o al giorno in cui scopri che una copia completa ogni notte di un dataset da 40 GB corrisponde a 1,2 TB al mese di storage che stai pagando per conservare trenta cose quasi identiche.

L'istinto è fare il backup dell'intero filesystem. Resistigli. Un filesystem root è per lo più pacchetti di distribuzione che puoi reinstallare in novanta secondi, e includerli costa storage, tempo di trasferimento e, peggio, attenzione — un backup da 40 GB che nessuno vuole testare è meno utile di uno da 900 MB che viene ripristinato ogni trimestre.

Ciò che davvero non può essere ricostruito è poca cosa: /etc (l'intera configurazione, e il motivo per cui una ricostruzione richiede un'ora invece di un weekend), /home e /root, /srv e /var/www, lo stato applicativo sotto /var/lib/ e /opt/, i volumi Docker con nome, le unit di cron e systemd che hai scritto tu, e i dump del tuo database. Salta /proc, /sys, /dev, /run, /tmp, /var/cache, i file di swap, i socket e /var/lib/docker/overlay2 — quest'ultima è ricostruibile dal tuo file compose ed è spesso la singola directory più grande sul disco.

Ora la parte che silenziosamente rovina i ripristini. Copiare la directory dei dati di un database mentre il database è in esecuzione produce un insieme di file che molto probabilmente sarà inutilizzabile. Il motore tiene lo stato in memoria, scrive su più file in un ordine che conta, e la tua copia percorre quell'albero nell'arco di svariati minuti catturando file diversi in istanti diversi. InnoDB a volte se ne riprenderà con un crash-recovery e a volte no; il guasto emerge mesi dopo, durante un ripristino in cui stai già avendo una brutta giornata.

Fai invece il dump attraverso il motore, poi metti il dump in backup:

# MariaDB / MySQL — InnoDB gets a consistent snapshot from one transaction
mariadb-dump --single-transaction --quick --routines --triggers --events \
  --all-databases | zstd -T0 > /var/backups/db/all-$(date -u +%F).sql.zst

# PostgreSQL — pg_dump is consistent by design; grab roles separately
pg_dumpall --globals-only > /var/backups/db/globals.sql
pg_dump -Fc -Z6 mydb    > /var/backups/db/mydb.dump

# SQLite — never cp a live database; WAL mode makes that a torn file
sqlite3 /var/lib/app/app.db ".backup /var/backups/db/app.db"

Due note a margine che vale la pena avere. --single-transaction ti dà coerenza solo per InnoDB — se una tabella è ancora MyISAM viene copiata fuori dalla transazione e può risultare incoerente rispetto al resto, quindi converti quelle tabelle o mettile sotto lock. E una volta che stai facendo il dump, escludi la directory dei dati live dal passaggio sui file. Fare il backup di entrambi significa conservare una grande copia lacerata accanto a quella buona, e dare a un futuro ripristino due candidati in cui uno è silenziosamente sbagliato.

I container non cambiano il principio, solo il percorso: esegui il dump con docker compose exec -T db mariadb-dump … e metti in backup il file risultante, non il volume sottostante.

La cifratura lato client è l'unica ragione per cui è accettabile conservare i tuoi dati su una macchina diversa da quella da cui provengono. Sia restic che Borg cifrano prima che qualsiasi cosa lasci la fonte, quindi l'host di backup detiene solo testo cifrato e può essere trattato come storage non fidato. Questa proprietà vale esattamente quanto la cura con cui gestisci la chiave, e non un briciolo di più.

La modalità di guasto è deprimentemente comune. La password del repository sta in /etc/restic/env sul server di produzione, il che va bene ed è necessario per l'automazione. Poi è proprio la produzione che perdi — distrutta, sequestrata, o semplicemente sparita insieme all'account — e ti ritrovi davanti a diverse centinaia di gigabyte di blocchi cifrati e alla progressiva consapevolezza che l'unica copia della chiave stava dentro proprio la cosa da cui ti stavi proteggendo dal perdere.

Quindi: la password sul server è una copia di lavoro, mai il verbale ufficiale. Il verbale ufficiale vive da qualche parte che sopravvive al server — un password manager il cui vault è a sua volta salvato altrove, oppure scritto su carta in un cassetto, o entrambi. Annota la posizione del repository e il comando di ripristino esatto accanto ad essa, perché una passphrase senza contesto è un rompicapo che risolverai sotto stress tra diciotto mesi. E dedica cinque minuti a verificarla: da una macchina diversa, con solo ciò che è nel password manager, esegui restic snapshots contro il repository. Se funziona, hai un backup. Se richiede qualcosa che esiste solo sulla produzione, hai una cartella molto costosa.

Entrambi gli strumenti supportano più chiavi su un solo repository (restic key add), che è il modo pulito per dare accesso al job di pruning o a un secondo amministratore senza condividere la passphrase originale. E se il disco di produzione è cifrato con LUKS, tieni i due segreti genuinamente separati — conservare la passphrase di restic dentro il volume LUKS e la passphrase di LUKS dentro il repository restic è un ciclo che si blocca in modo sicuro su entrambi i lati.

La retention sembra una questione di costo dello storage, ma è in realtà una questione di latenza nel rilevamento. Il numero che conta non è quanto disco vuoi spendere; è per quanto tempo un problema può passare inosservato nel tuo sistema. Qualunque sia quel periodo, il tuo backup più vecchio deve essere più vecchio di esso.

Sette snapshot giornalieri sembra generoso ed è scarso nella pratica. Una tabella corrotta che nessuno interroga, una cancellazione lenta causata da un cron job difettoso, un'intrusione rimasta silenziosa per un mese prima di fare qualcosa di visibile — tutte queste cose impiegano di norma più di una settimana a emergere, e se la tua storia è profonda sette giorni allora ogni snapshot che conservi è già contaminato. Il dwell time nelle intrusioni reali si misura regolarmente in settimane. Gli snapshot mensili economici sono la difesa specifica contro questo, e la deduplicazione li rende davvero molto economici: un mensile conservato per un anno aggiunge una frazione di una copia completa, perché solo i blocchi effettivamente cambiati vengono memorizzati due volte.

restic forget \
  --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --keep-yearly 2 \
  --prune

Questa scala — una settimana di giorni, un mese di settimane, un anno di mesi, un paio d'anni di anni — corrisponde a circa ventisei snapshot e, su dati tipici, a ben meno del doppio della dimensione di una singola copia completa. È il default per cui faremmo battaglia, a meno che tu non abbia una ragione specifica per discostartene.

Due note operative. forget senza --prune rimuove solo le etichette, quindi lo spazio non viene recuperato finché non fai il prune — cosa che sorprende chi osserva un disco che non si riduce mai. E --prune richiede diritti di cancellazione sul repository, quindi in un progetto append-only o pull non gira sul server di produzione. Gira sull'host di backup, o dal tuo laptop, con una chiave che la produzione non ha mai visto. Questa separazione è tutto il punto della faccenda; non disfarla per comodità all'ultimo passaggio.

Il classico disastro del backup non è un job che va in crash. È un job che smette di girare e non lo dice a nessuno, scoperto undici mesi dopo da qualcuno che ne aveva bisogno. Ogni elemento qui sotto esiste per rendere impossibile esattamente quell'esito.

Usa un timer systemd invece di cron. Ottieni log veri nel journal con gli exit status allegati, Persistent=true in modo che un'esecuzione mancata mentre la macchina era spenta avvenga al boot successivo invece di essere saltata per sempre, e RandomizedDelaySec in modo che una flotta non travolga l'host di backup esattamente alle 03:00. La notifica di fallimento di cron è un'email verso una mailbox locale che, su un server moderno, non va esattamente da nessuna parte.

# /etc/systemd/system/backup.timer
[Unit]
Description=Nightly encrypted backup

[Timer]
OnCalendar=*-*-* 03:17:00
RandomizedDelaySec=1800
Persistent=true

[Install]
WantedBy=timers.target

Poi aggiungi un dead-man's switch, che è la singola riga a più alto valore in tutta questa guida. Alla fine esatta dello script — dopo che il backup è andato a buon fine, non prima — fai una richiesta HTTPS verso un monitor che si aspetta di sentirti ogni giorno e avvisa quando non succede. Questo inverte la logica della notifica: invece di affidarti a un fallimento per generare un messaggio, è l'assenza stessa a diventare l'allarme. Un job morto da tre giorni diventa allora un messaggio nella tua casella di posta invece che una scoperta in piena crisi. Ospita tu stesso il monitor sull'host di backup se preferisci non creare un altro account di terze parti; sono poche righe e un timer a sé.

Infine, i piccoli rischi operativi, tutti quelli in cui siamo incappati almeno una volta. Un'esecuzione interrotta lascia un lock e ogni esecuzione successiva fallisce con un messaggio che smetti di leggere dopo la quarta notte — gestisci restic unlock in modo deliberato, non riflesso. Un disco di destinazione pieno fa fallire ogni job finché qualcuno non se ne accorge; genera un avviso sullo spazio libero, non solo sullo stato del job. Una chiave SSH con una scadenza, una host key ruotata, una regola nftables aggiunta durante un lavoro non correlato — ognuna di queste interromperà silenziosamente il pull. E systemctl enable --now, non solo start: un timer che non è mai stato abilitato funziona magnificamente fino al primo riavvio e poi non gira mai più.

Tutto quanto sopra è preparazione. Questa è la parte che lo trasforma in un backup, ed è la parte che quasi tutti saltano.

Una volta al trimestre, fai il deploy di un VPS nuovo — lo Starter da $5 è più che sufficiente e la fatturazione è oraria, proporzionata al secondo, quindi l'intero esercizio costa un paio di centesimi. Ripristina al suo interno usando solo ciò che avresti in un disastro reale: l'indirizzo del repository, la passphrase dal tuo password manager, e la procedura scritta. Non usare deliberatamente nulla della produzione, perché nello scenario che stai provando la produzione non esiste. Porta su l'applicazione, punta una voce del file hosts verso il nuovo IP, clicca in giro. Poi distruggilo.

# on a throwaway machine, with nothing but the passphrase
export RESTIC_REPOSITORY=sftp:[email protected]:/srv/restic/prod
restic snapshots                      # can you even see the history?
restic restore latest --target /restore
restic check --read-data-subset=10%   # verify stored blocks, not just metadata

Quello che questo scova non è mai ciò che ti aspetti. È il file di configurazione che stava in una directory che la lista di inclusione non copriva. Il dump del database che è a zero byte da cinque settimane perché una password è cambiata e lo script non ha controllato il suo exit status. L'applicazione che non parte perché un secret vive in una variabile d'ambiente detenuta dall'orchestratore e non è mai stata nel filesystem. Il record DNS non documentato. Il certificato che va riemesso prima che qualcosa risponda sulla 443. Ognuno di questi è una correzione da dieci minuti in un pomeriggio tranquillo, oppure due ore brutte alle tre del mattino.

Annota quanto è durata l'esercitazione, dall'inizio alla fine. Quel numero — non la frequenza dei backup — è il tuo vero tempo di ripristino, ed è l'unica risposta onesta quando qualcuno chiede per quanto tempo saresti fuori uso. Aggiungi anche restic check --read-data-subset=5% a un timer mensile: legge e verifica un campione rotante dei blocchi effettivamente memorizzati anziché il solo indice, ed è così che trovi la corruzione silenziosa mentre esiste ancora una buona copia a cui tornare. Se mai sposti l'intero server verso un nuovo host, un ripristino provato è anche gran parte della migrazione già fatta.