Come eseguire il backup e il ripristino dell'intera cartella dell'app /var/discourse?

Come eseguire il backup e il ripristino dell’intera cartella /var/discourse?

A causa di problemi con il processo abituale di backup e ripristino, mi chiedevo se fosse possibile eseguire il backup dell’intera cartella /var/discourse e riutilizzarla su un altro server. Ecco cosa ho fatto…

Sul server di produzione:

rsync_opts="\
   --recursive \
   --links \
   --hard-links \
   --safe-links \
   --owner \
   --group \
   --perms \
   --times \
   --delete \
   --sparse \
   --compress \
   --partial \
   --rsh=ssh
"
dir=/var/discourse
rsync  $rsync_opts "$dir/" root@xx.xx.xx.xx:"/var/production-backup/$dir"

Sul server di staging:

Installa Docker.

rsync --recursive --links --hard-links --safe-links --owner --group --perms --times --delete --sparse --compress --partial /var/production-backup/var/discourse/ /var/discourse

Ma ricevo 502 Bad Gateway.

Sto cercando di indagare.

cd /var/discourse

./launcher start app

root@whonix-app:/var/www/discourse# service postgresql status
12/main (port 5432): down
root@whonix-app:/var/www/discourse# service postgresql start
[....] Avvio del server di database PostgreSQL 12: main[....] Errore: Il cluster è di proprietà [FAIL] dell'utente 116 che non esiste ... fallito!
 fallito!

Provo alcune correzioni:

chown -R postgres.postgres /etc/postgresql
chown -R postgres.postgres /shared/postgres_*
chown -R postgres.postgres /var/lib/postgresql
chown -R postgres.postgres /var/log/postgresql
chown -R redis.redis /etc/redis/redis.conf
chown -R redis.redis /shared/redis_data
chown -R redis.redis /var/run/redis
chown -R redis.redis /var/lib/redis
chown -R redis.redis /var/log/redis
chgrp -R ssl-cert /etc/ssl/private

Ma non hanno funzionato.

root@whonix-app:/var/www/discourse# service postgresql start
[....] Avvio del server di database PostgreSQL 12: main[....] Errore: /usr/lib/postgresql/12/bin/pg_ctl /usr/lib/postgresql/12/bin/pg_ctl start -D /shared/postgres_data -l /var/log/postgresql/postgresql-12-main.log -s -o -c config_file="/etc/postgresql/12/main/postgresql.conf" è uscito con stato 1: 2020-05-25 10:20:10.501 UTC [603] FATAL: i file del database sono incompatibili con il server 2020-05-25 10:20:10.501 UTC [603] DETAIL: La directory dei dati è stata inizializzata con PostgreSQL versione 10, che non è compatibile con questa versione 12.2 (Debian 12.2-2.pgdg100+1). pg_ctl: impossibile avviare il server. Esaminare l'output del log. ... fallito!
 fallito!

Perché sono stati introdotti questi problemi di permessi sui file?

Perché PostgreSQL viene aggiornato dalla versione 10 alla versione 12 semplicemente copiando l’intera cartella da un server all’altro? Devo stare facendo qualcosa di sbagliato.

Potreste gentilmente condividere le istruzioni su come eseguire il backup dell’intera applicazione Discourse su un server e spostarla su un altro server?

Discourse non utilizza Phabricator?

Refuso. Intendevo Discourse. Refuso corretto. La domanda originale rimane.

Questo non sposta l’intera cartella /var/discourse. Conosco queste istruzioni, ma non funzionano per me. Per questo motivo volevo un metodo di backup più “completo”, una copia “hard” 1:1.

Puoi spegnere il container e copiare l’intero contenuto su un nuovo server, escludendo le directory tmp, backup e cache (e penso ce ne sia un’altra?). Dovrebbe funzionare. L’ho fatto recentemente, credo per un motivo simile.

Ma devi comunque risolvere il problema dell’indice rotto.

Penso che la versione di Docker stia introducendo delle differenze. (Che poi hanno portato al fallimento.)

Server originale
docker-engine 17.05.0~ce-0~debian-stretch

vs server più recente (stage)
docker-engine 17.05.0~ce-0~debian-stretch

Ciò comporta che il server originale abbia la versione 10 di PostgreSQL, mentre il server più recente (stage) abbia già PostgreSQL 12.

È obbligatorio? C’è un modo più semplice? Perché sarebbe necessario non copiare tutto così com’è e ripristinare?

Portando a problemi di permessi che non riesco a spiegare. Dovrebbe essere possibile copiare senza rompere i permessi. Inoltre, non sono sicuro di aver risolto tutti i problemi di permessi.

Sì, ma penso che sarebbe molto più sicuro procedere con ciò solo dopo aver almeno riprodotto tutto ciò che funziona ancora ora.

Non puoi semplicemente “tarare” la directory /var/discourse, spostarla su un’altra macchina, estrarla e avviare l’app Discourse.

Uno dei motivi principali è che quando buildi / avvii Discourse, il launcher (come ricordo a memoria) verifica se esiste un container Discourse di base (immagine) e scarica l’immagine Docker di base di Discourse (se non esiste), avviando poi quell’immagine Docker di base in un container.

Dopo quel pull git di base, il processo di build crea un’altra immagine Docker (quella dell’app).

Entrambe queste immagini Docker (l’immagine di base e l’immagine dell’app) non esistono all’interno di /var/discourse, quindi tarare /var/discourse è solo una “soluzione” parziale (usando questo termine in senso lato).

Queste immagini Docker di Discourse sono create come immagini Docker e fanno parte di Docker; non “vivono” in /var/discourse ma vengono costruite lì e poi spostate in Docker come immagini Docker.

Potrebbe essere possibile modificare il file yml del tuo container e ricominciare da capo, ma il metodo più convenzionale è salvare:

  • il/i file yml del/i container
  • il tuo backup completo con gli upload

quindi modificare il file yml del container, clonare il repository discourse-docker e ricominciare la build.

Poi, ripristina il tuo backup completo, inclusi gli upload (da riga di comando nel container).

Utilizzare GitHub come repository è una soluzione più pulita rispetto al vecchio metodo unixy di “tarare tutto il maledetto pacchetto” e “spostare tutto il maledetto pacchetto” su un altro server. Tuttavia, anche con il “vecchio metodo unix”, questo approccio spesso non fornisce una soluzione completa perché ci sono spesso librerie condivise nel sistema, directory utente delle librerie condivise e altro ancora che non fanno parte della directory di distribuzione, e ci sono file etc che non si trovano nella directory root della distribuzione, ecc.

Quindi, anche nella maggior parte dei sistemi Linux moderni, usiamo apt (su Ubuntu, ad esempio) per scaricare il repository. Nel caso di Discourse Docker, stai scaricando (e costruendo) discourse-docker per impostare il container di base e un altro repository Discourse per costruire l’app. Quindi, /var/discourse è un “luogo per costruire” (le immagini) e un “luogo per condividere” (i dati, i backup, i file statici pubblici, ecc.).

Spero che questo riassunto sia stato utile in qualche piccola misura.

Certo, puoi copiarlo tutto con rsync -rav.

Potresti avere più fortuna se cambi la tua app per utilizzare il template di PostgreSQL 10. Ma sembra che la cosa più semplice possa essere correggere direttamente il tuo database.

Puoi spostare la cartella, funziona correttamente. Non è semplicemente la via preferita, poiché aggira discourse-setup e qualsiasi sintonizzazione/test che esegue lungo il percorso.

Nel mio caso non ha funzionato perché l’aggiornamento di Docker ha portato a una versione più recente di PostgreSQL all’interno del contenitore Docker, il che ha causato un forum inutilizzabile a causa di problemi di migrazione di PostgreSQL. Ho dovuto passare da un template di Postres a uno di PostgreSQL 10.

How to backup and restore a whole /var/discourse app folder? - #8 by neounix spiega bene i dettagli.

Immagino che dovrei eseguire il backup e il ripristino anche della cartella /var/docker. Ma anche questo ha una possibilità di fallire a causa di questo:

Stai scendendo in un vicolo cieco.
Se fossi in te, mi concentrerei sulla risoluzione del tuo problema originale con il backup/ripristino.

Forse addirittura un buco di :rat: :rat: :rat:.

D’accordo… senz’altro…

@adrelanos

Non ci sono “problemi” con il processo di backup/ripristino. Vedi questo “elogio” scritto da me stesso, @neounix, alcuni mesi fa su questo argomento:

Gentile @adrelanos,

Tornando alla tua domanda originale nel post #1 qui sopra, per mia natura curiosa, non sono rimasto pienamente soddisfatto della mia risposta precedente e ho effettuato alcuni test oggi.

In sintesi, ho confermato che possiamo utilizzare docker save (per i container base e dell’applicazione) e tar per la directory /var/discourse, consentendo di salvare completamente, trasferire (backup) e ripristinare l’applicazione in questo modo.

Sono quasi certo (99,99%) che questo metodo non sia supportato ufficialmente, ma meriti una risposta, quindi l’ho testato per te:

In pratica, ecco i passaggi, in sintesi:

  1. Salva i tuoi container con docker save.

Ad esempio, se stai eseguendo un’app standalone, puoi salvare il container base e quello dell’applicazione, come segue (in base alla tua configurazione):

docker save -o /tmp/my.discourse.docker.app.tar  discourse/base:2.0.20200512-1735

e anche:

docker save -o /tmp/my.discourse.docker.app.tar local_discourse/app:latest  
  1. Puoi anche comprimere in tar la directory /var/discourse, come hai menzionato:
cd /var/
tar -cvzf /tmp/my.var.discourse.tar.gz discourse

e poi comprimere con gzip i tuoi file tar di docker, se lo desideri, e archiviarli:

gzip /tmp/my.discourse.docker*.tar
  1. … e puoi spostare questi file su un altro server, archiviarli sullo stesso server, fare ciò che preferisci, invertire i passaggi e avviare l’applicazione Discourse senza problemi.

L’ho appena confermato “facendolo”, eliminando tutte le immagini dei container e la directory /var/discourse. In pratica, ho cancellato tutto e ho ripartito dai backup (non c’era bisogno di ricostruire poiché il dominio non era cambiato, ecc.).

Ad esempio, per il ripristino, puoi prendere le immagini docker salvate sopra e caricarle, ad esempio:

gzip -d /tmp/my.discourse.docker.app.tar.gz
docker load -i /tmp/my.discourse.docker.app.tar

gzip -d /tmp/my.discourse.docker.base.tar.gz
docker load -i /tmp/my.discourse.docker.base.tar
  1. Quindi, estrai la tua directory originale /var/discourse
cd /var
tar -xvzf /tmp/my.var.discourse.tar.gz
  1. Successivamente, devi controllare le tue immagini per assicurarti che siano etichettate correttamente:
docker images
  1. e se le immagini non sono etichettate correttamente, assicurati di assegnare loro i tag corretti, ad esempio per l’immagine della tua app:
docker tag 58ffc74989af local_discourse/app:latest
  1. Infine, esegui semplicemente questo:
cd /var/discourse
./launcher start app

e funziona perfettamente. L’ho appena testato (due volte).

Spero che questo sia d’aiuto.

FWIW: Ho provato questo metodo in due modi diversi, eseguendo il metodo di backup sopra, eliminando tutti i container docker, le immagini e la directory /var/discourse (distruggendo completamente tutto, ogni volta).

In ogni caso, sono stato in grado di caricare le mie immagini docker salvate, estrarre la directory /var/discourse, eseguire ./launcher start app e Discourse è partito senza problemi; per dimostrarlo, ho potuto eseguire un backup normale dall’interfaccia utente, confermando che tutto era in ordine.

Non sono sicuro se questo risponda alla tua domanda (e non ho partecipato all’aggiornamento o alle discussioni da Postgres 10 a 12); ma riguardo alla tua domanda su come tar semplicemente l’app come backup e ripristinarla, la risposta è , ma devi non solo archiviare la directory /var/discourse, ma devi anche docker save le tue immagini.

Il principale “problema” è mantenere corretti il nome del repository delle immagini e i tag, e dovresti essere a posto.

Spero che questo risponda, in qualche piccola misura, alla tua domanda su:

Come eseguire il backup e il ripristino di tutta la cartella dell’app /var/discourse?

La risposta è che devi archiviare sia la tua cartella che le tue immagini docker (come nell’esempio sopra) utilizzando docker save per le immagini (per il backup) e docker load per il ripristino.

Tieni presente che questo metodo non è supportato ufficialmente; ma per curiosità, volevo vedere come farlo dal punto di vista del sysadmin e ho scoperto che era più semplice di quanto le mie risposte precedenti indicassero.

Nota1:

Potresti voler spostare tutti i backup dalla tua directory backups/default (fuori dall’albero delle directory) prima di comprimere tutto in /var/discourse/ e conservare quei backup (separatamente), poiché quei file sono così grandi…

Nota2:

Questo tipo di backup non è supportato e quindi non è raccomandato per la maggior parte degli amministratori di sistema Discourse. Raccomando agli utenti di seguire il metodo di backup e ripristino Discourse raccomandato (e ufficialmente supportato).

Rimani Curioso!

Stai attento.


Per ulteriori dettagli, inclusi screenshot, ti invito gentilmente a consultare il mio post completo qui:

Questo è un approccio eccellente! Grazie!

Un problema sul server di ripristino.

./launcher logs app

2020-06-18 13:33:56.434 UTC [127] FATAL: la directory dei dati “/shared/postgres_data” ha un proprietario errato
2020-06-18 13:33:56.434 UTC [127] HINT: il server deve essere avviato dall’utente che possiede la directory dei dati.
./run: 3: echo: echo: errore di I/O
2020-06-18 13:33:57.448 GMT [128] LOG: si salta il file di configurazione mancante “/shared/postgres_data/postgresql.auto.conf”


Potrebbe essere dovuto a qualche opzione tar mancante? Ho aggiunto -p e -s durante l’estrazione, ma non ha aiutato.

server originale (fuori docker):

ls -la /var/discourse/shared/standalone/postgres_data/

drwx------ 7 messagebus messagebus 4096 May 25 13:16 base

server originale (dentro docker (./launcher enter app)):

ls -la /var/lib/postgresql/10/main/

drwx------ 5 root postgres 4096 May 25 23:28 base


server di ripristino fuori docker:

ls -la /var/discourse/shared/standalone/postgres_data/

drwx------ 7 messagebus messagebus 71 May 25 11:16 base

server di ripristino dentro docker:

drwx------ 5 root postgres 41 May 25 23:28 base


./launcher rebuild app lo risolverebbe, ma questo è un altro discorso.

Qualche idea?

Credo che tu intendessi docker save -o /tmp/my.discourse.docker.base.tar discourse/base:2.0.20200512-1735, in base al tuo processo di ripristino. In ogni caso, ottima spiegazione!

Però, come hai detto tu, non credo che questo sia un approccio ufficialmente supportato (ma non credo nemmeno che ci sia qualcos’altro che possa causare errori, a meno che il team di Discourse non inizi a utilizzare più di un’immagine di base nel processo di ricostruzione).

Sembra che lo stesso problema si verifichi anche qui:

https://meta.discourse.org/t/postgresql-12-update/151236/298?u=lucasbasquerotto

Non c’è una risposta specifica a questo problema nella FAQ, ma forse il team di Discourse aggiungerà una soluzione, dato che più di una persona ha riscontrato lo stesso problema. C’è una FAQ su Il cluster sorgente non è stato arrestato correttamente che potrebbe essere correlata al tuo problema.

Un metodo che ho utilizzato, che non prevede l’uso di docker save né un trasferimento completo tramite tar+untar di /var/discourse: