J’utilise Cloudflare R2 pour les téléchargements de médias, mais je pense qu’il ne fonctionne pas pour la sauvegarde de la base de données. Quels répertoires de fichiers dois-je sauvegarder à l’aide de rclone ?
vous trouverez peut-être le sujet ci-dessous utile
Fichiers/répertoires Discourse à sauvegarder sur ProtonDrive (outre les médias R2/S3)
Étape 1 — Ce que signifie upload://
upload://
Commentaire
Discourse ne stocke que la référence upload://<hash> dans le contenu des publications (brut/cuit). Au moment de la compilation ou du rendu, Discourse consulte ses tables de base de données (comme uploads, post_uploads, etc.) pour résoudre ces hachages en URL ou chemins réels en fonction de l’emplacement de stockage des téléchargements (local, CDN, S3/R2, etc.).
Étape 2 — Où cela se trouve à l’intérieur du conteneur
/shared/uploads/default
Commentaire
Dans l’installation Docker standard (utilisant launcher et app.yml), /shared à l’intérieur du conteneur est monté en bind depuis le /var/discourse/shared/standalone de l’hôte. Tout ce que Discourse écrit de manière persistante — y compris les téléchargements, les journaux, les sauvegardes, etc. — se trouve sous /shared.
Étape 3 — Le chemin du système de fichiers de l’hôte
/var/discourse/shared/standalone/uploads/default
Commentaire
Si vous n’utilisez pas de téléchargements externes (S3/R2), c’est le chemin principal que vous devez synchroniser avec ProtonDrive pour conserver les médias de publication téléchargés. Si vous utilisez S3/R2, la plupart des téléchargements ne se trouveront pas ici, mais certains fichiers (par exemple, des variantes optimisées, des pierres tombales) peuvent subsister. Décidez si vous souhaitez également sauvegarder cela.
Étape 4 — Le mappage de volume Docker (app.yml)
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared
Commentaire
Tout ce qui se trouve dans /shared à l’intérieur du conteneur devient /var/discourse/shared/standalone sur l’hôte. Si vous sauvegardez cet arbre, vous obtenez les téléchargements, les fichiers de sauvegarde, les journaux et (facultativement) les données PostgreSQL si elles sont conservées sur disque (bien que les fichiers de sauvegarde soient généralement suffisants pour la récupération).
Cibles concrètes à sauvegarder (stockage local)
Ensemble minimal (si vous faites confiance aux sauvegardes tarball de Discourse) :
/var/discourse/shared/standalone/backups/ # Sauvegardes complètes générées par Discourse (fichiers tarball .tar.gz)
/var/discourse/shared/standalone/uploads/ # Uniquement si vous stockez les téléchargements localement
Commentaire
- La sauvegarde tarball fait référence au fichier .tar.gz créé par la fonctionnalité de sauvegarde de Discourse. Il contient l’intégralité de la sauvegarde de la base de données, la configuration du site, les thèmes et (facultativement, si sélectionné) tous les téléchargements locaux. Il ne contient pas les médias stockés sur S3/R2 externes ; seulement les enregistrements de la base de données qui y font référence.
- Si vos téléchargements résident sur S3/R2, vous n’aurez peut-être besoin que de
/backups/localement et d’un processus distinct pour sauvegarder votre bucket de stockage d’objets.
Ensemble « Tout ce dont j’aurais jamais besoin » (copie au niveau du système de fichiers) :
/var/discourse/shared/standalone/backups/ # Sauvegardes complètes de Discourse (tarballs)
/var/discourse/shared/standalone/uploads/ # Téléchargements/médias locaux (si pas S3/R2)
/var/discourse/shared/standalone/log/rails/ # (Facultatif) Journaux Rails — utiles pour l’analyse médico-légale
/var/discourse/shared/standalone/tmp/backups/ # (Facultatif) Zone de transit temporaire pour les sauvegardes (généralement vide)
/var/discourse/shared/standalone/postgres_data/ # (Facultatif) Répertoire de données PostgreSQL brut — généralement pas nécessaire
/var/discourse/containers/ # Votre app.yml et tous les YML de conteneur (configuration)
/etc/letsencrypt/ # (Facultatif) Certificats TLS si vous terminez le SSL sur l’hôte
Commentaire
- Les données PostgreSQL brutes ne sont généralement pas nécessaires car la sauvegarde tarball contient une sauvegarde logique de la base de données, ce qui est plus sûr pour la restauration.
- /containers est petit mais essentiel pour la reprise après sinistre — il contient vos paramètres et les mappages de volume.
- Les certificats TLS n’ont d’importance que si vous effectuez le SSL en dehors du conteneur.
Carte rapide en une ligne
upload://
↓
/shared/uploads/default (à l’intérieur de Docker)
/var/discourse/shared/standalone/uploads/default (sur l’hôte)
Commentaire
Si vous utilisez S3/R2 :
- Sauvegardez votre bucket S3/R2 séparément (par exemple, avec Rclone).
- Pensez quand même à sauvegarder
/backups/(tarballs, qui incluent la base de données et la configuration, les téléchargements du site, mais pas les médias externes) et/containers/.
TL;DR pour le fil de discussion ProtonDrive
- Téléchargements locaux ? Sauvegardez :
- /var/discourse/shared/standalone/uploads/
- /var/discourse/shared/standalone/backups/ # (contient les sauvegardes tarball au format .tar.gz)
- Téléchargements S3/R2 ? Sauvegardez :
- /var/discourse/shared/standalone/backups/ # (sauvegardes tarball : base de données/configuration/table des téléchargements)
- Votre bucket S3/R2 avec un autre outil
- Facultatif : /containers/, /log/rails/, et postgres_data pour une couverture complète de reprise après sinistre
Commentaire
Sauvegarde tarball : Le fichier .tar.gz créé par le système de sauvegarde de Discourse, contenant une sauvegarde logique de la base de données, des thèmes, des configurations et (facultativement) des téléchargements locaux, mais n’incluant jamais les médias S3/R2 externes.
J’aimerais souligner que chacune des 3 fois où j’ai changé de serveur, en m’appuyant sur la sauvegarde tarball pour préserver les téléchargements locaux, le app.yml par défaut était différent.
Par conséquent, il est probablement préférable de copier manuellement des parties de l’ancien app.yml pour remplacer des parties du nouveau fichier.
j