Sto usando Cloudflare R2 per l’upload dei media, ma credo che non funzioni per il backup del database. Quali directory di file devo eseguire il backup usando rclone?
Potresti trovare utile l’argomento seguente
File/directory di Discourse da eseguire il backup su ProtonDrive (oltre ai media R2/S3)
Fase 1 — Cosa significa upload://
upload://
Commento
Discourse memorizza solo il riferimento upload://<hash> nel contenuto del post (raw/cooked). Al momento della creazione o del rendering, Discourse consulta le sue tabelle di database (come uploads, post_uploads, ecc.) per risolvere questi hash in URL o percorsi effettivi in base a dove sono archiviati i caricamenti (locale, CDN, S3/R2, ecc.).
Fase 2 — Dove si trova all’interno del container
/shared/uploads/default
Commento
Nell’installazione Docker standard (utilizzando launcher e app.yml), /shared all’interno del container viene montato in bind dalla directory /var/discourse/shared/standalone dell’host. Tutto ciò che Discourse scrive in modo persistente, inclusi caricamenti, log, backup, ecc., si trova sotto /shared.
Fase 3 — Il percorso del filesystem dell’host
/var/discourse/shared/standalone/uploads/default
Commento
Se non stai utilizzando caricamenti esterni (S3/R2), questo è il percorso principale da sincronizzare con ProtonDrive per conservare i media dei post caricati. Se stai utilizzando S3/R2, la maggior parte dei caricamenti non si troverà qui, ma alcuni file (ad esempio, varianti ottimizzate, segnaposto) potrebbero rimanere. Decidi se vuoi eseguire il backup anche di questo.
Fase 4 — Il mapping del volume Docker (app.yml)
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared
Commento
Tutto ciò che si trova in /shared all’interno del container diventa /var/discourse/shared/standalone sull’host. Se esegui il backup di questo albero, otterrai caricamenti, archivi di backup, log e (opzionalmente) dati PostgreSQL se conservati su disco (sebbene gli archivi di backup siano generalmente sufficienti per il ripristino).
Destinazioni concrete da eseguire il backup (store locale)
Set minimo (se ti fidi dei backup tarball di Discourse):
/var/discourse/shared/standalone/backups/ # Backup completi generati da Discourse (file tarball .tar.gz)
/var/discourse/shared/standalone/uploads/ # Solo se archivi i caricamenti localmente
Commento
- Il backup tarball si riferisce al file .tar.gz creato dalla funzionalità di backup di Discourse. Contiene l’intero dump del database, la configurazione del sito, i temi e (opzionalmente, se selezionato) tutti i caricamenti locali. Non contiene media archiviati su S3/R2 esterni; solo i record del database che li fanno riferimento.
- Se i tuoi caricamenti risiedono su S3/R2, potresti aver bisogno solo di
/backups/localmente e di un processo separato per eseguire il backup del tuo bucket di object storage.
Set “Tutto ciò che potrei mai aver bisogno” (copia a livello di filesystem):
/var/discourse/shared/standalone/backups/ # Backup completi di Discourse (tarball)
/var/discourse/shared/standalone/uploads/ # Caricamenti/media locali (se non S3/R2)
/var/discourse/shared/standalone/log/rails/ # (Opzionale) Log di Rails — utili per le indagini forensi
/var/discourse/shared/standalone/tmp/backups/ # (Opzionale) Staging temporaneo dei backup (solitamente vuoto)
/var/discourse/shared/standalone/postgres_data/ # (Opzionale) Directory dati PostgreSQL grezzi — solitamente non necessaria
/var/discourse/containers/ # Il tuo app.yml e qualsiasi YML del container (configurazione)
/etc/letsencrypt/ # (Opzionale) Certificati TLS se si termina SSL sull’host
Commento
- I dati PostgreSQL grezzi di solito non sono necessari poiché il backup tarball contiene un dump logico del database, che è più sicuro per il ripristino.
- /containers è piccolo ma critico per il disaster recovery: contiene le tue impostazioni e i mapping dei volumi.
- I certificati TLS sono importanti solo se stai gestendo SSL al di fuori del container.
Mappa rapida in una riga
upload://
↓
/shared/uploads/default (all’interno di Docker)
/var/discourse/shared/standalone/uploads/default (sull’host)
Commento
Se utilizzi S3/R2:
- Esegui il backup del tuo bucket S3/R2 separatamente (ad esempio, con Rclone).
- Considera comunque di eseguire il backup di
/backups/(tarball, che includono db e configurazione, caricamenti del sito, ma non media esterni) e/containers/.
TL;DR per il thread ProtonDrive
- Caricamenti locali? Esegui il backup di:
- /var/discourse/shared/standalone/uploads/
- /var/discourse/shared/standalone/backups/ # (contiene backup tarball come .tar.gz)
- Caricamenti S3/R2? Esegui il backup di:
- /var/discourse/shared/standalone/backups/ # (backup tarball: db/config/tabella uploads)
- Il tuo bucket S3/R2 con un altro strumento
- Opzionalmente: /containers/, /log/rails/, e postgres_data per una copertura completa DR
Commento
Backup tarball: Il file .tar.gz creato dal sistema di backup di Discourse, che contiene un dump logico del database, temi, configurazioni e (opzionalmente) caricamenti locali, ma non include mai media S3/R2 esterni.
vorrei sottolineare che ognuna delle 3 volte in cui ho spostato il server, affidandomi al backup tarball per preservare i caricamenti locali, il file app.yml predefinito è stato diverso.
Pertanto, è probabilmente meglio copiare manualmente parti del vecchio app.yml per sostituire parti del nuovo file.
Vorrei provare docker cp per estrarre un file di backup da un container discourse e metterlo sul sistema host, se necessario