Guida pratica / Recupero dei file

Backup di un VPS Ubuntu: prova il ripristino dei file

Un backup del VPS Ubuntu serve quando puoi recuperarlo fuori dal server e ritrovare i file attesi. Questa prova archivia una pagina statica e una configurazione Nginx, le copia su un altro computer e verifica i byte ripristinati senza modificare il sito attivo.

Indice

Definisci l’ambito della prova

Servono Bash, GNU tar, sha256sum e OpenSSH su Ubuntu o su un client Linux/WSL. Usa un terminale server e uno client su un computer separato. Lasciali aperti: le variabili appartengono alla rispettiva sessione. Fermati dopo qualsiasi errore di comando.

L’esercizio usa due file temporanei nella home. Non modifica Nginx, firewall o contenuto pubblico e non estrae archivi come root. Parti dai file di prova; la sostituzione opzionale usa solo i due file della prima pubblicazione HTTPS.

Per un sito più ampio inventaria separatamente risorse, redirect, configurazioni incluse, DNS e dipendenze. Questi due file non rappresentano una copia completa della macchina o dell’applicazione.

Prepara i file senza cambiare il sito

Nel terminale server crea una cartella privata. La configurazione qui sotto è un file da archiviare, non un servizio da attivare.

umask 077
backup_lab=$(mktemp -d "$HOME/ubuntu-vps-backup.XXXXXX")
mkdir -p "$backup_lab/payload/site" "$backup_lab/payload/nginx" "$backup_lab/export"
printf '%s\n' '<!doctype html><html lang="it"><title>Prova di ripristino</title><h1>Pagina statica recuperata</h1></html>' > "$backup_lab/payload/site/index.html"
printf '%s\n' 'server {' '    listen 8080;' '    server_name example.test;' '    root /var/www/first-site;' '}' > "$backup_lab/payload/nginx/first-site.conf"
printf 'Cartella della prova: %s\n' "$backup_lab"

Facoltativo: per usare la vera pagina e il server block della guida, sostituisci soltanto queste copie temporanee. Le due sorgenti devono essere leggibili dal tuo account. Controlla che non contengano segreti e sospendi le pubblicazioni durante la raccolta per copiare lo stesso rilascio. Salta questo blocco se usi i file di prova.

install -m 600 /var/www/first-site/index.html "$backup_lab/payload/site/index.html"
install -m 600 /etc/nginx/sites-available/first-site "$backup_lab/payload/nginx/first-site.conf"

I comandi leggono le sorgenti senza modificarle. Non copiano chiavi private TLS né intere directory di sistema. Per un sito reale aggiungi deliberatamente i file mancanti sia all’inventario sia al manifesto dei checksum.

Crea l’archivio e due livelli di verifica

Nella stessa sessione server calcola i checksum dei file, crea l’archivio con percorsi relativi e calcola il checksum dell’archivio. Non cambiare i file durante questa operazione.

(
    cd "$backup_lab/payload" &&
    sha256sum site/index.html nginx/first-site.conf > SHA256SUMS
)
tar -czf "$backup_lab/export/static-site.tar.gz" -C "$backup_lab/payload" site nginx SHA256SUMS
(
    cd "$backup_lab/export" &&
    sha256sum static-site.tar.gz > static-site.tar.gz.sha256
)
tar -tzf "$backup_lab/export/static-site.tar.gz"
printf 'Cartella di esportazione sul server: %s\n' "$backup_lab/export"

L’elenco deve contenere site/, nginx/, i due file e SHA256SUMS. Annota la cartella di esportazione stampata. Il checksum esterno rileva cambiamenti dell’archivio trasferito; quello interno verifica i file estratti.

Nessuno dei due autentica la copia se qualcuno può sostituire sia dati sia checksum atteso. Proteggi sorgente, accessi e destinazione.

Trasferisci su un computer separato

Nel terminale locale assegna a remote_backup la cartella esatta stampata dal server. Sostituisci indirizzo, account e chiave con i dati SSH funzionanti. 203.0.113.10 è un esempio per documentazione; REPLACE non è il suffisso realmente generato da mktemp.

umask 077
recovery_dir=$(mktemp -d "$HOME/ubuntu-vps-restore.XXXXXX")
remote_backup=/home/deploy/ubuntu-vps-backup.REPLACE/export
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz" "$recovery_dir/"
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz.sha256" "$recovery_dir/"

Prima di accettare un nuovo host verifica l’impronta attraverso un canale attendibile. Se il trasferimento fallisce per SSH, segui la diagnosi della connessione senza disabilitare il controllo della chiave host.

SCP protegge il trasferimento tramite SSH. tar.gz è compresso, non cifrato: proteggi account e storage di destinazione e usa cifratura a riposo quando necessaria. Una seconda cartella sullo stesso VPS non è una copia esterna.

Verifica ed estrai in una cartella nuova

Nella stessa sessione client controlla prima l’archivio. Continua soltanto dopo OK da sha256sum.

(
    cd "$recovery_dir" &&
    sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"

Se la somma non coincide, investiga o ripeti il trasferimento: non riscrivere quella attesa per nascondere l’errore. Estrai questo archivio attendibile in una directory appena creata e vuota.

restore_dir=$(mktemp -d "$recovery_dir/restored.XXXXXX")
tar -xzf "$recovery_dir/static-site.tar.gz" -C "$restore_dir" --keep-old-files --no-same-owner
(
    cd "$restore_dir" &&
    sha256sum -c SHA256SUMS
)
cat "$restore_dir/site/index.html"

keep-old-files rifiuta di sostituire file esistenti; no-same-owner evita di ripristinare il proprietario archiviato. Non cambiare la destinazione in / e non usare sudo.

Attendi OK per site/index.html e nginx/first-site.conf, poi il titolo della pagina recuperata. Verifichi il contenuto dei file, non proprietari di produzione, ACL, disponibilità del servizio o tutte le dipendenze.

Distingui recupero dei file e ritorno del servizio

La configurazione recuperata è ancora un file inattivo. Sul server sostitutivo controlla percorsi, include, moduli, permessi e certificati. Valida lì la configurazione Nginx completa prima del reload e prova HTTP/HTTPS dall’esterno. Controllare il vecchio server immutato non valida la copia recuperata.

L’archivio esclude deliberatamente le chiavi TLS private. Pianifica riemissione o copia separata protetta dei certificati. Per un database attivo usa la sua procedura coerente di backup e ripristino, non tar dei file in uso.

Gli snapshot del provider possono aiutare, ma verifica conservazione, dipendenza dalla stessa infrastruttura e procedura di ripristino. Uno snapshot presente non dimostra che i file esportati funzionino su un altro host.

Registra obiettivi e risultato completo

RPO esprime la perdita di dati accettabile in tempo; RTO il tempo obiettivo per ripristinare il servizio. Per un piccolo sito informativo potresti scegliere RPO di 24 ore e RTO di 60 minuti. Sono obiettivi illustrativi, non risultati misurati da questa prova. Copie giornaliere servono solo se riescono e rimangono recuperabili.

Scorri la tabella per vedere le altre colonne →

RegistroCosa dimostra
Ora della copia e rilascioQuale versione puoi recuperare
Destinazione indipendente e conservazioneDove sopravvive la copia e per quanto
Checksum di archivio e fileSe i byte selezionati sono stati recuperati
Inizio e fine del ripristinoDurata dei passi eseguiti
File, permessi o dipendenze mancantiLavoro necessario per riattivare il servizio
Controllo HTTPS sul nuovo serverSe il sito è effettivamente tornato

Misura l’intera sostituzione prima di considerare raggiungibile l’RTO: accesso, creazione VM, configurazione, dati, certificati e DNS. Un’estrazione locale rapida non misura il recupero da un’interruzione. Conserva punti di ripristino adatti e sorveglia i job falliti. Nel confronto dell’hosting includi conservazione e assistenza al recupero.

Domande e risposte

Devo cancellare il sito originale per provare la copia?

No. Estrai in un’altra cartella vuota e verifica il manifesto. Prova il servizio completo in un ambiente sostitutivo separato senza creare un’interruzione.

Un checksum corretto dimostra che il sito intero è salvato?

Conferma solo i file nel manifesto. Non individua dati, segreti, asset o DNS omessi. Mantieni un inventario e verifica le funzioni reali dopo il recupero.

Il file tar.gz è cifrato?

No. SCP protegge il trasferimento, ma l’archivio è soltanto compresso. Proteggi lo storage e applica cifratura a riposo se i dati lo richiedono.

Il flusso locale dei file di prova, archivio e checksum è stato verificato con strumenti GNU in Git Bash su Windows. Quella prova non ha esercitato un server Ubuntu, il trasferimento SSH remoto, i certificati o l’attivazione di Nginx.
Attività collegate

Qual è il prossimo passo?