Supongo que no es estrictamente necesario descargarlo. La mayoría de las personas ejecuta una sola instancia en la nube, que puede o no tener un bucket S3 de respaldo. Descargar la copia de seguridad sería la única forma para que este grupo realice una copia de seguridad externa, como usted mencionó.
Incluso llegaría a crear un sistema de copia de seguridad adicional en un proveedor completamente diferente, especialmente después de lo que recientemente le sucedió a este desarrollador de código abierto. Independientemente de su validez, es una gran advertencia tener una copia de seguridad semanal o mensual en una ubicación/proveedor de almacenamiento completamente separado.
¡Gracias @pfaffman por añadir esto, ahora es realmente sencillo! (excepto al restaurar una copia de seguridad grande, que siempre es una espera tensa y larga, sea cual sea la configuración).
por cierto, creo que esta ruta es incorrecta: debería ser web-only (por defecto), ¿creo?
Sí. web-only y eso es un poco confuso cuando en todos los demás contextos es web_only. Pero quizás cuando algo es un directorio o un contenedor, lo que sea, es una cosa diferente.
Qué sé yo… Acabo de perder 4 horas peleando con SearXNG y eso debería ser un trabajo de 5 minutos (realmente no me gustan las cosas de Docker).
edición y fuera de tema
¿De verdad él y ck son palabras prohibidas? Nos lo enseñaron en la escuela como una palabra no ofensiva. Así que se equivocaron, obvio
Creo que eso se añadió cuando se estaban probando las palabras vigiladas y simplemente nunca se eliminó.
Sí. A menudo me confundo con eso. De hecho, creo que probablemente por eso una vez, cuando intenté simplemente renombrar cosas para cambiar de contenedor simple a doble, me equivoqué con el guion bajo/guion y falló.
Y lo que es peor, estoy bastante seguro de que es mi culpa. Recibí un error cuando creé la opción de dos contenedores en discourse-setup (¿quizás los contenedores no podían tener guiones bajos?) A Ruby le gustan los guiones bajos en los nombres de archivo, así que ¿quizás por eso usé un guion bajo allí? Creo que eso es todo, y creo que web_only no puede funcionar como nombre de contenedor de Docker, ya que también necesitan ser nombres de host válidos.
Prefiero guiones en las rutas de los directorios, así que todo bien como está, y un guion bajo en el nombre del contenedor, honestamente, tiene sentido, así que déjalo como está.
Por cierto, creo que debería haber un título o una insignia autocertificada en meta para aquellos que usan la configuración de dos contenedores Una vez que hayas estado aquí por un año, creo que debería ser obligatorio migrar tus instalaciones estándar.
Si no fuera por tanta documentación existente sobre la configuración de un solo contenedor, casi argumentaría que debería ser la predeterminada, aunque necesitaría alguna herramienta para que la gente sepa que la base de datos podría necesitar atención, o algo así.
A menudo veo a mucha gente descontenta y, de lo contrario, asustada de las instalaciones de dos contenedores. (Recientemente, alguien quiso que la instalación de dos contenedores que creé cuando hice su instalación se moviera a un solo contenedor, por ejemplo). Es muy raro que sea un problema, y la única vez que causa problemas, en realidad ahorra algunas molestias, ya que facilita posponer una actualización de Postgres hasta que esté listo para hacerlo. Por lo general, puedes posponer una actualización de PG por un buen tiempo (excepto cuando el complemento de IA se agregó al núcleo y requirió esa extensión).
mis copias de seguridad comenzaron a fallar después de esto:
[2025-09-09 09:34:50] Creando archivo: blah-forum-2025-09-09-093246-v20250828181952.tar.gz
[2025-09-09 09:34:50] Asegurándose de que el archivo no exista ya...
[2025-09-09 09:34:50] Creando archivo vacío...
[2025-09-09 09:34:50] EXCEPCIÓN: 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: No se puede abrir: Permiso denegado
tar: El error no se puede recuperar: saliendo ahora
mirando los permisos desde dentro del contenedor web_only:
/var/www/discourse/public/backups# ls -l
total 4
drwxr-xr-x 2 root root 4096 Sep 6 12:37 default
si miro en otra instancia, la propiedad es diferente:
/var/www/discourse/public/backups# ls -l
total 4
drwxr-xr-x 2 discourse www-data 4096 Sep 9 03:46 default
¿qué ha ido mal aquí y qué debería cambiar en ese directorio para el contenedor web_only? ¿debería ser lo mismo que para una instalación estándar?
Sin mirarlo, lo siguiente que intentaría sería reconstruir el contenedor de datos, esperando que cualquier cambio que se haya realizado también se haya hecho en (o afecte a) el contenedor de datos.
La respuesta de mal consejo es hacer que ...backups/default sea escribible por todos y ver la propiedad de la copia de seguridad.
Así que creo que lo que quieres hacer es chown default a discourse.www-data en el contenedor web (ese es el que hace las copias de seguridad).
En algunos momentos del pasado, el proceso de compilación hacía chown a todos los archivos, pero puede llevar mucho tiempo, así que creo que eso pudo haber sido eliminado en algún momento (esto es más una sensación que algo basado en prestar atención a los commits).
Mayormente. ./launcher hará un git pull (al menos eso creía, ¿pero quizás no?) primero y es más probable que tengas autocompletado funcionando para docker que para ./launcher.
Fui paciente y esperé el trabajo programado (¡pero documentarlo es muy útil!) y eso parece haber funcionado, así que muchas gracias por tu ayuda @pfaffman
Sí. Solía haber un chown que se ejecutaba en cada reconstrucción, estoy bastante seguro. Puede llevar tiempo y casi siempre es superfluo (excepto cuando no lo es). No tiene nada que ver con uno o dos contenedores. Creo que tiene que ver con el paso de una versión de Debian para la imagen base a otra versión y la nueva versión tiene diferentes mapeos de usuario de los que tenía la antigua.
No estoy seguro de a qué te refieres con “esta”, pero tanto este tema como el al que me refiero son para una instalación estándar, por lo que docker_manager funciona normalmente.
Docker_manager no está relacionado con el proceso de mudarse a otro servidor, ya que tienes que construir un nuevo contenedor.
Debería obligarte a construir una nueva aplicación cuando hay un cambio en la imagen base, lo cual creo que ha estado sucediendo bastante últimamente. Para ser honesto, no he entendido del todo los mecanismos en juego allí.
Así es como lo encontré: después de un arranque de web_only y reemplazar (destruir, iniciar), fui a actualizar después de un solo cambio de plugin, ¡solo para que me pidieran reconstruir la aplicación!
él y ck son palabras prohibidas? Nos lo enseñaron en la escuela como una palabra no ofensiva. Así que se equivocaron, obvio 
Una vez que hayas estado aquí por un año, creo que debería ser obligatorio migrar tus instalaciones estándar. 