Estou usando o Cloudflare R2 para uploads de mídia, mas acredito que ele não funciona para fazer backup do banco de dados. Quais diretórios de arquivos preciso fazer backup usando o rclone?
você pode achar o tópico abaixo útil
Arquivos/diretórios do Discourse para fazer backup no ProtonDrive (além de mídia R2/S3)
Etapa 1 — O que upload:// significa
upload://
Comentário
O Discourse armazena apenas a referência upload://<hash> no conteúdo da postagem (cru/cozido). No momento da compilação ou ao renderizar, o Discourse consulta suas tabelas de banco de dados (como uploads, post_uploads, etc.) para resolver esses hashes em URLs ou caminhos reais com base em onde os uploads são armazenados (local, CDN, S3/R2, etc.).
Etapa 2 — Onde isso fica dentro do contêiner
/shared/uploads/default
Comentário
Na instalação Docker padrão (usando launcher e app.yml), /shared dentro do contêiner é montado a partir de /var/discourse/shared/standalone do host. Tudo o que o Discourse persistente escreve — incluindo uploads, logs, backups, etc. — está em /shared.
Etapa 3 — O caminho do sistema de arquivos do host
/var/discourse/shared/standalone/uploads/default
Comentário
Se você não estiver usando uploads externos (S3/R2), este é o caminho principal que você deve sincronizar com o ProtonDrive para preservar a mídia de postagem carregada. Se você estiver usando S3/R2, a maioria dos uploads não estará aqui, mas alguns arquivos (por exemplo, variantes otimizadas, tombstones) podem permanecer. Decida se você deseja fazer backup disso também.
Etapa 4 — O mapeamento do volume Docker (app.yml)
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared
Comentário
Tudo em /shared dentro do contêiner se torna /var/discourse/shared/standalone no host. Se você fizer backup desta árvore, obterá uploads, arquivos de backup, logs e (opcionalmente) dados do PostgreSQL se mantidos em disco (embora os arquivos de backup geralmente sejam suficientes para recuperação).
Destinos concretos para fazer backup (armazenamento local)
Conjunto mínimo (se você confia nos backups em tarball do Discourse):
/var/discourse/shared/standalone/backups/ # Backups completos gerados pelo Discourse (arquivos tarball .tar.gz)
/var/discourse/shared/standalone/uploads/ # Somente se você armazena uploads localmente
Comentário
- O backup em tarball refere-se ao arquivo .tar.gz criado pelo recurso de backup do Discourse. Ele contém o dump completo do banco de dados, configuração do site, temas e (opcionalmente, se selecionado) todos os uploads locais. Ele não contém mídia armazenada em S3/R2 externo; apenas os registros do banco de dados que os referenciam.
- Se seus uploads residem em S3/R2, você pode precisar apenas de
/backups/localmente e um processo separado para fazer backup do seu bucket de armazenamento de objetos.
Conjunto “Tudo o que eu poderia precisar” (cópia em nível de sistema de arquivos):
/var/discourse/shared/standalone/backups/ # Backups completos do Discourse (tarballs)
/var/discourse/shared/standalone/uploads/ # Uploads/mídia locais (se não for S3/R2)
/var/discourse/shared/standalone/log/rails/ # (Opcional) Logs do Rails — úteis para forense
/var/discourse/shared/standalone/tmp/backups/ # (Opcional) Estágio de backup transitório (geralmente vazio)
/var/discourse/shared/standalone/postgres_data/ # (Opcional) Diretório de dados brutos do PostgreSQL — geralmente não é necessário
/var/discourse/containers/ # Seu app.yml e quaisquer YMLs de contêiner (configuração)
/etc/letsencrypt/ # (Opcional) Certificados TLS se estiver terminando SSL no host
Comentário
- Dados brutos do PostgreSQL geralmente não são necessários, pois o backup em tarball contém um dump lógico do banco de dados, que é mais seguro para restauração.
- /containers é pequeno, mas crítico para recuperação de desastres — ele contém suas configurações e mapeamentos de volume.
- Certificados TLS só importam se você estiver fazendo SSL fora do contêiner.
Mapeamento rápido de uma linha
upload://
↓
/shared/uploads/default (dentro do Docker)
/var/discourse/shared/standalone/uploads/default (no host)
Comentário
Se você usa S3/R2:
- Faça backup do seu bucket S3/R2 separadamente (por exemplo, com Rclone).
- Ainda considere fazer backup de
/backups/(tarballs, que incluem db e config, uploads do site, mas não mídia externa) e/containers/.
TL;DR para o tópico do ProtonDrive
- Uploads locais? Faça backup de:
- /var/discourse/shared/standalone/uploads/
- /var/discourse/shared/standalone/backups/ # (contém backups em tarball como .tar.gz)
- Uploads S3/R2? Faça backup de:
- /var/discourse/shared/standalone/backups/ # (backups em tarball: db/config/uploads table)
- Seu bucket S3/R2 com outra ferramenta
- Opcionalmente: /containers/, /log/rails/, e postgres_data para cobertura completa de DR
Comentário
Backup em tarball: O arquivo .tar.gz criado pelo sistema de backup do Discourse, contendo um dump lógico do banco de dados, temas, configurações e (opcionalmente) uploads locais, mas nunca inclui mídia S3/R2 externa.
Gostaria de ressaltar que, das 3 vezes que mudei de servidor, confiando no backup de tarball para preservar os uploads locais, o app.yml padrão tem sido diferente.
Portanto, é provavelmente melhor copiar manualmente partes do antigo app.yml para substituir partes do novo arquivo.
gostaria de tentar docker cp para extrair um arquivo de backup de um contêiner discourse para o sistema host, se isso for necessário