欢迎观看这一篇极具个人恩怨情仇的文章。

正如标题所言，故事的开始，源于我一时的手贱，在服务器上运行了一个所谓的bbr优化脚本（明明Linux内核早已原生支持bbr……）。大概是一时脑子抽了罢。

寻思着评论区一堆人跑过都没事，我也顺手在Rocky系统上敲了下去。结果呢？

《诶，什么叫自动移除了十几个内核》

《诶，我ssh怎么连不上了》

《诶，我vnc怎么直接进了grub命令行》

故事的开端，大概就是这样子的。

---

用vnc连上后，只看到一个孤零零的grub命令行。系统直接卡在引导器阶段，根本进不去（就像Windows坏了，只剩绝望的BIOS界面一样）

ls到硬盘中，发现少了个系统内核vmlinuz。ChatGPT和Gemini都说这种情况天王老子来了都救不了。手搓 grub 修复……感觉蛮复杂的，于是只能另辟蹊径了。

大概……是这样恢复的。（数据恢复的万能流程）

1. 把坏掉的系统盘打个镜像
2. 新开一台临时服务器（作为“中转站”）
3. 把镜像作为数据盘挂载到临时服务器
4. 给原服务器重装健康的系统
5. 从临时服务器的数据盘里，把网站数据迁回原服务器

貌似……挺麻烦的，但这是唯一解了。

这次事故，三年的博客数据差点没了。

---

打好镜像后，为了省钱，我开了台1c4g的按时付费云服务器，外加公网带宽，一小时八毛左右，还算能接受。

在开通的临时服务器挂载好镜像后，可以看到原先坏掉的系统盘中的数据。至少不必担心数据消失了

原服务器系统重装好后，真正折磨人的环节才开始：数据迁移。相信大部分经常换服务器的博主也能体验到这种艰辛吧，尤其是像我这种不能整盘镜像迁移的，只能一个个文件夹手动同步，说多了都是泪啊……

# 一、安装基础服务
apt install -y rsync openssh-server
# 确保服务启动
systemctl enable ssh --now

# 二、网站核心数据
rsync -avz --progress /mnt/old/www/wwwroot/ root@老服务器IP:/www/wwwroot/

# 三、数据库
rsync -avz --progress /mnt/old/www/server/data/ root@老服务器IP:/www/server/data/

# 四、一坨配置文件
rsync -avz --progress /mnt/old/www/server/nginx/conf/ root@老服务器IP:/www/server/nginx/conf/
rsync -avz --progress /mnt/old/www/server/panel/vhost/nginx/ root@老服务器IP:/www/server/panel/vhost/nginx/
rsync -avz --progress /mnt/old/www/server/php/ root@老服务器IP:/www/server/php/
rsync -avz --progress /mnt/old/www/server/panel/data/ root@老服务器IP:/www/server/panel/data/
rsync -avz --progress /mnt/old/www/server/panel/vhost/ root@老服务器IP:/www/server/panel/vhost/

# 五、docker
rsync -avz --progress /mnt/old/var/lib/docker/ root@老服务器IP:/var/lib/docker/
rsync -avz --progress /mnt/old/root/docker/ root@老服务器IP:/root/docker/

# 六、定时任务
rsync -avz --progress /mnt/old/var/spool/cron/ root@老服务器IP:/var/spool/cron/

# 七、一堆SSL证书
rsync -avz --progress /mnt/old/www/server/panel/vhost/cert/ root@老服务器IP:/www/server/panel/vhost/cert/

到这，数据基本恢复完毕。

中间还踩了个坑：新装的系统+宝塔面板后，提示sshd版本不匹配——

OpenSSL version mismatch. Built against 30000010, you have 30500010

最后只能换成兼容性更好的Ubuntu才解决。（貌似之前也遇到过这种情况呢，详见Mimosa的小站-碎碎念#4838）

---

总结

1. 系统（或程序）能跑，就别手欠去动——尤其是生产环境。（虽然对于强迫症和完美主义者的Mimosa我而言这很难……）
2. 运行谜之脚本前一定瞟一眼。
3. 每次在手贱操作前问问自己：真的有效果吗？风险可控吗？有快速的回滚方案吗？
4. 别对某些不知名的云厂商（京东云）抱有太高期望，配套和技术支持，有时真的靠不住。
5. 数据备份真的很重要，最好搞个异地备份，服务器GG了还有的恢复。

这次因为一个脚本，折腾了整整一天，好在保住了四年博客的数据。

好像……明天就过年了。

至少在新的一年里，我会绝对践行这句话的：

“代码能跑，就别动。”