我猜它并非严格必需下载。大多数人运行的是单个云实例,可能有一个备份 S3 存储桶,也可能没有。下载备份将是这部分人进行异地备份的唯一方法,正如您提到的那样。
我甚至会更进一步,在完全不同的提供商那里建立一个额外的备份系统,尤其是在最近发生在这位开源开发者身上的事情之后。无论其有效性如何,它都是一个很好的警示,提醒我们每周或每月备份到完全独立的存储位置/提供商那里。
我猜它并非严格必需下载。大多数人运行的是单个云实例,可能有一个备份 S3 存储桶,也可能没有。下载备份将是这部分人进行异地备份的唯一方法,正如您提到的那样。
我甚至会更进一步,在完全不同的提供商那里建立一个额外的备份系统,尤其是在最近发生在这位开源开发者身上的事情之后。无论其有效性如何,它都是一个很好的警示,提醒我们每周或每月备份到完全独立的存储位置/提供商那里。
感谢 @pfaffman 添加了这一项,现在真的太简单了!(除了恢复大型备份,无论哪种设置,这总是一段紧张而漫长的等待)。
顺便说一句,我认为这个路径不正确:应该是 web-only(默认情况下)?
volumes:
- volume:
host: /var/discourse/shared/web-only
guest: /shared
- volume:
host: /var/discourse/shared/web-only/log/var-log
guest: /var/log
附言:我已经相应地编辑了 OP
是的。web-only 并且这有点令人困惑,因为在所有其他上下文中它都是 web_only。但也许当某样东西是目录或容器时——不管那是什么——事情就会不同。
我所知道的……我刚刚花了 4 个小时与 SearXNG 搏斗,而这本应该是 5 分钟的工作(我真的很讨厌 docker 的东西)
编辑和离题
真的吗
他和 ck 是一个被禁止的词?我们在学校被教导过,这是一个没有冒犯性的词。所以,他们错了,显而易见 ![]()
我认为那可能是在首次测试监视词时添加的,然后从未被移除。
是的。我经常对此感到困惑。事实上,我认为这可能就是为什么有一次我试图重命名事物以从单容器切换到双容器时,我弄错了下划线/破折号,结果失败了。
而且更糟糕的是,我很确定这是我的错。我在 discourse-setup 中创建双容器选项时遇到了一些错误(也许容器不能有下划线?)Ruby 喜欢文件名中的下划线,所以也许我在这里使用了下划线?我认为就是这样——而且我认为 web_only 不能作为 docker 容器名称,因为它们也需要是有效的 主机名。
我更喜欢目录路径中使用连字符,所以保持原样一切都好,而容器名称中使用下划线,说实话,这很有意义,所以保持原样。
顺便说一句,我认为元(meta)上应该有一个标题或自认证徽章,给那些使用双容器设置的人
一旦你在这里待满一年,我认为强制将标准安装迁移到双容器是必须的。![]()
如果不是因为有大量关于单容器设置的现有文档,我几乎会认为它应该是默认设置,尽管需要一些工具来告知人们数据库可能需要注意,或者其他什么。
我经常看到很多人对双容器设置感到不满和害怕。(最近有人希望将我为他们安装时创建的双容器安装迁移到单容器。)这种情况很少出现问题,而且一旦出现问题,实际上可以省去一些麻烦,因为它很容易将 Postgres 升级推迟到您准备好进行升级时。您通常可以推迟 PG 升级一段时间(除非 AI 插件已添加到核心并需要该扩展)。
我的备份在此之后开始失败:
[2025-09-09 09:34:50] Creating archive: blah-forum-2025-09-09-093246-v20250828181952.tar.gz
[2025-09-09 09:34:50] Making sure archive does not already exist...
[2025-09-09 09:34:50] Creating empty archive...
[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: Cannot open: Permission denied
tar: Error is not recoverable: exiting now
查看 web_only 容器内的权限:
/var/www/discourse/public/backups# ls -l
total 4
drwxr-xr-x 2 root root 4096 Sep 6 12:37 default
如果我查看另一个实例,所有权是不同的:
/var/www/discourse/public/backups# ls -l
total 4
drwxr-xr-x 2 discourse www-data 4096 Sep 9 03:46 default
这里出了什么问题,我应该为 web_only 容器更改该目录的什么设置——它应该与标准安装的设置相同吗?
简而言之,也许可以试试
docker exec -it web_only bash
chown -R discourse:www-data /shared/backups
还有更多内容。
不看就知道,我接下来会尝试重建数据容器,希望所做的任何更改也已应用到(或影响)数据容器。
错误的建议是使 ...backups/default 可被所有人写入,并查看备份的所有权。
所以我想你要做的是在 web 容器(负责备份的那个)中将 default 的所有权更改为 discourse.www-data。
这是一个最近的单容器示例:
root@forum.mbse-capella.org(app):~$ docker exec -it app bash
root@new-app:/# grep www /etc/passwd
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
root@new-app:/# grep discourse /etc/passwd
discourse:x:1000:1000::/home/discourse:/bin/bash
过去在某些时候,构建过程会“chown”所有文件,但这可能需要很长时间,所以我认为这可能在某个时候被移除了(这更多是一种感觉,而不是基于关注提交记录)。
这等同于 ./launcher enter web_only?
大部分是。./launcher 会先执行 git pull(至少我是这么认为的,但也许不是?)而且你更有可能在 docker 上使用 tab 自动补全而不是 ./launcher。
它还将您置于根目录,而启动器会将您置于 discourse 目录中
/var/www/discourse/public/backups# ls -l
total 4
drwxr-xr-x 2 discourse www-data 4096 Sep 6 12:37 default
这似乎是正确的调整,所以让我们看看下一次备份情况如何,谢谢!
您可以直接从命令行或用户界面运行一个以查看其是否正常工作。
另外,如果我更聪明一些的话:
docker exec -it web_only bash -c "chown -R discourse:www-data /shared/backups"
我很有耐心,等待了预定的工作(但记录下来很有用!),这似乎奏效了,非常感谢你的帮助 @pfaffman
这就是我们不同之处。
是的。我敢肯定,以前每次重建都会运行一个 chown。这可能需要一段时间,而且几乎总是多余的(除非它不是)。这与一个容器与两个容器无关。我认为这与将基础映像从一个版本的 Debian 迁移到另一个版本的 Debian 有关,而新版本具有与旧版本不同的用户映射。
docker_manager 插件在此设置中没有用吗?它总是告诉我重建应用程序!
我不确定“此设置”是什么,但此主题和我引用的主题都是针对标准安装的,因此 docker_manager 可以正常工作。
Docker_manager 与迁移到另一台服务器的过程无关,因为您必须构建一个新容器。
当基础映像发生更改时,它应该会强制您构建一个新应用程序,我认为这最近发生了很多。老实说,我还没有完全弄清楚其中的机制。
我发现这个问题是在 web_only 引导并替换(销毁、启动)之后,在仅更改单个插件后尝试更新,结果被提示需要重建应用程序!