[Home](https://servhidden.com/it) /
[Guide di Hosting Privato](https://servhidden.com/it/guides) /
Backup VPS: Strategia Cifrata, Offsite e Che Funziona Davvero






Operaciones


# Backup VPS che Si Ripristinano Davvero



L'hosting no-KYC toglie la rete di sicurezza insieme alla burocrazia: nessun backup conservato, dati distrutti entro 24 ore dalla terminazione, e nessun supporto che finisca con una copia recuperata. Ecco il piano operativo — cosa copiare, dove metterlo, come impedire che un attaccante lo cancelli, e come dimostrare che si ripristina davvero.


[Leer la guida](#guide-body)
[FAQ](#guide-faq)






## En questa pagina




- [Guida](#guide-body)

- [FAQ](#guide-faq)

- [Guide relacionullas](#guide-related)

- [Paginas consigliate](#guide-cta)






Senza KYC
Solo crypto
Nessun log
DMCA ignorato
Root completo
NVMe SSD





19 min di lettura
Aggiornato Aug 2026

En questa pagina

[01Cosa distrugge davvero i server](#cosa-distrugge-davvero-i-server)
[02Uno snapshot non è un backup, e nemmeno il tuo host lo è](#uno-snapshot-non-è-un-backup-e-nemmeno-il-tuo-host-lo-è)
[03La regola 3-2-1, riscritta per chi non ha mai mostrato un documento](#la-regola-3-2-1-riscritta-per-chi-non-ha-mai-mostrato-un-doc)
[04Push, pull, e l'errore che permette a una brutta notte di divorare entrambe le copie](#push-pull-e-lerrore-che-permette-a-una-brutta-notte-di-divor)
[05Cifra alla fonte, poi decidi chi custodisce la chiave](#cifra-alla-fonte-poi-decidi-chi-custodisce-la-chiave)
[06Scegliere uno strumento, in una tabella](#scegliere-uno-strumento-in-una-tabella)
[07Tutto ciò che è in esecuzione non è un file](#tutto-ciò-che-è-in-esecuzione-non-è-un-file)
[08Cosa mettere nel backup, e le parti che tutti dimenticano](#cosa-mettere-nel-backup-e-le-parti-che-tutti-dimenticano)
[09Un ripristino che non hai testato è una voce di corridoio](#un-ripristino-che-non-hai-testato-è-una-voce-di-corridoio)
[10Automatizzarlo perché continui a succedere](#automatizzarlo-perché-continui-a-succedere)
[11La versione breve](#la-versione-breve)
[FAQDomande frequenti](#guide-faq)
[→Paginas consigliate](#guide-cta)







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](https://servhidden.com/it/privacy) è 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.

Un target di backup ha bisogno di disco e di un indirizzo, non di core. La seconda macchina più economica in una giurisdizione diversa è un endpoint all'altezza — e l'unica copia che sopravvive a un evento presso il primo provider.

## 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](https://servhidden.com/it/guides/choosing-an-offshore-jurisdiction) 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](https://servhidden.com/it/vps) più piccolo in una delle nostre altre [sette sedi](https://servhidden.com/it/locations) è un endpoint restic o Borg all'altezza, e per archivi misurati in terabyte un [server dedicato](https://servhidden.com/it/dedicated) 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](https://servhidden.com/it/guides/how-to-pay-for-hosting-with-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](https://servhidden.com/it/guides/first-hour-vps-hardening-checklist) 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 restrict e un command= 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](https://servhidden.com/it/guides/full-disk-encryption-on-a-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](https://servhidden.com/it/guides/seedbox-setup-guide) 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:

- /etc per 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](https://servhidden.com/it/guides/how-to-host-a-tor-hidden-service), 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](https://servhidden.com/it/guides/offshore-mail-server-setup). Il seed e lo stato dei canali di un nodo Lightning possono significare fondi, non file — la [guida all'hosting di nodi crypto](https://servhidden.com/it/guides/crypto-node-hosting-guide) è 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](https://servhidden.com/it/guides/server-opsec-staying-anonymous).

## 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](https://servhidden.com/it/vps) in una giurisdizione diversa dalla prima, e dai al backup di stanotte un posto dove atterrare.





FAQ

## Backup VPS — domande frequenti





### 01
ServHidden fa il backup del mio VPS?



No, ed è una scelta deliberata, non una dimenticanza. La nostra policy di conservazione afferma che non viene conservato alcun backup, che i dati del server vengono distrutti entro 24 ore dalla terminazione, e che i dischi vengono cancellati crittograficamente invece che formattati. Conservare una copia dei tuoi dati dopo che ci hai chiesto di rimuoverli contraddirebbe il motivo per cui questa piattaforma esiste. Tutto ciò che vuoi far sopravvivere al server devi copiarlo tu stesso, idealmente verso un secondo provider in una seconda giurisdizione.





### 02
Uno snapshot è la stessa cosa di un backup?



No. Uno snapshot condivide ogni dominio di guasto con il server da cui proviene — lo stesso provider, lo stesso account, lo stesso paese, spesso lo stesso storage. È eccellente per annullare un aggiornamento andato male, ed è inutile contro la perdita dell'account, del provider o della macchina. Tratta gli snapshot come un tasto «annulla» e i backup come un'assicurazione; risolvono problemi diversi e ti servono entrambi.





### 03
restic o BorgBackup: quale devo usare?



restic se il target potrebbe essere object storage, SFTP o qualcosa che non hai ancora scelto, perché parla con il maggior numero di backend. BorgBackup se il target è un'unica macchina Linux raggiunta via SSH e i dati sono grandi e ripetitivi, perché la sua deduplicazione è la più forte del gruppo. Entrambi cifrano alla fonte prima che qualsiasi cosa lasci la macchina, ed entrambi supportano un target append-only, il che conta molto più della scelta tra i due.





### 04
Come impedisco a un attaccante di cancellare i miei backup?



Elimina la capacità, non il movente. O rendi il target append-only, così le credenziali sul server di produzione possono aggiungere dati ma mai rimuoverli, oppure inverti la connessione così che l'host di backup faccia il pull dalla produzione e il server di produzione non custodisca alcuna credenziale. Cancellare i backup prima di farsi notare è prassi standard per chi lo fa a livello commerciale, e una copia che il tuo attaccante può cancellare non è una seconda copia.





### 05
Dove deve stare la seconda copia di backup?



Presso un provider diverso, in una giurisdizione diversa, e pagata in modo altrettanto privato del tuo server di produzione. Gli eventi che eliminano entrambe le copie insieme raramente sono fisici — sono un account a cui hai perso l'accesso, un provider che ha avuto una brutta settimana, o uno strumento legale che raggiunge un paese e non un altro. Due server nello stesso rack sono una copia con passaggi in più. Poiché gli strumenti cifrano alla fonte, il secondo host non deve essere uno di cui ti fidi.





### 06
Ogni quanto devo fare il backup?



Ragiona a ritroso partendo da quanto lavoro sei disposto a rifare. Un blog può perdere un giorno senza che nessuno se ne accorga; un negozio non può perdere un'ora di ordini. Ogni notte è la scelta predefinita giusta per la maggior parte delle configurazioni a server singolo, con dump del database più frequenti se le scritture hanno valore. Ciò che conta più della frequenza è la profondità della retention: la corruzione spesso si nota con settimane di ritardo, quindi conserva abbastanza cronologia da poter tornare a un punto precedente al suo inizio.





### 07
Un backup cifrato è sicuro su un server che non controllo?



Per il contenuto, sì — restic e Borg cifrano prima che i dati lascino la fonte, quindi il target memorizza blob che non può leggere e la chiave non viaggia mai. Quello che il target impara è il metadato: più o meno quanti dati conservi, come cambiano, e quando girano i tuoi job. Di solito è accettabile. Se non lo è, varia la pianificazione e tieni il repository su una macchina la cui proprietà non è collegata a quella di produzione.





### 08
Cosa succede se perdo la passphrase del backup?



L'archivio è perso, permanentemente, senza alcun rimedio da parte di nessuno. È la perdita totale più comune di tutto l'argomento, e l'unico guasto senza un percorso di recupero. Tieni la passphrase lontano da ogni macchina coinvolta, preferisci la carta a un account che potresti perdere anche tu, e aggiungi una seconda chiave al repository così che una password dimenticata sia un fastidio e non la fine dell'archivio.




Guide relacionullas

## Seguir leyendo


[### Come Scegliere una Giurisdizione di Hosting Offshore in 2026

Compra


Un quadro decisionale pratico per scegliere una giurisdizione offshore: leggi sulla conservazione dei dati, esposizione ai trattati MLAT, posizione sul DMCA, velocità dei tribunali e applicazione reale della legge — paese per paese.


FAQ di 6 domande](https://servhidden.com/it/guides/choosing-an-offshore-jurisdiction)
[### VPS vs Server Dedicato per Workload Critici per la Privacy

Compra


Quando un VPS va bene, quando la tenancy condivisa è un rischio e quando il bare metal è l'unica risposta onesta. Isolamento hardware, rischio hypervisor e costo rispetto al modello di minaccia.


FAQ di 6 domande](https://servhidden.com/it/guides/vps-vs-dedicated-for-privacy)
[### VPN Autogestionulla in un VPS Senza KYC: WireGuard vs OpenVPN

Operaciones


Perché una VPN self-hosted batte i provider commerciali, e come si confrontano davvero WireGuard e OpenVPN su privacy, prestazioni e rischio operativo nel 2026.


FAQ di 6 domande](https://servhidden.com/it/guides/self-hosted-vpn-wireguard-vs-openvpn)
[### RTX 4090 vs H100 SXM5 per inferenza IA (e dove rientra la RTX 5090)

Compra


Guida all'acquisto: quale GPU NVIDIA scegliere per carichi di lavoro LLM, immagine, video, voce e fine-tuning self-hosted nel 2026. RTX 4090 vs RTX 5090 vs H100 SXM5 vs doppio H100 — VRAM, throughput, $/token, quando vince ciascuna.


FAQ di 6 domande](https://servhidden.com/it/guides/rtx-4090-vs-h100-for-ai-inference)
[### RDP Windows Offshore per Trading Forex con MT4 / MT5 / cTrader

Operaciones


Guida completa: perché scegliere un RDP Windows per il trading forex, come scegliere una giurisdizione offshore a bassa latenza, la configurazione di MT4 / MT5 / cTrader / Expert Advisor, la latenza verso i server dei broker e il percorso di checkout senza KYC.


FAQ di 6 domande](https://servhidden.com/it/guides/offshore-windows-rdp-for-forex-trading)
[### Hosting con DMCA Ignorato: Cosa Significa Davvero nel 2026

Compra


Cosa acquista davvero un hosting "DMCA ignored", quali giurisdizioni lo supportano concretamente, i carichi di lavoro che ne hanno bisogno e le insidie sul copyright che il termine non copre.


FAQ di 6 domande](https://servhidden.com/it/guides/dmca-ignored-hosting-explained)
[### Registrazione Anonima di Domini con Crypto: Privacy WHOIS nel 2026

Privacy


Una guida pratica 2026 per registrare domini senza rivelare la propria identità: regimi WHOIS per TLD, scelta del registrar, opzioni di pagamento crypto e gli errori operativi che vi espongono comunque.


FAQ di 6 domande](https://servhidden.com/it/guides/anonymous-domain-registration-with-crypto)
[### Pagamenti Crypto per Hosting: Monero vs Bitcoin vs USDT

Privacy


Come la scelta della moneta di pagamento influisce su ciò che il tuo host scopre di te. Privacy, commissioni, finalità ed esposizione all'analisi della catena per XMR, BTC e USDT — con una raccomandazione chiara.


FAQ di 6 domande](https://servhidden.com/it/guides/crypto-payments-monero-vs-bitcoin-vs-usdt)
[### L'hosting offshore è davvero anonimo? Una risposta onesta

Privacy


L'hosting offshore no-KYC elimina l'identità che un host normale raccoglie — ma "anonimo" dipende dal pagamento, dai log del provider e dalla tua opsec. Ecco cosa è davvero tracciabile.


FAQ di 6 domande](https://servhidden.com/it/guides/is-offshore-hosting-truly-anonymous)
[### La prima ora di hardening di un VPS: una checklist

Operaciones


Una checklist concreta e ordinata per mettere in sicurezza un nuovo VPS in meno di un'ora: chiavi SSH, un firewall, fail2ban, aggiornamenti automatici e la riduzione della superficie d'attacco che blocca la maggior parte degli attacchi opportunistici.


FAQ di 6 domande](https://servhidden.com/it/guides/first-hour-vps-hardening-checklist)
[### Cos'è l'Hosting No-KYC? Definizione, Legalità e Come Funziona

Privacy


L'hosting No-KYC ti permette di noleggiare un server senza alcuna verifica d'identità — nessun nome, nessuna email, nessun documento. Ecco cosa significa esattamente, come funziona tecnicamente, se è legale e come scegliere un provider affidabile.


FAQ di 6 domande](https://servhidden.com/it/guides/what-is-no-kyc-hosting)
[### L'Hosting Offshore è Legale? La Risposta Onesta per il 2026

Compra


L'hosting offshore è legale — per te e per il provider. Ecco cosa significa davvero il termine, dove si trova il confine giuridico, i miti da sfatare e come usarlo in modo responsabile.


FAQ di 6 domande](https://servhidden.com/it/guides/is-offshore-hosting-legal)
[### Come pagare l'hosting con Monero (XMR) — Guida passo dopo passo

Privacy


Una guida passo dopo passo per pagare un VPS o un server dedicato con Monero (XMR): perché XMR è l'opzione più privata, come ottenerlo e come funziona il checkout — dalla fattura al server operativo in pochi minuti.


FAQ di 6 domande](https://servhidden.com/it/guides/how-to-pay-for-hosting-with-monero)
[### Come ospitare un sito web in modo anonimo — Guida pratica 2026

Privacy


Una guida pratica e stratificata per ospitare un sito web senza alcuna identità associata: l'account, il pagamento, il dominio, la giurisdizione, la connessione e il contenuto — ogni livello spiegato nel dettaglio.


FAQ di 6 domande](https://servhidden.com/it/guides/how-to-host-a-website-anonymously)
[### Come Configurare una VPN WireGuard su un VPS — Guida Passo dopo Passo

Operaciones


Costruisci la tua VPN privata su un VPS con WireGuard: perché una VPN self-hosted supera quella commerciale, la configurazione completa dall'installazione a un client connesso, e come rafforzarne la sicurezza.


FAQ di 6 domande](https://servhidden.com/it/guides/how-to-set-up-wireguard-vpn-on-a-vps)
[### Come fare self-hosting di un LLM su un server GPU — Guida 2026

Operaciones


Esegui il tuo modello linguistico su un server GPU in affitto: perché il self-hosting supera un'API, quale GPU e modello scegliere, la configurazione con Ollama o vLLM, e i costi reali.


FAQ di 6 domande](https://servhidden.com/it/guides/self-host-an-llm-on-a-gpu-server)
[### Hosting Bulletproof vs Hosting Offshore — Qual è la Differenza?

Compra


Hosting bulletproof e hosting offshore vengono continuamente confusi — ma non sono la stessa cosa. Ecco la vera differenza, perché conta e quale dei due fa davvero al caso tuo.


FAQ di 6 domande](https://servhidden.com/it/guides/bulletproof-vs-offshore-hosting)
[### Come acquistare un VPS con Bitcoin — Guida passo dopo passo (2026)

Compra


Una guida accessibile anche ai principianti per acquistare un VPS con Bitcoin: come ottenere BTC, scegliere un piano, pagare la fattura e cosa si ottiene — un server attivo senza carta e senza nome associato.


FAQ di 6 domande](https://servhidden.com/it/guides/how-to-buy-a-vps-with-bitcoin)
[### I migliori paesi per l'hosting ignorato dal DMCA nel 2026

Compra


Dove ospitare i tuoi server quando vuoi essere al riparo dai takedown in stile statunitense: le giurisdizioni che funzionano davvero, cosa significa concretamente "ignorato dal DMCA" e come scegliere.


FAQ di 6 domande](https://servhidden.com/it/guides/best-countries-for-dmca-ignored-hosting)
[### Come ospitare un servizio nascosto Tor (sito .onion) — Guida 2026

Operaciones


Configura un servizio onion Tor su un VPS: cos'è un servizio nascosto, perché rappresenta la forma più solida di hosting anonimo, la procedura completa e come mantenerlo davvero anonimo.


FAQ di 6 domande](https://servhidden.com/it/guides/how-to-host-a-tor-hidden-service)
[### Configurazione di un Server Mail Offshore — Self-Hosting di Email Private nel 2026

Operaciones


Gestisci il tuo server email privato su un VPS offshore: perché ospitare la posta in autonomia, cosa ti serve, come configurare uno stack mail all-in-one e come garantire la consegna dei messaggi.


FAQ di 6 domande](https://servhidden.com/it/guides/offshore-mail-server-setup)
[### Guida all'Hosting di Nodi Crypto — Esegui un Nodo Blockchain su un VPS

Operaciones


Come ospitare un nodo blockchain su un server: perché gestire il proprio nodo, come dimensionare il server per Bitcoin, Ethereum, Monero e non solo, la configurazione e come mantenerlo privato.


FAQ di 6 domande](https://servhidden.com/it/guides/crypto-node-hosting-guide)
[### GPU Hosting per Stable Diffusion — Esegui il Tuo Server di Immagini

Operaciones


Esegui Stable Diffusion sul tuo server GPU dedicato: perché fare self-hosting della generazione di immagini, quale GPU scegliere, la configurazione con una web UI e il confronto dei costi rispetto a un servizio in hosting.


FAQ di 6 domande](https://servhidden.com/it/guides/gpu-hosting-for-stable-diffusion)
[### Server OpSec — Restare Anonimi Quando Gestisci un Server

Privacy


Sicurezza operativa per chi gestisce un server anonimo: gli errori che espongono l'identità, le abitudini che li prevengono e come tenere davvero separate le identità.


FAQ di 6 domande](https://servhidden.com/it/guides/server-opsec-staying-anonymous)
[### Guida alla configurazione di una seedbox — Costruisci la tua seedbox privata nel 2026

Operaciones


Come costruire la propria seedbox su un server: cos'è una seedbox, come dimensionarla, come installare un client torrent con interfaccia web e come mantenerla privata e sicura.


FAQ di 6 domande](https://servhidden.com/it/guides/seedbox-setup-guide)
[### Come aggirare la censura DPI con il tuo VPS (guida 2026)

Privacy


La tua VPN ha smesso di funzionare? Come aggirare la censura DPI con il tuo VPS: cosa rileva davvero la deep packet inspection, quale dei cinque protocolli del 2026 batte quale tipo di blocco, e una guida completa a VLESS+REALITY.


FAQ di 6 domande](https://servhidden.com/it/guides/bypass-dpi-censorship-with-your-own-vps)
[### Crittografia full-disk su un VPS: setup LUKS e cosa protegge davvero

Operaciones


Come cifrare un VPS con LUKS: volumi dati cifrati, cifratura full-root con sblocco remoto via SSH, le impostazioni che contano su un server piccolo, e cosa blocca davvero la crittografia del disco.


FAQ di 8 domande](https://servhidden.com/it/guides/full-disk-encryption-on-a-vps)
[### Nascondere l'IP del server di origine: CDN, reverse proxy e cosa trapela

Privacy


Se mettere una CDN davanti a un server offshore: cosa nasconde, lo sportello reclami che erediti, i sei modi in cui un IP di origine trapela comunque, e come verificare il tuo.


FAQ di 8 domande](https://servhidden.com/it/guides/hiding-your-origin-server-ip)
[### Self-Hosting Matrix: federazione, metadati e cosa non copre la E2EE

Operaciones


Cosa ti dà davvero un homeserver Matrix: Synapse contro Conduit, il server_name che non puoi mai cambiare, i media che riempiono il disco e cosa rivela la federazione.


FAQ di 8 domande](https://servhidden.com/it/guides/self-host-a-matrix-server)
[### Migrare un Sito su Hosting Offshore Senza Downtime

Operaciones


L'ordine che rende noiosa una migrazione di host: abbassa il TTL del DNS con giorni di anticipo, fai girare entrambi i server in parallelo, blocca le scritture per minuti anziché ore — e ripulisci la traccia di DNS passivo, Certificate Transparency e WHOIS che il trasloco lascia dietro di sé.


FAQ di 8 domande](https://servhidden.com/it/guides/migrate-website-to-offshore-hosting)
[### How to Self-Host a Crypto Payment Gateway with BTCPay Server

Operaciones


Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out.


FAQ di 8 domande](https://servhidden.com/it/guides/self-host-a-crypto-payment-gateway)




## Dai al backup di stanotte un posto dove atterrare



Sette giurisdizioni, banda illimitata su ogni piano, e server a partire da $7.50/mo che diventano endpoint restic o Borg all'altezza. Niente KYC, niente email, solo crypto — tanto per il target di backup quanto per la produzione.


[Vedi i Piani VPS](https://servhidden.com/it/vps)
[Server dedicati](https://servhidden.com/it/dedicated)
[Todas le località](https://servhidden.com/it/locations)


## Structured data (JSON-LD)

```json
{
    "@context": "https://schema.org",
    "@type": "Organization",
    "@id": "https://servhidden.com/#organization",
    "name": "ServHidden",
    "url": "https://servhidden.com",
    "description": "VPS e server dedicati offshore in 7 giurisdizioni. Nessun KYC, nessun log, solo crypto. Privacy per architettura.",
    "logo": {
        "@type": "ImageObject",
        "url": "https://servhidden.com/ServHidden.webp",
        "width": 512,
        "height": 512
    },
    "foundingDate": "2025",
    "areaServed": [
        {
            "@type": "Country",
            "name": "Iceland"
        },
        {
            "@type": "Country",
            "name": "Panama"
        },
        {
            "@type": "Country",
            "name": "Moldova"
        },
        {
            "@type": "Country",
            "name": "Romania"
        },
        {
            "@type": "Country",
            "name": "Switzerland"
        },
        {
            "@type": "Country",
            "name": "Netherlands"
        },
        {
            "@type": "Country",
            "name": "Russia"
        }
    ],
    "knowsAbout": [
        "Offshore hosting",
        "Offshore VPS",
        "Bare-metal dedicated servers",
        "DMCA-ignored hosting",
        "No KYC hosting",
        "Cryptocurrency payments",
        "Privacy engineering",
        "Token-based authentication",
        "Anonymous domain name registration",
        "No-KYC domain registrar",
        "WHOIS privacy",
        "Cheap .com domains",
        "Crypto-paid domain names",
        "NVIDIA GPU compute",
        "Windows RDP hosting",
        "Agentic commerce"
    ],
    "contactPoint": {
        "@type": "ContactPoint",
        "contactType": "customer support",
        "url": "https://servhidden.com/contact",
        "availableLanguage": [
            "en",
            "ru",
            "zh",
            "es",
            "fr",
            "de",
            "pt",
            "ar",
            "ja",
            "ko",
            "hi",
            "id",
            "it",
            "tr",
            "fa",
            "vi"
        ]
    },
    "sameAs": [
        "https://servhidden.com/canary",
        "https://servhidden.com/press"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "WebSite",
    "@id": "https://servhidden.com/#website",
    "url": "https://servhidden.com",
    "name": "ServHidden",
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "inLanguage": [
        "en",
        "ru",
        "zh",
        "es",
        "fr",
        "de",
        "pt",
        "ar",
        "ja",
        "ko",
        "hi",
        "id",
        "it",
        "tr",
        "fa",
        "vi"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "Backup VPS: Strategia Cifrata, Offsite e Che Funziona Davvero",
    "description": "Il tuo host non conserva backup. Cosa distrugge davvero i server, perché il backup push muore con loro, restic contro BorgBackup, e come testare un vero ripristino.",
    "image": "https://servhidden.com/assets/img/guides/vps-backup-strategy.webp?v=1787218773",
    "author": {
        "@type": "Organization",
        "@id": "https://servhidden.com/#editorial",
        "name": "ServHidden Editorial",
        "url": "https://servhidden.com/about",
        "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.",
        "knowsAbout": [
            "Offshore hosting jurisdictions",
            "Data retention law",
            "MLAT and judicial cooperation",
            "WireGuard and OpenVPN deployment",
            "Tor relay operation",
            "Monero and Bitcoin payment privacy",
            "KVM virtualization and bare-metal hosting",
            "DMCA-ignored hosting"
        ],
        "parentOrganization": {
            "@id": "https://servhidden.com/#organization"
        }
    },
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "datePublished": "2026-08-20T00:00:00+00:00",
    "dateModified": "2026-08-20T00:00:00+00:00",
    "mainEntityOfPage": "https://servhidden.com/guides/vps-backup-strategy",
    "inLanguage": "it",
    "keywords": "backup VPS, backup VPS crittografato, restic vs BorgBackup, backup offsite VPS, regola 3-2-1 backup, backup append-only, backup server senza KYC, test di ripristino backup",
    "articleSection": "Operaciones",
    "wordCount": 3749
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
        {
            "@type": "Question",
            "name": "ServHidden fa il backup del mio VPS?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "No, ed è una scelta deliberata, non una dimenticanza. La nostra policy di conservazione afferma che non viene conservato alcun backup, che i dati del server vengono distrutti entro 24 ore dalla terminazione, e che i dischi vengono cancellati crittograficamente invece che formattati. Conservare una copia dei tuoi dati dopo che ci hai chiesto di rimuoverli contraddirebbe il motivo per cui questa piattaforma esiste. Tutto ciò che vuoi far sopravvivere al server devi copiarlo tu stesso, idealmente verso un secondo provider in una seconda giurisdizione."
            }
        },
        {
            "@type": "Question",
            "name": "Uno snapshot è la stessa cosa di un backup?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "No. Uno snapshot condivide ogni dominio di guasto con il server da cui proviene — lo stesso provider, lo stesso account, lo stesso paese, spesso lo stesso storage. È eccellente per annullare un aggiornamento andato male, ed è inutile contro la perdita dell'account, del provider o della macchina. Tratta gli snapshot come un tasto «annulla» e i backup come un'assicurazione; risolvono problemi diversi e ti servono entrambi."
            }
        },
        {
            "@type": "Question",
            "name": "restic o BorgBackup: quale devo usare?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "restic se il target potrebbe essere object storage, SFTP o qualcosa che non hai ancora scelto, perché parla con il maggior numero di backend. BorgBackup se il target è un'unica macchina Linux raggiunta via SSH e i dati sono grandi e ripetitivi, perché la sua deduplicazione è la più forte del gruppo. Entrambi cifrano alla fonte prima che qualsiasi cosa lasci la macchina, ed entrambi supportano un target append-only, il che conta molto più della scelta tra i due."
            }
        },
        {
            "@type": "Question",
            "name": "Come impedisco a un attaccante di cancellare i miei backup?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Elimina la capacità, non il movente. O rendi il target append-only, così le credenziali sul server di produzione possono aggiungere dati ma mai rimuoverli, oppure inverti la connessione così che l'host di backup faccia il pull dalla produzione e il server di produzione non custodisca alcuna credenziale. Cancellare i backup prima di farsi notare è prassi standard per chi lo fa a livello commerciale, e una copia che il tuo attaccante può cancellare non è una seconda copia."
            }
        },
        {
            "@type": "Question",
            "name": "Dove deve stare la seconda copia di backup?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Presso un provider diverso, in una giurisdizione diversa, e pagata in modo altrettanto privato del tuo server di produzione. Gli eventi che eliminano entrambe le copie insieme raramente sono fisici — sono un account a cui hai perso l'accesso, un provider che ha avuto una brutta settimana, o uno strumento legale che raggiunge un paese e non un altro. Due server nello stesso rack sono una copia con passaggi in più. Poiché gli strumenti cifrano alla fonte, il secondo host non deve essere uno di cui ti fidi."
            }
        },
        {
            "@type": "Question",
            "name": "Ogni quanto devo fare il backup?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Ragiona a ritroso partendo da quanto lavoro sei disposto a rifare. Un blog può perdere un giorno senza che nessuno se ne accorga; un negozio non può perdere un'ora di ordini. Ogni notte è la scelta predefinita giusta per la maggior parte delle configurazioni a server singolo, con dump del database più frequenti se le scritture hanno valore. Ciò che conta più della frequenza è la profondità della retention: la corruzione spesso si nota con settimane di ritardo, quindi conserva abbastanza cronologia da poter tornare a un punto precedente al suo inizio."
            }
        },
        {
            "@type": "Question",
            "name": "Un backup cifrato è sicuro su un server che non controllo?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Per il contenuto, sì — restic e Borg cifrano prima che i dati lascino la fonte, quindi il target memorizza blob che non può leggere e la chiave non viaggia mai. Quello che il target impara è il metadato: più o meno quanti dati conservi, come cambiano, e quando girano i tuoi job. Di solito è accettabile. Se non lo è, varia la pianificazione e tieni il repository su una macchina la cui proprietà non è collegata a quella di produzione."
            }
        },
        {
            "@type": "Question",
            "name": "Cosa succede se perdo la passphrase del backup?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "L'archivio è perso, permanentemente, senza alcun rimedio da parte di nessuno. È la perdita totale più comune di tutto l'argomento, e l'unico guasto senza un percorso di recupero. Tieni la passphrase lontano da ogni macchina coinvolta, preferisci la carta a un account che potresti perdere anche tu, e aggiungi una seconda chiave al repository così che una password dimenticata sia un fastidio e non la fine dell'archivio."
            }
        }
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
        {
            "@type": "ListItem",
            "position": 1,
            "name": "Home",
            "item": "https://servhidden.com/it/"
        },
        {
            "@type": "ListItem",
            "position": 2,
            "name": "Guide di Hosting Privato",
            "item": "https://servhidden.com/it/guides"
        },
        {
            "@type": "ListItem",
            "position": 3,
            "name": "Backup VPS: Strategia Cifrata, Offsite e Che Funziona Davvero",
            "item": "https://servhidden.com/it/guides/vps-backup-strategy"
        }
    ]
}
```