大家好 - 正在尝试从托管的 Discourse 迁移到自托管。已经成功测试了各种操作，但在尝试进行包含所有上传内容的实际迁移时，在解压存档几个小时后，在尝试提取转储文件时，它会提示“不存在该文件或目录”。所以现在面临丢失大约 140GB 上传内容的风险，除非大家有什么好主意？
请提供日志？
您是从命令行还是 Web 界面进行恢复？我推荐使用 Web 界面。
您好 - 我已将日志附加到上一封电子邮件，但在此再次附加。我首先尝试通过 Web 界面进行操作，然后第二次通过命令行进行操作。我怀疑备份可能以某种方式损坏，因为它在上传到 S3 时未被识别，并且如果我尝试通过浏览器上传，它几乎会立即被拒绝。
restore-failure-log.txt (3.28 KB)
看起来是这样。您是通过网页浏览器上传的，还是通过 scp/rsync？我建议使用 rsync 重新上传一次。
您好 Jay - 很抱歉我之前有点糊涂，因为我们在此迁移过程中也一直在通过电子邮件与 Discourse 进行讨论，我在那里附加了日志文件。
查看错误，我怀疑 tarball 实际上不包含 sql 转储，只有图像。该文件由 Discourse 代表我们启动和检查。我通过 http 下载了它，并通过 scp 上传到服务器，因为浏览器上传拒绝了它。
是的，我刚刚运行了一个命令来检查 tarball 的内容，它只包含图像，没有 SQL 转储。
您能否验证 tarball 的大小是否完全相同？
- 在 CDCK 实例上
- 下载的那个
- 您使用 scp 上传的那个
您可能需要使用 tar tfvz 来检查存档是否未被截断。
您可能需要检查您是否在任何地方都遇到了磁盘空间不足的问题，因为它需要存档大小的多倍空间。
好的，我暂时离开一下，晚点再查看。空间应该没问题，我有 512GB，备份文件是 70GB。我很惊讶文件比我们上次创建的文件小了几GB，我本来以为会稍微大一点。我很确定，不知何故，它没有包含 SQL 转储，这大约是大小差异。
您好 @pfaffman @RGJ，这是关于此进展的最新情况。SQL 转储确实在下载的存档中丢失了，我不确定单独进行数据库备份并将其插入存档是否可行（需要几个小时来测试）。所以我们最终恢复了数据库并进行了迁移（成功）。
现在的问题是，一旦 Discourse 退役所有东西并关闭 S3 存储桶/CDN，我们所有的历史图片都会失效。
我拥有所有图片，并认为我或许可以保持相同的文件夹结构将它们全部上传到我们的 S3 存储桶。看到一些帖子讨论了使用 discourse.remap / dbhelper.remap 在数据库级别批量更新链接的可能性。对此有任何想法都非常感谢！
我无法想象那会怎么发生。您的浏览器是否以某种方式解压缩并解除了备份的tar包，然后您试图将其重新组合起来？
您可以要求discourse.org的人员给您一个包含上传文件的备份。这就是您想要做的。他们会启用一个include_s3_uploads_in_backup（这接近，但几乎肯定不是隐藏设置的名称）。
您也可以设法使用S3工具从他们的存储桶中下载所有文件，然后重新上传。有几个主题讨论过这个问题。我不推荐这样做。
我最近将一个大约100GB的备份从CDCK迁移到Digital Ocean，包括droplet、spaces存储桶和bunny.net CDN，花费了1000美元。我很后悔。
那只是数据库吗？
哦，您是否以某种方式进行了仅数据库的恢复，即使您在tar文件中拥有这些图像？
您需要恢复他们制作的确切文件，并让Discourse恢复它。那个包含数据库和上传文件的文件。或者，您可以查看恢复代码，并设法手动完成它重新映射图像到新位置的操作。虽然我认为Richard拥有这方面的技能和工具，但我认为您不想那样做。
几个月前我们做过一次测试，一切正常。我认为他们保留了那个隐藏设置，因为这次我能够从后端触发包含上传的备份，尽管大约 12 小时后我们收到通知说备份失败了。然后我联系了 Discourse，他们说他们会从他们的端创建备份。几个小时后，我发起的备份似乎完成了，尽管按照 Discourse 的建议我们丢弃了该文件。然后他们遇到了一堆备份超时并返回错误的问，最后告诉我们有一个完整的文件。但是当我尝试恢复文件时，在花了几个小时提取存档后，它抱怨说转储文件丢失了。使用 tar -tf 检查文件确认存档中没有转储文件（查看其他完整备份，它通常是存档中的第一个文件）。由于是周日，我无法联系到 Discourse，并且我们承诺在周一早上之前完成迁移，所以我只进行了数据库备份（约 7GB）并用它进行了迁移。
Discourse 正在努力提供帮助，但他们现在真的只能做这么多，因为我们已经完成了迁移，并且自周日下午以来一直使用我们自己的托管环境。最简单的解决方案是让他们（付费）继续激活我们的 S3 存储桶和 CDN，但他们说这不可能。我估计我们只能丢失历史图像了。
这是可以修复的。只需将 S3 存储桶内容下载到您的本地上传目录，然后在数据库上执行 remap，将 CDN 和存储桶 URL 重写为您的实例的 URL。
1 个赞
有几个问题——上传的图片大小会耗尽我们新 VPS 的 SSD，而且我们无法附加额外的磁盘。也许我们可以只选择一部分，虽然不确定这在查看目录结构时会如何运作。此外，我们已经将网站配置为使用 S3 进行上传，而不是本地存储。
好的，然后将他们的 S3（或从 S3 备份）复制到您的 S3 并重新映射？
1 个赞
是的，这正是我希望成为可能的事！
1 个赞
啊。我明白了。是的，一旦上线就无法回头了。在文件被删除之前，仍然很有可能将它们移到 S3。
您始终需要有足够的空间来保存所有图片才能进行恢复。您可以一次复制一张图片。我相信也有一些工具可以直接复制文件。
是的，最初的计划是使用一个临时的 Azure 虚拟机进行恢复，并附加一个大的磁盘，然后将其推送到 S3，完成后再进行一次备份，最后将其迁移到我们的 VPS（尽量降低成本）。
所以，我有一个包含所有上传文件的 tar.gz，并且可以直接将它们保持目录结构导入到我们的 S3 存储桶中（我认为现在标准的 AWS 上传器可以做到，否则还有 CLI）。可能需要考虑所有权/权限问题，但也许不需要。
之后就是重新映射 - 不确定 discourse.remap 和 dbhelper.remap 之间的区别。我打算先在带有几个文件的虚拟安装上测试所有这些。
1 个赞