请问，您能指导一下我们需要在备份 tar 中编辑哪个文件吗？
归档文件中包含 dump.sql。您需要对其进行修改，然后将修改后的版本重新打包。我也通过修改它解决了其他问题——移除了一些导致登录后崩溃的异常自定义字段。
谢谢。
我会尝试下载备份文件，解压它，并按照您的说明修改该文件。
为了恢复备份而必须执行所有这些操作，确实令人有些担忧。
我想这可能是新版本的一个漏洞。
但备份和恢复是灾难恢复计划的关键组成部分。
它们应尽可能稳健，而该流程中的漏洞将产生重大影响。
1 个赞
好的，我能够在不修改备份文件的情况下完成恢复。
我尝试了几次，奇怪的是，其中一次恢复没有报错。
我之前被 Discourse 踢出了，直到我重新构建了一个启动器应用，问题才得以解决。
但现在一切正常了。
真是个奇怪的问题。
这仍然给我在从备份恢复论坛时带来麻烦。已经过去好几周了，从备份恢复的功能似乎仍然有问题。
对此有什么解决办法吗？
据我所知，我只能交替进行更新、检查表格格式、确保源站与托管站内容一致，并眼睁睁看着它多次失败。即便如此，可能还是需要进行一些微小的数据库修改才能奏效。
我已经成功迁移了三个站点中的两个，但为了保持理智，每天只能投入不到一小时来处理此事。我已经开始与客户沟通，说明未来遇到类似情况时可能引发的问题。耸肩
我只是坚持执行恢复操作，最终成功让系统运行起来。
报错信息指出用户资料表中存在一个不存在的列。
但这很可能是数据库端的超时错误，或者是 PostgreSQL 方面的某个漏洞。如果该列确实不存在，仅靠反复尝试恢复操作是无法自动创建该列的。
Jaromir 表示，修改脚本可以解决此问题。
Discourse 开发团队中似乎无人关注此问题，但这确实是一个令人困惑且令人不安的错误，因为它会影响您的灾难恢复计划。
也许该主题在众多讨论中被忽视了。
这并没有被忽视。明天我会首先着手处理这个问题。
同时，我正准备着手改进备份和恢复功能，因为在发生灾难或需要迁移到新服务器时，任何人都无需为此担忧。
11 个赞
太好了，谢谢。很高兴听到这个消息。
谢谢，Gerhard。我不确定您现在是否关心，但我在使用 GCP 的 PG 11 站点时也遇到了问题。这可能值得检查一下，因为它可能会影响我了解将在今年晚些时候进行的 PG12 升级。
我刚刚升级了两个共享 S3 备份存储桶的实例。我在其中一个实例上运行了备份，并尝试在另一个实例上恢复，但收到以下错误：
No migration with version number 20191007140446。
当前不支持 PostgreSQL 11 和 12。
4 个赞
好的，我已在 Droplet 上安装了最新版本的 Discourse（tests-passed），备份恢复（包含上传文件，未使用 S3 存储上传内容）顺利完成，未出现问题。
如果您在恢复过程中仍遇到问题，请按以下步骤操作：
-
重建容器：
cd /var/discourse git pull ./launcher rebuild app -
通过 Web 界面或命令行恢复备份：
cd /var/discourse ./launcher enter app discourse enable_restore discourse restore <filename>
如果问题仍未解决，请发布您尝试恢复的备份文件版本号，以及恢复过程中看到的错误信息。
6 个赞
两个站点均为 2.4.0.beta6 (8fc0cc9aaa)。备份（但上传文件除外）存储在 S3 上。
discourse restore 返回以下信息：
Starting restore: wonderful-community-2019-10-10-184822-v20191007140446.tar.gz
[STARTED]
'system' has started the restore!
Marking restore as running...
Making sure /var/www/discourse/tmp/restores/default/2019-10-10-211121 exists...
Downloading archive to tmp directory...
Unzipping archive, this may take a while...
EXCEPTION: Compression::Strategy::ExtractFailed
/var/www/discourse/lib/compression/gzip.rb:49:in `block in extract_file'
/var/www/discourse/lib/compression/gzip.rb:45:in `open'
/var/www/discourse/lib/compression/gzip.rb:45:in `extract_file'
当然，而且我认为该站点直接使用 GCP 上的数据库备份也能满足需求。不过，Sam 曾表示他曾在自己的开发站点上运行 PG 11，并很乐意了解与 PG 11 相关的问题。
@pfaffman 请增加站点设置 decompressed_file_max_size_mb（该设置是隐藏的）。当前默认值为 1GB。
我已准备好一个拉取请求（PR），可将默认值提升至 100GB，但尚未合并：
7 个赞
谢谢，@Roman。好吧，那个问题解决了。
但现在我收到一堆 invalid command \N 错误（它们在显示之前就把缓冲区填满了，所以我无法看到前面的内容），但也许
ERROR: syntax error at or near "Shiny"
LINE 1: Shiny contest submission 2019-01-07 20:00:05.570573 2019-01-...
^
EXCEPTION: psql failed
/var/www/discourse/lib/backup_restore/restorer.rb:324:in `restore_dump'
/var/www/discourse/lib/backup_restore/restorer.rb:75:in `run'
才是你需要了解的信息。
是的，我认为这是由 PG11 引起的。
2 个赞
如果是 pg11 实例，我同意！但这是一个标准的 2 容器安装。
等等！存在版本不匹配。
root@community:/var/discourse# ./launcher enter data root@staging-data:/# psql --version
psql (PostgreSQL) 10.7 (Ubuntu 10.7-1.pgdg16.04+1)
我要恢复的目标容器是 10.9 版！我敢肯定就是这个问题。（我认为 pg11 也会遇到类似的失败，但那时我是在同一实例上进行恢复）。
我明天会升级数据容器，然后告知您。感谢您的帮助。
3 个赞
好的，我将两个都升级到了 10.10（使用标准数据模板），但仍然遇到了“无效命令”的问题。
当开始出现“无效命令”错误时，我强制退出了恢复脚本。随后再次尝试恢复（旨在重现“无效命令”消息之前的第一个错误），结果出现了以下错误：
ActiveRecord::StatementInvalid: PG::UndefinedTable: ERROR: relation "theme_fields" does not exist
随后我在两个实例上分别执行了 rake db:migrate，再次备份后，恢复成功。也许在某个环节遗漏了迁移步骤？
（在修改上述设置后——以下是完整说明，供那些可能在极短时间内需要它们的人参考，之后这些操作将不再必要）
./launcher enter app
rails c
SiteSetting.decompressed_file_max_size_mb=1000000
1 个赞
我又遇到一次失败。这两个版本都是 2.4.0.beta6（一个是 2c011252f1，另一个可能稍新一些）。
我通过 S3 进行恢复。我尝试了包含和不包含上传文件两种情况。两者似乎都在正常运行，随后却像这样失败了：
...
COPY 11871
COPY 3689
COPY 0
COPY 36550
COPY 0
COPY 14736
/usr/local/bin/discourse: line 2: 3232 Killed RAILS_ENV=production sudo -H -E -u discourse bundle exec script/discourse "$@"
这是你收到的唯一消息吗？
如果你尝试移除任何 S3 依赖，先将备份文件复制到本地，结果会怎样？
@pfaffman，值得指出的是，你在此主题中发布的两起（或三起）恢复问题，并非本主题最初讨论的 bug（即 PG::UndefinedColumn: ERROR 问题）。鉴于这些明显是不同的问题，你可能需要考虑为它们分别开启新的主题。
4 个赞