@pnoeric 既然你担心站点正常运行时间，我想把我目前了解到的情况告诉你。
正如我所提到的，我是实时进行迁移的。如果不对迁移进行速率限制，负责通知用户彼此活动等任务的队列就会被堵塞，从而降低站点的用户体验。
我迁移了大约 500 篇包含视频的帖子和约 30,000 篇包含图片的帖子，整个过程耗时约两周。
如果你想尝试我使用的代码，它目前位于：
你可以下载它并复制到你的应用中，以替换当前 lib/tasks/uploads.rake 的内容。
使用这段代码，你可以执行类似以下的操作：
bin/rake uploads:batch_migrate_from_s3[100,1000]
这将仅考虑总共 1000 篇包含上传文件的帖子，并迁移最多 100 个文件后停止；每次在迁移上传文件后实际修改帖子时，它都会等待队列清空后再开始下一个。
如果你复制该文件，在撤销更改之前，它会破坏未来的站点更新。在你满意之后，最简单的撤销方法就是运行 ./launcher rebuild app（不过作为开发者，我通常使用 git checkout HEAD lib/tasks/uploads.rake 来撤销我的更改……）
我注意到，至少在使用 DigitalOcean Spaces 时，有时需要重试几次迁移才能成功。目前的脚本在这种情况下不会发出任何警告，你只能不断运行它并等待观察结果。我确实有一个等待审查的 PR，它会在出现这种情况时打印出错误信息，这样你至少能知道出了什么问题。
……
我添加了一个简单的短重试循环以及错误消息，看起来重试循环解决了这个问题。此外，之前针对当前规则进行的验证是基于过去帖子的原始内容，这可能会破坏迁移并静默留下需要重新烘焙的帖子；我也修复了这个问题。你绝对不应该在没有至少获得验证修复的情况下进行迁移，而该修复是我当前等待审查的 PR 中的其中一个提交。
……
据我所知，我的迁移已经完成。我的 PR 包含了我为完成迁移所使用的全部代码。该 PR 尚未经过审查。如果你想了解进展，我建议关注 https://meta.discourse.org/t/migrate-from-s3-problems/119064。