Ripristina un backup dalla riga di comando

[Discourse]

Questa guida spiega come ripristinare un backup di Discourse dalla riga di comando senza utilizzare l’interfaccia web di Discourse.
Livello utente richiesto: Amministratore
Accesso alla console richiesto

Ecco come ripristinare un backup di Discourse dalla riga di comando, senza avviare mai l’interfaccia web di Discourse. Questo è utile quando si sta cambiando server.

Prerequisiti

Prima di iniziare, assicurati di completare i seguenti passaggi:

1. Scarica l’ultimo file di backup dall’istanza Discourse di origine.
2. Avvia l’istanza Discourse di destinazione eseguendo ./discourse-setup o copiando il tuo file app.yml esistente.
3. Assicurati che l’istanza Discourse di destinazione sia aggiornata all’ultima versione. Aggiornala se necessario.

Trasferisci il backup

1. Accedi al server di destinazione tramite SSH, o crea la cartella di backup lì in altro modo:

mkdir -p /var/discourse/shared/standalone/backups/default

2. Carica il tuo file di backup sul server di destinazione.

scp /path/to/backup/backup.tar.gz root@192.168.1.1:/var/discourse/shared/standalone/backups/default

Assicurati di sostituire i percorsi, i nomi dei file e i nomi dei server con quelli che stai utilizzando – ma vuoi che il file di backup finisca in:

/var/discourse/shared/standalone/backups/default

Puoi anche caricare e scaricare il tuo file di backup di Discourse da siti di archiviazione web popolari come Google Drive, Dropbox, OneDrive, ecc. – dovrai cercare le istruzioni specifiche della riga di comando in base al tuo provider di archiviazione web preferito.

NON CAMBIARE IL NOME DEL FILE DI BACKUP! Discourse tratta il nome del file di backup come metadati, quindi se modifichi il nome del file, il ripristino non funzionerà. Mantieni il nome originale del file.

Sostituisci /path/to/backup/discourse-xyz.tar.gz con il percorso locale del tuo file di backup e sostituisci \u003cserver_ip_address\u003e con l’indirizzo IP del server di destinazione.

Se Nginx è usato come proxy inverso (Running other websites on the same machine as Discourse) assicurati che tutti i percorsi verso il backup siano leggibili dal container e che Nginx possa leggere il file .sock.

Ripristina il backup

1. Accedi al tuo server di destinazione e naviga nella cartella Discourse:

cd /var/discourse

2. Accedi al container dell’app Docker di Discourse:

./launcher enter app

3. Abilita la funzionalità di ripristino:

discourse enable_restore

4. Ripristina il file di backup:

discourse restore sitename-2019-02-03-042252-v20190130013015.tar.gz

Suggerimento: Se esegui discourse restore senza un nome file, elencherà tutti i file di backup disponibili.

Se l’impostazione backup_location del tuo sito è configurata per utilizzare S3, ma hai caricato manualmente il file di backup nel filesystem locale, devi specificare --location local:

discourse restore --location local sitename-2019-02-03-042252-v20190130013015.tar.gz

Allo stesso modo, usa --location s3 per ripristinare direttamente da un backup S3 senza scaricarlo prima.

5. Esci dal container dell’app Docker di Discourse:

exit

Ricostruisci

Dopo aver ripristinato il backup, potresti scegliere di ricostruire l’istanza di destinazione per assicurarti che tutte le impostazioni e le configurazioni vengano applicate correttamente.

Ora è un buon momento per aggiornare /var/discourse/containers/app.yml con HTTPS completo, plugin aggiuntivi o configurazione CDN. Confronta la configurazione di app.yml di entrambe le istanze per esserne sicuro!

cd /var/discourse
./launcher rebuild app

Abilita Email

Quando viene ripristinato un backup, la posta in uscita per gli utenti non staff viene disabilitata. Non vuoi che il tuo server di prova, il nuovo server o il server su cui hai appena ripristinato un backup per qualsiasi altro motivo inizi a inviare email ai tuoi utenti! Cambia l’impostazione del sito disable_emails in “no” per riabilitare le email.

Ecco fatto. Il tuo server Discourse è stato ripristinato con successo.

[gregcaporaso]

Queste istruzioni hanno funzionato per il ripristino dal backup, ma abbiamo dovuto modificare il comando discourse restore in:

discourse restore --location local sitename-2019-02-03-042252-v20190130013015.tar.gz

(il mio esempio utilizza il nome del file dall’esempio sopra) per far sì che il ripristino trovasse i backup che avevamo inserito nella directory /var/discourse/shared/standalone/backups/default (a differenza dei backup archiviati su s3).

[Isambard]

La ricostruzione dopo il ripristino è necessaria?

Inoltre, ho ripristinato su un nuovo server dove c’è un proxy inverso NGINX che poi inoltra al discourse upstream. Pertanto, ho disabilitato SSL su discourse, ma ho notato che durante il ripristino:

Rimappatura di 'https://example.com' in 'http://example.com'

Questa rimappatura riguarda tutti i link interni? È semplice annullare questa operazione con discourse remap http://example.com https://example.com?

[pfaffman (Jay Pfaffman)]

@Isambard

La ricostruzione dopo il ripristino è necessaria?

No.

@Isambard

Questo rimappa tutti i collegamenti interni?

Sembra di sì. Sì, puoi rimapparli.

Dovresti impostare la variabile force_https.

[pinder99 (Pushpender Singh)]

Se il backup è di 15 GB, quanto spazio è necessario per ripristinare?

[pfaffman (Jay Pfaffman)]

È solo il database o anche i caricamenti?

Probabilmente 3-5 volte tanto.

[pinder99 (Pushpender Singh)]

è database+upload 15gb, ho 20gb di spazio su HD da 60gb ma il ripristino fallisce ogni volta, ho bisogno di almeno 50-60gb di spazio per ripristinare?

[pfaffman (Jay Pfaffman)]

È necessario disporre di spazio sufficiente per il backup, i caricamenti e il database non compresso.

Potresti provare prima a ripristinare solo il backup del database e quindi copiare i caricamenti manualmente con rsync.

[Ethsim2 (Ethan)]

Ho verificato il mio account amministratore sull’host autonomo e ho caricato un backup .sql.gz, non un .tar.gz.

Il ripristino nell’interfaccia utente non è proficuo, quindi l’ho eseguito dalla “Ripristina il backup” dalla riga di comando, ottenendo [FAILED] alla fine del processo discourse restore, potrebbe il file di input da un hosting ufficiale essere .tar.gz causare il superamento del processo?

Il mio hosting ufficiale ha pochi giorni e il mio host autonomo ha iniziato a funzionare correttamente oggi dopo aver modificato i valori SMTP in container.yml.

[pfaffman (Jay Pfaffman)]

Dovrai includere quale errore hai ricevuto. Il nome del file contiene informazioni sulla versione, quindi se hai rinominato il file, probabilmente dovrai rinominarlo di nuovo, modificando solo le parole all’inizio del nome del file.

[helmi]

C’è qualche documentazione per discourse restore da qualche parte? Poiché sembra esserci un’interruttore --location local, presumo ci sia anche uno per S3?

Sto cercando di ripristinare da backup situati su S3 evitando di doverli scaricare manualmente in anticipo.

MODIFICA: niente. Ho scoperto che discourse restore --location s3 $nomefile sembra funzionare abbastanza bene.

[Jagster (Jakke Flemming)]

Poiché ho abilitato S3 in app.yml, un semplice discourse restore <filename> ha funzionato perfettamente.

Penso che se cerchi backup restore s3 troverai il post giusto.

[Ethsim2 (Ethan)]

Ciao, ho completato questo processo utilizzando s3(-cli) come mio scp e una modifica del provider di posta in uscita da MailGun a Brevo

Dopo il ripristino non riesco a trovare un modo per rimuovere il banner?

[Moin]

@Discourse

Il processo di ripristino imposta automaticamente l’impostazione disabilita email su “non staff”, in modo che le email non vengano inviate agli utenti del tuo sito finché non sei pronto.

Il modo più semplice per rimuovere il banner è abilitare le email nelle impostazioni del sito

[pfaffman (Jay Pfaffman)]

@Moin

Il modo più semplice per rimuovere il banner è abilitare le email nelle impostazioni del sito

Giusto. Potresti anche nasconderlo con il CSS!

[Moin]

Vero. Ero un po’ cauto nel consigliarlo perché ho dovuto pensare a Air theme hides "outgoing email disabled" warning

[pfaffman (Jay Pfaffman)]

@Moin

Ero un po’ cauto nel consigliarlo perché ho dovuto pensare a Air theme nasconde l’avviso “email in uscita disabilitata”

Ogni volta che ripristini un backup, l’email viene automaticamente disabilitata per i non staff. Immagino che questo sia stato aggiunto al codice solo un paio di volte dopo che un ripristino è stato effettuato su un server di test che ha iniziato a inondare i suoi utenti con notifiche per un server di cui non avrebbero dovuto essere a conoscenza.

Ho aggiornato l’OP di conseguenza:

@Discourse

Abilita Email

Quando viene ripristinato un backup, la posta in uscita per i non staff viene disabilitata. Non vorrai che il tuo server di test, il nuovo server o il server per cui hai appena ripristinato un backup per qualsiasi altro motivo inizi a inviare email ai tuoi utenti! Cambia l’impostazione del sito “disable_emails” per riabilitare l’email.

[thoka (Thomas Kalka)]

Nota per la guida:

Se ripristini regolarmente i backup a scopo di test e il tuo server di test è configurato correttamente, per inviare e-mail a un servizio di debug e-mail (come GitHub - maildev/maildev: 📫 SMTP Server + Web Interface for viewing and testing emails during development.) potresti voler abilitare le e-mail tramite scripting:

docker exec -it app /bin/bash --login \
-c "rails runner 'SiteSetting.disable_emails=\"no\";'"

[pfaffman (Jay Pfaffman)]

In tal caso, potresti voler impostare DISCOURSE_DISABLE_EMAILS su no nel tuo app.yml. (e anche DISCOURSE_ENABLE_RESTORE per rendere più facile il ripristino)