Je suppose qu’il n’est pas strictement nécessaire de le télécharger. La plupart des gens utilisent une seule instance cloud, qui peut ou non avoir un bucket S3 de sauvegarde. Le téléchargement de la sauvegarde serait le seul moyen pour ce groupe de faire une sauvegarde hors site, comme vous l’avez mentionné.
J’irais même jusqu’à mettre en place un système de sauvegarde supplémentaire chez un fournisseur complètement différent, surtout après ce qui est arrivé récemment à ce développeur open source. Quelle que soit sa validité, c’est un excellent avertissement pour avoir une sauvegarde hebdomadaire ou mensuelle dans un emplacement/fournisseur de stockage entièrement distinct.
Merci @pfaffman d’avoir ajouté cela, c’est vraiment simple maintenant ! (sauf pour la restauration d’une sauvegarde volumineuse qui est toujours un peu stressante et longue, quelle que soit la configuration).
Au fait, je pense que ce chemin est incorrect : il devrait être web-only (par défaut), je pense ? :
Ouais. web-only et c’est un peu déroutant quand dans tous les autres contextes c’est web_only. Mais peut-être que quand quelque chose est un répertoire ou un conteneur-peu-importe, c’est une chose différente.
Qu’est-ce que j’en sais… J’ai juste perdu 4 heures à me battre avec SearXNG et ça aurait dû être un travail de 5 minutes (je déteste vraiment les trucs docker)
edit et hors sujet
Vraiment lui et ck sont des mots interdits ? On nous l’a enseigné à l’école comme un mot non offensant. Donc, ils avaient tort, évidemment
Je pense que cela a peut-être été ajouté lors des premiers tests des mots surveillés et que cela n’a jamais été supprimé.
Ouais. Je suis souvent confus à ce sujet. En fait, je pense que c’est probablement pour cela qu’une fois, lorsque j’ai essayé de renommer des choses pour passer de single à double conteneur, j’ai mal orthographié le trait de soulignement/tiret et cela a échoué.
Et pire encore, je suis à peu près sûr que c’est de ma faute. J’ai eu une erreur lorsque j’ai créé l’option deux conteneurs dans discourse-setup (peut-être que les conteneurs ne pouvaient pas avoir de traits de soulignement ?) Ruby aime les traits de soulignement dans les noms de fichiers, alors peut-être est-ce pour cela que je l’ai utilisé là-bas ? Je pense que c’est ça - et je pense que web_only ne peut pas fonctionner comme nom de conteneur docker car ils doivent également être des noms d’hôte valides.
Je préfère les tirets dans les chemins de répertoire, donc tout va bien tel quel, et le trait de soulignement dans le nom du conteneur, honnêtement, c’est logique, donc laissez-le tel quel.
Au fait, je pense qu’il devrait y avoir un titre ou un badge auto-certifié sur meta pour ceux qui utilisent la configuration à deux conteneurs Une fois que vous êtes ici depuis un an, je pense qu’il devrait être obligatoire de migrer vos installations standard.
Si ce n’était pas pour autant de documentation existante sur la configuration à conteneur unique, je dirais presque qu’elle devrait être la valeur par défaut, bien qu’il faudrait des outils pour informer les gens que la base de données pourrait nécessiter une attention particulière, ou quelque chose comme ça.
Je vois souvent beaucoup de gens mécontents et par ailleurs effrayés par les installations à deux conteneurs. (Récemment, quelqu’un voulait que l’installation à deux conteneurs que j’avais créée lors de son installation soit déplacée vers un conteneur unique, par exemple.) C’est si rarement un problème, et la seule fois où cela cause des problèmes, cela permet en fait d’éviter certains tracas car il est facile de reporter une mise à niveau de Postgres jusqu’à ce que vous soyez prêt à le faire. Vous pouvez généralement reporter une mise à niveau de PG pendant un bon moment (sauf lorsque le plugin IA a été ajouté au cœur et a nécessité cette extension).
mes sauvegardes ont commencé à échouer après ceci :
[2025-09-09 09:34:50] Création de l'archive : blah-forum-2025-09-09-093246-v20250828181952.tar.gz
[2025-09-09 09:34:50] Vérification que l'archive n'existe pas déjà...
[2025-09-09 09:34:50] Création d'une archive vide...
[2025-09-09 09:34:50] EXCEPTION : 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 : Impossible d'ouvrir : Permission refusée
tar : L'erreur n'est pas récupérable : sortie maintenant
en regardant les permissions depuis le conteneur web_only :
/var/www/discourse/public/backups# ls -l
total 4
drwxr-xr-x 2 root root 4096 Sep 6 12:37 default
si je regarde une autre instance, la propriété est différente :
/var/www/discourse/public/backups# ls -l
total 4
drwxr-xr-x 2 discourse www-data 4096 Sep 9 03:46 default
qu’est-ce qui s’est mal passé ici et que dois-je changer sur ce répertoire pour le conteneur web_only - devrait-il être le même que pour une installation standard ?
Sans regarder, j’essaierais ensuite de reconstruire le conteneur de données, en espérant que tout changement effectué y soit également apporté (ou l’affecte).
La mauvaise idée serait de rendre ...backups/default accessible en écriture à tous et de vérifier la propriété de la sauvegarde.
Je pense donc que ce que vous voulez faire est de changer le propriétaire de default en discourse.www-data dans le conteneur web (c’est celui qui effectue les sauvegardes).
À certains moments dans le passé, le processus de construction modifiait le propriétaire de tous les fichiers, mais cela pouvait prendre très longtemps, je pense donc que cela a pu être supprimé à un moment donné (c’est plus une intuition qu’autre chose basé sur l’attention portée aux commits).
La plupart du temps. ./launcher fera d’abord un git pull (du moins, je le pensais, mais peut-être pas ?) et vous aurez plus de chances d’avoir la complétion par tabulation qui fonctionne pour docker que ./launcher.
J’ai été patient et j’ai attendu le travail programmé (mais le documenter est très utile !) et cela semble avoir fonctionné, donc merci beaucoup pour votre aide @pfaffman
Ouais. Il y avait un chown qui s’exécutait à chaque reconstruction, j’en suis presque sûr. Cela peut prendre du temps et est presque toujours superflu (sauf quand il ne l’est pas). Cela n’a rien à voir avec un ou deux conteneurs. Je pense que cela a à voir avec le passage d’une version de Debian pour l’image de base à une autre version et que la nouvelle version a des mappages d’utilisateurs différents de ceux de l’ancienne.
Je ne suis pas sûr de ce que signifie « ceci », mais ce sujet et celui auquel je fais référence concernent une installation standard, donc docker_manager fonctionne normalement.
Docker_manager n’est pas lié au processus de déplacement vers un autre serveur, car vous devez construire un nouveau conteneur.
Il devrait vous forcer à construire une nouvelle application lorsqu’il y a un changement dans l’image de base, ce qui, je pense, s’est produit assez souvent dernièrement. Pour être honnête, je n’ai pas encore bien compris les mécanismes en jeu.
C’est ainsi que je l’ai trouvé : après un bootstrap de web_only et un remplacement (destroy, start), je suis allé mettre à jour après un simple changement de plugin, seulement pour être invité à reconstruire l’application !
lui et ck sont des mots interdits ? On nous l’a enseigné à l’école comme un mot non offensant. Donc, ils avaient tort, évidemment 
Une fois que vous êtes ici depuis un an, je pense qu’il devrait être obligatoire de migrer vos installations standard. 