Ripristinare da un backup

Hai un pacchetto .tar.gz che avevi salvato in precedenza (o che ti ha inviato un collega, oppure che è appena arrivato da un altro server). Qui trovi come rimetterlo online come servizio in esecuzione: nella posizione originale (sovrascrivendo l’originale, se esiste ancora) oppure come clone su un nuovo dominio.

Cerchi come creare i backup? È un articolo separato: Backup: quale scegliere e come usarlo. Questo parte da “ho già un pacchetto sul mio computer”.

Da dove avviare il ripristino: tre punti di ingresso

Stesso flusso, tre porte. Scegli quella più adatta al punto da cui parti. (Due porte usano il Menu Azioni nella barra superiore: fai clic sul termine per vedere dov’è.)

Le tre porte aprono tutte la stessa finestra Ripristina da un backup. Cambia solo il contesto che Server Manager ha nel momento in cui la apri:

• Da un pannello servizio, la finestra sa quale ricetta + servizio ti aspetti: se il pacchetto caricato ha una struttura diversa (per esempio hai aperto il pannello WordPress ma hai caricato un pacchetto Postgres), mostra un avviso così puoi scegliere un altro file prima che venga eseguito qualsiasi comando.
• Dal menu Azioni, non c’è nessuna aspettativa: viene ripristinato ciò che il pacchetto dichiara di essere.
• Da un trasferimento in arrivo, il pacchetto è già sul server; la finestra offre un pulsante Ripristina questo pacchetto con un solo clic.

La procedura

Scegli il punto di ingresso adatto alla tua situazione (vedi la tabella sopra). La finestra è uguale in tutti e tre i casi:

Trascina il file .tar.gz nell’area di caricamento, oppure fai clic in un punto qualsiasi dell’area per aprire il selettore file. La finestra accetta file che terminano con .tar.gz o .tgz.

Fai clic su Carica. Una barra di avanzamento sostituisce l’area di caricamento mentre il pacchetto viene inviato al server (caricamento a blocchi: anche pacchetti da molti GB reggono connessioni instabili).

Che cosa viene caricato? Il tuo computer invia i byte del file .tar.gz al server tramite uno stream in stile SFTP, cifrato dalla sessione SSH a cui sei connesso. Il file arriva in /tmp/helm-restore/<id>/<bundle>.tar.gz e resta lì finché il ripristino non termina; poi viene eliminato.

Quando il caricamento finisce, la finestra si chiude e Faro ti saluta in chat con il riepilogo del manifest letto dal pacchetto: titolo sorgente, dominio sorgente, ricetta e data/ora del backup. Poi ti fa una sola domanda breve:

Vuoi ripristinare nella posizione originale (sovrascrivendo il <name> esistente, se è ancora presente) oppure clonare su un nuovo dominio (lasciando intatto l’originale e creando una copia separata)?

Questo è l’unico punto in cui devi decidere. Da qui in poi, la tua risposta determina il resto dei passaggi.

4a. Ripristinare nella posizione originale

Scegli questa opzione quando:

• Il servizio originale non c’è più (è stato eliminato, oppure sei su un server nuovo) e vuoi riportarlo online con lo stesso dominio e gli stessi nomi.
• L’originale è rotto o configurato male e vuoi cancellarlo e ricrearlo dal pacchetto.

Cosa fa Faro:

1. Legge docker-compose.yml e .env dal pacchetto e li ricrea nel percorso di installazione originale.
2. Ripristina ogni volume Docker con nome (dati del database, file caricati, ecc.) dai volumi inclusi nel pacchetto.
3. Per i siti statici, copia di nuovo l’albero dei file sotto /var/www/<domain>/.
4. Riapplica il blocco Caddyfile così il dominio originale torna a servire il sito.
5. Avvia il servizio ed esegue un controllo di stato.

Ogni comando si ferma per chiederti conferma prima di partire: la chat mostra le righe esatte docker compose up, tar xzf, caddy reload che stai per eseguire.

4b. Clonare su un nuovo dominio

Scegli questa opzione quando:

• Vuoi che l’originale continui a funzionare mentre una copia viene pubblicata su un dominio diverso (staging, dev, demo, seconda attività…).
• Stai ripristinando su un server a cui punta un dominio diverso da quello sorgente del pacchetto.

Faro fa una domanda in più: qual è il nuovo dominio? (per esempio staging.example.com).

Cosa fa Faro in aggiunta ai passaggi del ripristino nella posizione originale:

1. Sceglie un nuovo nome progetto compose (così i container del clone non entrano in conflitto con quelli dell’originale), per esempio mysite-com → staging-example-com.
2. Riscrive la voce del Caddyfile per usare il nuovo dominio.
3. Rigenera i segreti in .env (nuova password DB, nuove chiavi app): il clone non condivide le credenziali con l’originale.
4. Per WordPress, esegue wp search-replace <old-domain> <new-domain> dentro il container clonato, così i link nei post e nei metadati dei media puntano al nuovo dominio.
5. Per le web app, aggiorna eventuali variabili d’ambiente *_URL / *_HOST che puntano al vecchio dominio.
6. Richiede un nuovo certificato TLS per il nuovo dominio (Let's Encrypt via Caddy, automatico).

L’originale continua a funzionare senza essere toccato.

Stai clonando un database? I database non hanno un dominio. Faro chiede invece un suffisso breve (come staging o qa) e lo usa per derivare un nome progetto compose, un nome container e una porta di ascolto univoci, così entrambi i DB possono funzionare affiancati senza conflitti.

Quando i passaggi finiscono, Faro mostra l’URL finale (clone) oppure il dominio appena ripristinato (posizione originale). Aprilo nel browser; se non si carica subito, aspetta 30–60 secondi perché Let's Encrypt emetta il certificato e riprova.

Il pacchetto originale viene rimosso automaticamente da /tmp/helm-restore/ quando il ripristino termina correttamente.

Ricetta non corrispondente

Se hai aperto la finestra di ripristino da un pannello servizio (per esempio il pannello WordPress di mysite.com) e hai caricato un pacchetto di una ricetta diversa (per esempio un pacchetto Postgres), la finestra non procede alla cieca: ti avvisa.

Hai due possibilità:

• Scegli un altro file: quasi sempre è quello che vuoi fare (hai preso il pacchetto sbagliato).
• Usa comunque questo pacchetto: è il pacchetto a guidare il ripristino, quindi verrà configurato un nuovo servizio basato sulla ricetta del pacchetto, NON verrà modificato quello del pannello che avevi aperto. Sceglilo solo se lo sai e lo vuoi davvero.

Il controllo di corrispondenza scatta solo quando la finestra è stata aperta da un pannello servizio con una ricetta attesa. Il percorso Azioni → Ripristina lo salta del tutto (non c’è nessuna aspettativa da verificare).

Ripristino automatico dopo uno spostamento da server a server

Se su un altro server hai usato scheda Backup → Sposta su un altro server e questo ha trasferito qui un pacchetto, la finestra di ripristino si apre automaticamente con quel pacchetto evidenziato in alto:

Fai clic su Ripristina questo pacchetto e da lì in poi il resto del flusso è identico a un ripristino nuovo (Faro chiede posizione originale o clone, tu approvi i comandi, ecc.). Il pacchetto è già sul server, quindi non c’è il passaggio di caricamento.

Puoi anche fare clic su Usa un pacchetto diverso… per chiudere il precaricamento e aprire il normale selettore file: utile se hai trasferito il pacchetto sbagliato e vuoi ricominciare.

Domande comuni

Dove resta l’originale durante una clonazione? Intatto. Il clone usa nomi container diversi, volumi diversi, porte diverse (per i database) e segreti diversi. Puoi eliminare il clone in seguito senza toccare l’originale.

Posso ripristinare un pacchetto su una distribuzione Linux diversa? Sì. Il pacchetto è solo Docker compose + volumi con nome + (per i siti statici) un albero di file. Server Manager gestisce l’installazione di Docker specifica per la distribuzione di destinazione, se manca. L’eccezione sono i pacchetti di web app native (non in container): dipendono dal gestore pacchetti e da systemd della distribuzione sorgente, e l’articolo di ripristino ti dirà se non può tradurre l’installazione.

Il pacchetto è enorme: il caricamento andrà in timeout? No. Il caricamento è a blocchi (~4 MB per blocco) e il server li ricompone. I pacchetti da molti GB funzionano; se la connessione cade a metà caricamento, la finestra ti permette di annullare e ricominciare invece di ripartire da zero a ogni blocco.

E se annullo a metà ripristino? Se annulli durante il caricamento, il file parziale viene eliminato e torni all’area di caricamento. Se annulli durante i passaggi in chat (tra una conferma e l’altra), rimane ciò che Faro ha già fatto: potrebbero esistere alcuni container, alcuni volumi, ecc. Puoi rieseguire il ripristino dallo stesso pacchetto, oppure chiedere prima a Faro di pulire lo stato parziale; se qualcosa ti sembra strano, chiedi in chat e Faro farà la diagnosi.

Posso ripristinare lo stesso pacchetto più volte come cloni diversi? Sì. Riapri la finestra, carica lo stesso pacchetto, scegli clona ogni volta con un nuovo dominio diverso. Il pacchetto resta valido per sempre (è solo un tarball).

Dove restano i file dei ripristini non riusciti? In /tmp/helm-restore/<id>/ sul server di destinazione. Il menu Azioni della schermata iniziale mostra le directory helm-restore orfane nella vista di pulizia, se ne rimane qualcuna. Puoi eliminarle in sicurezza.

Cosa NON rientra qui

• **File .helm-backup/** (annullamento per singolo file nella scheda File) → vedi la sezione “Recuperare un singolo file” dell’articolo Backup.
• **Dump DB grezzi .sql.gz** (caricabili in qualsiasi Postgres/MySQL) → vedi la sezione “Fare il backup del solo database” dell’articolo Backup.
• Ripristino tra ricette diverse (per esempio un pacchetto WordPress come sito statico): i pacchetti sono specifici per ricetta. Scegli un pacchetto che corrisponda a ciò che vuoi riportare online.

Riferimento

Cosa serve al ripristino sul server di destinazione:

• Il server Linux raggiungibile via SSH a cui sei connesso in Server Manager.
• Spazio su disco per estrarre il pacchetto (circa 2× la dimensione del pacchetto, per poco tempo, durante l’estrazione).
• Docker installato (Server Manager lo installa automaticamente se manca su una destinazione nuova).

Percorsi su disco durante il ripristino:

• Pacchetto caricato (temporaneo) → /tmp/helm-restore/<id>/<name>.tar.gz
• Sorgente estratta → /tmp/helm-restore/<id>/extracted/
• Installazione finale: lo stesso percorso usato dall’originale (per esempio /opt/wordpress-mysite-com/, /var/www/mysite.example.com/, …)

L’albero decisionale in breve: