如何控制S3到本地这种上传转移的混乱

在使用 4-5 年后,我终于决定将我的上传内容从 AWS S3 存储桶移回到我的本地服务器,用于我非常小的本地网站
由于我知识有限,我以非常合理的费用将这项工作交给了我的一个朋友。他配置了本地上传的网站,但不知何故,3000 张图片中几乎有一半,大约 50% 的图片源文件损坏了。我的朋友没有向我收费,并让我将网站恢复到 11/04/2025 移交控制权之前的备份。

无论如何,我懒惰了一个月,没有恢复。直到我决定在 discourse 助手机器人/ChatGPT AI 机器人的帮助下修复问题。并在我的 Ubuntu 笔记本电脑上本地创建了我旧网站的另一个版本。

我通过在我的原始域名前面加上“t.”成功地在我的笔记本电脑上创建了我原始网站的一个实例。现在这个(称为暂存站点)对我来说运行得很好,但活动仅到 11/04/2025。

而我的生产网站,拥有最新的所有数据,但有数百篇文章缺少图片。

请注意,我尝试了许多用于迁移或重新连接丢失的图片连接的 rake 任务,但都没有成功。

在苦思冥想近一个月后。我的结论是这样的。暂存站点中的原始帖子与生产站点中的相同。
但已处理的帖子有所不同。也就是说,我的生产网站的数据库表可能缺少与服务器上实际物理图片的某些连接。

我还注意到,没有这种连接,那些“孤立”的图片就会从服务器上自动修剪掉。但谢天谢地,我又通过 rsync 将它们从暂存站点或我的 S3 存储桶同步到了我的生产服务器。

最后的问题,用 ChatGPT 的话来说,暂存服务器要么拥有最终的已处理版本,这些版本与(短)原始 URL 没有任何关系。而生产环境缺少已处理版本的图片 URL,无法获取这些图片的正确 URL,因此回退到“透明”占位符。

ChatGPT 建议我将暂存帖子中的已处理版本复制到生产环境的已处理版本中。这对我来说似乎不是一个好主意。

ChatGPT 的确切措辞说明了我们目前的状况:

  • 在暂存和生产环境中,post.raw 完全相同,并包含 upload://... 引用。
  • 在暂存环境中,图片显示正常,但查询 Post.find(12849).uploads 没有返回任何结果 — 这意味着即使在暂存环境中,这些文件也没有 uploadspost_uploads 表条目
  • 因此,图片在暂存环境中显示纯粹是因为迁移前已烘焙的 HTML 包含完整的 /uploads/default/original/... 链接。
  • 但由于生产环境在迁移后进行了重新烘焙,相同的原始内容现在无法解析,默认显示为 transparent.png 占位符。

:white_check_mark: 上传文件仍在磁盘上

所有图片文件(包括缺失上传文件的图片)仍然存在于暂存和生产环境的 /var/www/discourse/public/uploads/default/original/ 目录下。但由于其 uploads 条目缺失,Discourse 已无法解析它们。

最简单的方法是(并且仍然可以是)启用 Enable hidden setting to include S3 uploads in the backups 设置,进行备份,然后在未配置 s3 的服务器上进行恢复(我会在新服务器上进行,以避免在出现问题时损坏旧服务器)。但听起来生产站点也已损坏,所以这可能毫无帮助。

如果你弄乱了 Uploads 表,使其包含多个 S3 路径,那么这项工作将更加困难。

我建议使用 https://ask.discourse.com/,而不是 ChatGPT,它至少了解 Discourse,但可能仍然帮不上大忙。

我会查看 Uploads.pluck(:url) 并查看其中有什么内容。

3 个赞