Presumo che non sia strettamente necessario scaricarlo. La maggior parte delle persone utilizza una singola istanza cloud, che può o non può avere un bucket S3 di backup. Scaricare il backup sarebbe l’unico modo per questo gruppo di effettuare un backup off-site, come hai menzionato.
Andrei anche oltre, creando un sistema di backup aggiuntivo su un provider completamente diverso, specialmente dopo quello che è successo di recente a questo sviluppatore open source. Indipendentemente dalla sua validità, è un ottimo avvertimento per avere un backup settimanale o mensile in una posizione/provider di archiviazione completamente separato.
Grazie @pfaffman per averlo aggiunto, ora è davvero indolore! (eccetto per il ripristino di un backup di grandi dimensioni che è sempre un’attesa un po’ tesa e lunga, qualunque sia l’installazione).
a proposito, penso che questo percorso sia errato: dovrebbe essere web-only (per impostazione predefinita) credo?:
Sì. web-only e questo è un po’ confusionario quando in ogni altro contesto è web_only. Ma forse quando qualcosa è una directory o un contenitore-qualunque-cosa è una cosa diversa.
Cosa ne so… ho appena perso 4 ore a combattere con SearXNG e quello che doveva essere un lavoro da 5 minuti (odio davvero le cose di docker)
modifica e fuori tema
Davvero lui e ck sono parole bannate? Ci è stato insegnato a scuola come parole non offensive. Quindi, si sbagliavano, ovviamente
Penso che sia stato aggiunto quando le parole monitorate venivano testate e non è mai stato rimosso.
Sì. Mi confondo spesso su questo. Infatti, penso che sia probabilmente il motivo per cui una volta, quando ho cercato di rinominare le cose per passare da contenitore singolo a doppio, ho sbagliato la cosa trattino/underscore e non ha funzionato.
E peggio ancora, sono abbastanza sicuro che sia colpa mia. Ho ricevuto un errore quando ho creato l’opzione a due contenitori in discourse-setup (forse i contenitori non potevano avere underscore?) A Ruby piacciono gli underscore nei nomi dei file, quindi forse è per questo che l’ho usato lì? Penso che sia così - e penso che web_only non possa funzionare come nome di contenitore Docker poiché devono anche essere nomi host validi.
Preferisco i trattini nei percorsi delle directory, quindi va tutto bene così com’è, e il trattino basso nel nome del container, onestamente, ha senso, quindi lascialo così com’è.
A proposito, penso che dovrebbe esserci un titolo o un badge autocertificato su meta per coloro che utilizzano la configurazione a due container Una volta che sei qui da un anno, penso che dovrebbe essere obbligatorio migrare le tue installazioni standard.
Se non fosse per tanta documentazione esistente sull’installazione a contenitore singolo, quasi quasi potrei sostenere che dovrebbe essere l’impostazione predefinita, anche se sarebbero necessari alcuni strumenti per informare le persone che il database potrebbe richiedere attenzione, o qualcosa del genere.
Spesso vedo molte persone insoddisfatte e altrimenti spaventate dalle installazioni a due contenitori. (Recentemente qualcuno ha voluto che l’installazione a due contenitori che avevo creato quando ho fatto la sua installazione venisse spostata in un singolo contenitore, ad esempio.) È così raro che sia un problema, e l’unica volta che causa problemi, in realtà risparmia un po’ di fatica poiché rende facile rimandare un aggiornamento di Postgres finché non si è pronti a farlo. Di solito puoi rimandare un aggiornamento di PG per un bel po’ (tranne quando il plugin AI è stato aggiunto al core e ha richiesto quell’estensione).
i miei backup hanno iniziato a fallire dopo questo:
[2025-09-09 09:34:50] Creazione archivio: blah-forum-2025-09-09-093246-v20250828181952.tar.gz
[2025-09-09 09:34:50] Assicurazione che l'archivio non esista già...
[2025-09-09 09:34:50] Creazione archivio vuoto...
[2025-09-09 09:34:50] ECCEZIONE: tar --create --file /var/www/discourse/public/backups/default/blah-forum-2025-09-09-093246-v20250828181952.tar --files-from /dev/null
tar: /var/www/discourse/public/backups/default/mvertigo-org-vestibular-disorders-support-forum-2025-09-09-093246-v20250828181952.tar: Impossibile aprire: Permesso negato
tar: Errore non recuperabile: uscita in corso
guardando i permessi dall’interno del container web_only:
/var/www/discourse/public/backups# ls -l
totale 4
drwxr-xr-x 2 root root 4096 6 set 12:37 default
se guardo un’altra istanza, la proprietà è diversa:
/var/www/discourse/public/backups# ls -l
totale 4
drwxr-xr-x 2 discourse www-data 4096 9 set 03:46 default
cosa è andato storto qui e cosa dovrei cambiare in quella directory per il container web_only - dovrebbe essere la stessa di un’installazione standard?
Senza guardare, proverei a ricostruire il container dei dati, sperando che qualsiasi modifica sia stata apportata anche al container dei dati (o che lo influenzi).
La risposta di cattivo consiglio è rendere ...backups/default scrivibile da tutti e vedere la proprietà del backup.
Quindi penso che quello che vuoi fare sia cambiare il proprietario di default in discourse.www-data nel container web (quello che esegue i backup).
A un certo punto in passato il processo di build avrebbe cambiato la proprietà di tutti i file, ma può richiedere molto tempo, quindi penso che possa essere stato rimosso a un certo punto (questo è più una sensazione che qualcosa basato sull’attenzione ai commit).
Per lo più. ./launcher farà prima un git pull (almeno così pensavo, ma forse no?) e avrai maggiori probabilità di avere il completamento automatico con tab funzionante per docker rispetto a ./launcher.
Sono stato paziente e ho aspettato il lavoro programmato (ma documentarlo è molto utile!) e sembra che abbia funzionato, quindi grazie mille per il tuo aiuto @pfaffman
Sì. C’era un chown che veniva eseguito ad ogni ricompilazione, ne sono abbastanza sicuro. Può richiedere del tempo ed è quasi sempre superfluo (tranne quando non lo è). Non ha nulla a che fare con uno o due container. Penso che abbia a che fare con il passaggio da una versione di Debian per l’immagine di base a un’altra versione e la nuova versione ha mappature utente diverse rispetto a quella vecchia.
Non sono sicuro di cosa sia “questa”, ma sia questo argomento che quello a cui mi riferisco sono per un’installazione Standard, quindi docker_manager funziona normalmente.
Docker_manager non è correlato al processo di spostamento su un altro server, poiché devi creare un nuovo container.
Dovrebbe costringerti a creare una nuova app quando c’è una modifica all’immagine di base, cosa che penso stia accadendo abbastanza spesso ultimamente. A dire il vero, non ho ancora capito i meccanismi in gioco.
Il modo in cui l’ho scoperto è stato dopo un bootstrap di web_only e la sostituzione (distruzione, avvio), ho aggiornato dopo una singola modifica del plugin, solo per essere invitato a ricostruire l’app!
lui e ck sono parole bannate? Ci è stato insegnato a scuola come parole non offensive. Quindi, si sbagliavano, ovviamente 
Una volta che sei qui da un anno, penso che dovrebbe essere obbligatorio migrare le tue installazioni standard. 