无法迁移到 S3，因此无法从备份恢复

安装
1

因此，我有一个来自初始服务器的 Discourse 备份，我们正试图将系统迁移到新系统。

不幸的是，存在两个问题：

  1. 在恢复过程中，它显示 1073 个上传中有 71 个未迁移到 S3，因此在恢复过程中会硬性失败。

  2. 尝试在主实例上通过重新烘焙等方式修复此问题，它表明一些上传仍未迁移到 S3，即使我尝试使用 uploads:migrate_to_s3 rake 机制。

是否有任何方法可以从 migrate_to_s3 获取详细信息，了解哪些上传未迁移，以便我可以手动修复？也有可能它们指的是我们最初上传到的一个已死/失败的 S3 存储库，但当时东西爆炸了，我们只是切换了 S3 机制（当然是切换到 MinIO），并且 AWS S3 端仍然有一些旧的东西。我认为我无法轻松地将其迁移到我们的 MinIO 实例。

或者，是否有办法禁用恢复机制的 S3 上传检查器，因为我已经强制自己迁移了上传？

2 个赞
2

好的，在深入数据库进行排查后，我找到了原因。看起来是原始的、早已废弃的 S3 环境（或者更准确地说，是由于成本效益不高而未被主要使用的 S3 环境）遗留了 71 个上传文件。

我最终采取了以下步骤：

从源服务器：

  1. ./launcher enter app

  2. sudo -u postgres psql discourse

  3. SELECT url FROM uploads WHERE url NOT LIKE '%ExpectedS3DomainGoesHere%
    （将 ExpectedS3DomainGoesHere 替换为您 S3 配置的实际 URL）
    这将获取您需要处理的 URL，因为我们需要执行一些操作。

  4. 对于来自不同 URL 的旧存储桶的 URL，请使用 Amazon S3 客户端（或您的 S3 存储后端客户端），并执行以下操作：
    a. 将意外 URL 的存储桶（如果可用）同步到本地存储。
    b. 将本地文件同步到新的存储桶。

  5. discourse remap OLD-URL-FROM-DB NEW-URL-FROM-DB
    尽管有人建议 在此 使用 DbHelper.remap，但 discourse 的 remap 函数运行良好。

  6. 确保数据已迁移。
    rails uploads:migrate_to_s3

  7. 重建时间！
    rails posts:rebake

  8. 再次在“源”机器/服务器上备份站点。下载最新的更新。

从新目标服务器：

  1. 按预期设置 Discourse，将源服务器上的 app.yml 等文件复制到新服务器上的 /var/discourse/containers/，以确保重建能够命中所需的正确插件等。
    请确保在 app.yml 中注释掉任何 DISCOURSE_BACKUP_LOCATION: s3 条目，如果您正在处理本地备份文件。由于 S3 在处理备份文件时出现截断问题，我采取了本地方法进行恢复。

  2. 按照 https://meta.discourse.org/t/restore-a-backup-from-command-line/108034 中的步骤将备份导入到您的服务器并进行恢复。包括重建步骤。

我花了很长时间才解决这个问题，但在深入研究数据库中的 uploads 表后，问题得到了解决。但这似乎奏效了，所以……

5 个赞
3

在这些情况下，通常奏效的方法是在原始实例上暂时禁用 s3 上传，然后再进行备份。恢复后，您可以重新启用 s3。

3 个赞
4

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.