Abilita l'impostazione nascosta per includere gli upload S3 nei backup

Documentazione Self-Hosting
,
1

:bookmark: Questa guida spiega come abilitare un’impostazione nascosta in Discourse per includere i caricamenti Amazon S3 (Simple Storage Service) nei backup.

Discourse ha la capacità di archiviare i caricamenti multimediali su Amazon S3 per scalabilità e affidabilità. Tuttavia, questi caricamenti non sono inclusi nei backup per impostazione predefinita.

Questa guida copre l’abilitazione di un’impostazione nascosta per includere i caricamenti S3 nei backup, con opzioni per configurarla tramite la console Rails o il file app.yml.

Utilizzo della console Rails

Per abilitare l’inclusione dei caricamenti S3 nei backup tramite la console Rails, puoi seguire questi passaggi:

  1. Accedi al tuo server Discourse tramite SSH.
  2. Entra nel container Docker di Discourse eseguendo:
cd /var/discourse
./launcher enter app
  1. Avvia la console Rails:
rails c
  1. Abilita l’impostazione eseguendo:
SiteSetting.include_s3_uploads_in_backups = true
  1. Esci dalla console e dal container digitando:
exit
exit

Questa modifica ha effetto immediato. Non sono necessarie ulteriori azioni.

Modifica del file app.yml

Puoi anche apportare questa modifica aggiungendo o modificando il file app.yml nella sezione env:.

  1. Accedi alla directory del container dell’app Discourse:
cd /var/discourse
  1. Apri il file app.yml situato in containers:
nano containers/app.yml
  1. Sotto la sezione env:, aggiungi la riga:
DISCOURSE_INCLUDE_S3_UPLOADS_IN_BACKUPS: true
  1. Salva il file ed esci dall’editor.
  2. Applica le modifiche ricostruendo l’app:
./launcher rebuild app

Affinché questa modifica abbia effetto, è necessario eseguire il comando ./launcher rebuild app per applicare l’impostazione.

9 Mi Piace
2

Non è sufficiente distruggere e riavviare il container?

1 Mi Piace
3

Penso che non sia necessario distruggere e che il riavvio sia sufficiente. Lo confermerò più tardi.

Comunque, grazie @pfaffman per la tua altra howto guida che ho usato come modello per questa.

2 Mi Piace
4

Sono certo che sia necessario distruggere e riavviare per modificare le variabili d’ambiente applicate al container.

Naturalmente, se sono stati eseguiti aggiornamenti con docker manager, questi andranno persi quando il container verrà distrutto, motivo per cui la ricreazione è la raccomandazione più sicura. Forse è meglio raccomandare la ricreazione poiché è la più infallibile.

3 Mi Piace
9

Perché, non è questa impostazione sufficiente per includere tutti i caricamenti nel backup:
image

10

Ciò includerà i caricamenti locali ma non scaricherà i file che si trovano in s3 per includerli nel backup.

1 Mi Piace
11

Ok. Non lo sapevo.
Ma qual è la differenza tra ‘Caricamenti locali’ e la cartella “File archiviati in S3 ‘Caricamenti’”?

Inoltre, anche se non ho ancora modificato l’impostazione in web_only o nella console rails come detto sopra, ma ho solo scelto l’impostazione indicata qui.

Ma comunque, quando ho eseguito il backup, solo 10 minuti fa, ha mostrato come se avesse scaricato migliaia di file (che presumo possano essere solo sul mio spazio di archiviazione AWS S3, e la parola ‘Download’ stessa significa che sta scaricando dalla cartella remota del bucket S3).
Inoltre, sta mostrando Failed to download molti, moltissimi file. Quindi ho presunto che se questi file fossero sul server cloud locale, perché non includerli nel backup? Vedi questo screenshot:

image
image1091×605 39.8 KB

12

Se hai configurato Configura un provider di archiviazione oggetti compatibile con S3 per i caricamenti e hai spostato i tuoi caricamenti locali su S3, allora i tuoi caricamenti sono lì. Non vengono sottoposti a backup perché si presume che S3 venga sottoposto a backup e scaricarli sia costoso e solitamente non necessario.

Se hai bisogno di rimuoverli da S3 (ad esempio, se sei ospitato su discourse.org e ti stai spostando su un altro hosting), allora hai bisogno di un backup che includa i file archiviati su S3.

Perché vuoi scaricare i tuoi file da S3?

Sì, sembra che non riesca a scaricare i file da S3. La mia ipotesi è che non ne abbia scaricato nessuno, anche se è possibile che il tuo disco sia pieno, forse (mi aspetterei un errore di disco pieno, ma forse no?).

1 Mi Piace
13

Grazie. Ancora.

Il mio sito, essendo molto, molto piccolo, pagare qualche dollaro, che aumenta ogni mese con piccoli aggiornamenti, ogni mese ad Aws S3 storage si sta rivelando un po’ poco pratico per me. Sposterò la cartella ‘Uploads’ (e forse anche la cartella ‘backup’) su un altro provider come Google One Drive, iDrive, Hetzner ecc. alternative economiche.
Ora scopro che anche i diversi tipi di storage di Aws (da quello più attivo a quello di archiviazione), se li avessi scelti saggiamente all’inizio, mi sarebbero costati solo la metà per la stessa quantità/numero di file.

Ma lo farei ora.

1 Mi Piace
14

Quando ho scelto di archiviare i miei “upload” multimediali nel bucket AWS S3 anni fa, in quel momento (per quanto ne sono sicuro) HO ANCHE SPOSTATO tutti i media esistenti caricati dagli utenti su S3.

Inoltre, ho anche controllato ora nella mia cartella /var/discourse/shared/web_only/uploads/default/optimized/1X, contiene solo 63 file png e /var/discourse/shared/web_only/uploads/default/original/1X ne ha solo 3. (Ad eccezione di 1x, non esistono altre cartelle simili nella cartella ‘uploads o default’).

image
image1360×768 103 KB

Inoltre, non ho ancora modificato alcuna opzione nella console rails o nel file Yml per includere gli upload S3 nei miei backup. Quindi, perché mostra che ha scaricato così tanti “Media Uploads” DA S3!!!
E non è riuscito a scaricare così tanti file caricati? Screenshot qui.

Inoltre, la mia cartella di upload su S3 è di circa 3 GB (32k file), mentre i log di backup hanno mostrato che ha scaricato solo circa 3,2k (10% del totale).

Molto confuso.

Esiste un ALTRO comando rails per essere sicuri che quell’opzione non fosse stata attivata anni fa, quando sono passato ad Aws S3?

Qualsiasi spiegazione sarà utile.