在2020年4月30日，PC-Kombo的停机时间为1h15m。包括基准测试在内的PC硬件推荐器和这个博客都停机了。对于许多网站和服务来说，完全停机将是至关重要的，对于这个网站来说，这并不是那么糟糕，因为访问者的点击量可能很小。尽管如此，停机是在PC-Kombo做一些付费广告的第一阶段，所以这不是一个完美的时机。但我想让这场危机有用，所以我做了一个尸检。如何应对这样的停机，什么起作用了，什么没有起作用，可以吸取哪些教训？我希望分享这段经历会对你们中的一些人有所帮助。
三个部分：首先是一些背景信息，然后是停机过程中未加评论的日志，最后是一些关于经验教训的文字。
停机时间是我自己手动开始的。不久前，Scaleway发出了这封邮件：
C2&；ARM64实例停产-立即迁移到虚拟实例和裸机云服务器。
从2020年12月1日起，我们的C2和ARM64实例将达到其生命周期的终点。托管它们的物理服务器确实受到几个稳定性问题的随机影响，这些问题使我们无法完全保证整体服务质量。不过，请放心，我们将致力于指导您进行迁移，并为您提供最佳的匹配资源，以提高稳定性、性能和可靠性。
2020年4月14日起，不能再创建新的C2和ARM64实例。此外，他们的支持将于2020年7月1日结束。因此，我们的技术援助将不再解决与这些情况相关的问题。预计2020年7月1日也会涨价。最后，C2和ARM64实例将从2020年12月1日起完全取消配置。
PC-Kombo确实在C2实例上运行，所以它必须移动，越快越好。我关闭了PC-KomboC2实例的电源以创建快照。我们的计划是重新启动它，创建一个新的不同的实例，从快照重新创建站点，同时旧的C2实例同时为访问者提供服务。这不管用。C2实例从未重新通电。
15：25：使用备份集作为映像创建一个新的DEV-L实例。没有联机。
15：40：开始在DEV-M上下载外部Borg备份(还包括应用程序文件和其他操作数据)。
15：56：SSH-当Borg Backup Restore在该SSD实例中运行时，与DEV-M实例的连接关闭。
我已经对您的DEV实例执行了一些修改，在我执行的重启之后，它可能会联机。
16：08：Borg备份恢复中止，一些重要文件丢失。检查它们是否列在备份(Borg列表)中。重新启动备份还原。
由于某些事件，此实例系列目前缺货。如果您刚刚重新启动实例，则您的物理硬件已提供给同时启动其实例的另一个客户。
目前，我们的工程团队没有计划补充库存，因为c2x实例是不推荐使用的产品。它们既不能从最新的功能(热快照、无状态规则的安全组)中获益，也不能从与Scaleway生态系统的某些产品的兼容性中获益。
我们强烈建议您将当前的c2x实例迁移到DEV或GP实例，以保持稳定可靠的生产环境。我们的DEV和GP均采用AMD EPYC全新CPU，为您提供越来越强大的功能。
如果您需要帮助来迁移您的c1/c2x实例，请告诉我，只需几次单击即可完成迁移！
16：17：意识到支持链接到的文档包括我在使用备份创建DEV-L实例时遗漏的一个步骤：设置引导脚本。
在DEV-L和PC-Kombo上线之后，我经历了必须在另一个实例上从备份恢复的场景。一些教训来自于那次练习。
首先，在这种情况下，拥有在线备份是无价的。它让我相信，无论发生什么，数据丢失都将是最小的。我使用的是rsync.net提供的隐藏的博格/阁楼服务，每年支付不到20美元，绝对物有所值。
然而，该备份是不完整的。它不包括/etc/letscrypt和其他一些最近填充的数据位置，比如/var/www/html中受密码保护的goaccess报告。此外，有一个sqlite数据库已损坏-在使用中将其添加到备份中无法工作，传输期间的写入会损坏它。它是可恢复的(sqlite3 broken.db"；.recover"；|sqlite3 new.db)，但这需要额外的时间，而且并不总是可能的。备份需要改进。
其次，我应该早点打开支持票。尽管在重新启动哪台服务器方面有一些小的误解，但支持是有帮助的，而且速度很快。请记住，我没有支付支持计划，Scaleway没有义务对我的门票做出那么快的反应。它的反应非常好。
浮动IP功能Scaleway对快速将站点从损坏的C2实例迁移到新的DEV-L非常有帮助。必须在DNS级别设置新的IP会更加复杂。
然而，Scaleway的政策也造成了这种情况。坦率地说，在没有预留的情况下，在断电的几分钟内将C2实例泄露出去是不可接受的。特别是考虑到关闭它似乎需要遵循官方手册来迁移到不同的现代实例，以创建所需的快照。就我记忆所及，在联机时试图拍摄快照的语言并没有建议使用待机模式，而是建议完全关机。在任何情况下，Scaleway都不应该允许旧的C2实例无法重启的情况。
第三，从dev安装程序恢复文件不是一个好主意。sshfs上载花费的时间太长。最好完全专注于速度更快的Borg备份。
但第四，博格人的备份即使完成也是不够的。恢复过程需要考虑到新服务器可能是不同的Linux发行版，并且必须尽可能快。PC-Kombo背后的webapp是一个Ruby/Sinatra应用程序(这种情况增加了我对该方法的其他负面看法，需要说明的是，除了这一点，我还喜欢使用它)。这意味着设置它涉及到相当多的系统配置。需要安装系统依赖项，必须决定是否使用RVM，需要重新安装gem，等等。在压力下做所有这些工作是痛苦的。如果应用程序可以作为单个二进制文件分发，事情会容易得多。可悲的是，我所知道的所有项目，比如ruby-Packer和Travel-ruby，都被放弃了，而且不完整，它们的目的是从ruby项目创建这样的二进制文件。要为PC-Kombo和大多数Ruby项目工作，需要支持像sqlite3-ruby这样的非纯ruby宝石。我现在把赌注押在AppImage上，认为它是解决这一问题的最佳解决方案(到目前为止，起点是：提供Ruby的构建脚本)，并计划在那里投入更多工作。
这些都是我可以从停机时间中学到的教训。另外，我可能会说这真的很有压力。谢天谢地，这不是我第一次经历这样的事情，我知道如何保持冷静，但如果这是你自己的项目和钱在网上，压力水平自然会比平时高得多。