Ieri sera stavo procedendo con gli aggiornamenti di Discourse e ho ricompilato l’applicazione, il che ha generato una serie di errori di Postgres. Ho capito che ciò era dovuto al recente aggiornamento, ma continuavo a ricevere errori di “permesso negato”, tra l’altro (e sì, ho impostato la proprietà di tutto a 700, quindi non era globale). Così ho spostato la mia directory originale /var/discourse in una posizione che avrebbe dovuto essere temporanea e ho reinstallato una nuova istanza di Discourse nel tentativo di almeno aggiornare postgres.
Ed ecco dove la cosa si fa interessante. Avevo un backup del sito (solo il database, gli upload sono salvati su un volume diverso) generato dall’interfaccia grafica tre giorni fa. O almeno, credevo di averlo. Quello che ho ora è un file chiamato wacky-writers-forum-2021-04-06-033906-v20210328233843.sql.gz, che, a quanto ho capito, non è in realtà il file tar.gz in cui dovrebbe trovarsi il backup effettivo.
Al momento ho reindirizzato tutti a una pagina di atterraggio e spero che qualcuno possa dirmi che è ancora possibile recuperare l’effettivo file .tar.gz dal server di tre giorni fa, e come esattamente dovrei procedere per farlo.
Salvo i miei backup e gli upload su Digital Ocean Block Storage, e ho ancora la cartella di Discourse della mia vecchia installazione che funzionava, ma spostarla/copiarla nuovamente in /var/discourse rompe tutto di nuovo, inclusi gli errori di Postgres. Lavoro a questo da 9 ore di fila e sono proprio alla fine delle forze. Qualcuno può aiutarmi, o almeno provare a indicarmi la direzione giusta? Abbiamo appena raggiunto il traguardo di 1.000 utenti e mi piacerebbe davvero, davvero evitare di perderli tutti.
Modificato per correggere la mia configurazione degli upload.
Se hai la configurazione S3 nel file app.yml, puoi semplicemente eseguire un ripristino da riga di comando e il backup verrà recuperato da S3.
Poiché le tue risorse sono archiviate su S3, il backup contiene solo il database.
Dovresti essere in grado di clonare una nuova cartella /var/discourse, copiare il tuo file yml, ricostruire l’ambiente ed eseguire il ripristino da riga di comando.
Correggerò quindi la mia affermazione: i miei caricamenti e backup non si trovano nella cartella principale di Discourse (è in parte così che è iniziato tutto questo, stavo cercando di spostarci su DigitalOcean Spaces). Quindi, no, purtroppo non ho alcuna configurazione S3, dato che salvavo tutto su storage montato.
I backup venivano salvati in mnt/my_storage/shared/standalone, ma quando vado a cercare i backup lì, trovo solo il file wacky-writers-forum-2021-04-06-033906-v20210328233843.sql.gz. Ho effettivamente provato a ripristinare da quel file, per mancanza di idee migliori (probabilmente era sbagliato), ma ho ricevuto un errore “permission denied”. Sono sicuro che sia legato al modo in cui questi backup vengono effettivamente generati.
Quindi, in tal caso, dovresti essere in grado di ripristinare il file SQL e poi rimontare il volume di archiviazione a blocchi per recuperare i tuoi file caricati.
Esistono due tipi di backup: sql.gz, che non include i file caricati, e tar.gz, che li include. Quindi avevi il tipo sbagliato di backup, ma il fatto che i file caricati fossero su un volume esterno ti ha salvato la pelle.
Il ripristino dal file .sql.gz è andato a buon fine. (evviva! Grazie ancora, Richard.)
Ho verificato che app.yml avesse la stessa configurazione di prima del disastro
./launcher rebuild app
La ricostruzione è andata a buon fine con Postgres 13 (finalmente)
Tuttavia, ora il sito stesso è ancora offline. Uso Cloudflare, ma ho attivo la Modalità Sviluppo e ho svuotato la cache DNS. Tutto punta alla destinazione corretta. Il template di Cloudflare è incluso in app.yml.
Il DNS si risolve correttamente, gli hostnames sono aggiornati, l’installazione di Discourse è stata eseguita con l’URL appropriato e mi sto esaurendo di idee.
https://forum.wackywriters.com è l’URL, ma ricevo solo errori “server non disponibile”. Sento di girare a vuoto (scusa) ma hai qualche suggerimento?
Edit: Quando eseguo ./discourse-doctor, vedo che ci sono due istanze dell’app in esecuzione su Docker:
È normale? (Sembra di no, ma tutto ciò che pensavo di sapere su Discourse è stato buttato fuori dalla finestra nelle ultime 24 ore )
Edit2: Stavo rimandando questa opzione come ultima risorsa, ma proverò a configurare un server completamente nuovo con un’installazione pulita di Discourse. Temo che qualcosa si sia rotto a causa di tutti i miei tentativi e non riesco a capire cosa non funzioni. Per fortuna ho ancora il backup e tutti gli upload sullo storage a blocchi, quindi, se sono fortunato, dovrei riuscire a collegarli a un nuovo droplet e trasferire tutto da lì. Se qualcuno ha ulteriori suggerimenti o consigli, apprezzerei ancora di più la tua esperienza rispetto alla mia.
Edit3: Anche con un nuovo server e un IP in propagazione (nslookup e ping sembrano entrambi a posto, whatsmydns.net è OK), il forum non si carica. Ricevo ancora errori di connessione. È come se non stesse collegando l’indirizzo IP all’istanza di Discourse e invece stesse cercando di caricare una pagina statica, che ovviamente, in questo caso, non esiste.
Quindi, dopo quasi 24 ore di lotta, ho capito perché il sito si rifiutava di caricarsi dopo aver avviato il ripristino.
A causa di così tanti reset e reinstallazioni, e chissà cos’altro, ho raggiunto il limite di richieste, quindi ho temporaneamente commentato i template SSL e li riattiverò tra una settimana.
Il sito è “funzionante” mentre rigenero tutti i post per correggere le immagini rotte, ma apprezzo davvero Jay e Richard per essermi stati d’aiuto oggi: mi avete portato attraverso le parti che proprio non riuscivo a capire.
Ora devo scaricare un backup vero così posso configurare S3 questa settimana senza dovermi preoccupare di questo di nuovo.
Se cerchi, esiste un modo per aggiungere un secondo dominio in modo che venga conteggiato come una richiesta separata per Let’s Encrypt. Ma aspettare è più semplice.
Consiglio di impostare Cloudflare su “nube grigia” senza ottimizzazioni della velocità.
@pfaffman Non stai confondendo lo storage a oggetti con lo storage a blocchi? Lo storage a oggetti è S3, ma TS dice di aver utilizzato lo storage a blocchi, che è semplicemente un disco montato nella loro directory di upload:
Abbiamo appena raggiunto il traguardo di 1.000 utenti e mi piacerebbe davvero, davvero evitare di perderli tutti.
)
