你不能简单地将 /var/discourse 目录打包（tar），然后移动到另一台机器上解包并启动 Discourse 应用。
主要原因之一是，当你构建/引导 Discourse 时（据我记忆，这是启动器做的事），它会检查是否存在基础的 Discourse 容器（镜像），如果不存在，就会拉取基础的 Discourse Docker 镜像，并将该基础 Docker 镜像启动为容器。
在完成基础 git pull 之后，构建过程会构建另一个 Docker 镜像（即应用镜像）。
这两个 Docker 镜像（基础镜像和应用镜像）并不存在于 /var/discourse 内部，因此将 /var/discourse 打包只是一种部分的“解决方案”（此处“解决方案”一词的使用较为宽松）。
这些 Discourse Docker 镜像是作为 Docker 镜像构建的，并作为 Docker 的一部分；它们并不“驻留”在 /var/discourse 中，而是在那里构建，然后作为 Docker 镜像移交给 Docker。
也许你可以编辑容器 yml 文件并从零开始重新构建，但更常规的做法是保存你的：
- 容器 yml 文件
- 包含上传文件的完整备份
然后编辑你的容器 yml 文件，克隆 discourse-docker 仓库并重新构建。
接着，从容器内的命令行恢复你的完整备份（包括上传文件）。
使用 GitHub 作为仓库是一种比旧式的 Unix 风格 方法（即“打包整个东西”并“将整个东西迁移”到另一台服务器）更干净的解决方案。然而，即使采用这种“旧式 Unix 方法”，通常也无法提供完整的解决方案，因为系统中往往存在共享库、共享库用户目录等，它们不属于分发目录；此外，还有一些位于发行版根目录之外的 etc 文件等。
因此，即使在大多数现代 Linux 系统上，我们也使用 apt（例如在 Ubuntu 上）来拉取仓库。就 Discourse Docker 而言，你拉取（并构建）的是 discourse-docker 以设置基础容器，并拉取另一个 Discourse 仓库来构建应用。因此，/var/discourse 是一个“构建位置”（用于构建镜像）和一个“共享位置”（用于存储数据、备份、公共静态文件等）。
希望这个总结能在某种程度上有所帮助。