周五的时候我的服务器突然内核报错,连不上 ssh 也 无法重启。经过了迂回的各种抢救方案,终于救回了一千多张图床的的图片,心有余悸,记录一下救援过程,顺便折腾了一套新的图床方案。

服务器救援

这台服务器大约已经稳定运行了一年半,运行了我许多重要服务,还有我博客图床的一千多张无备份的图片通过 Docker Volume 持久化在主机上。

服务器宕机

其实我至今仍不知道出了什么问题,早上刚好需要更新服务器上的我运行的 RSSHub 实例的镜像版本,于是想着干脆把所有服务都更新到最新吧,于是一通 docker pulldocker-compose 重启操作,前面的都没什么问题,直到最后一个服务突然启动容器失败,报了一个类似 not enough space 的错误,我心想着可能是下载的镜像太多了导致磁盘满了,于是又一通 docker image prune --alldocker volume prunedocker system prune 操作,释放出了接近 10G 的空间,重试,依然不行。

作为一个有且仅有一点服务器运维经验的开发来说,我第一反应想到的就是重启,未曾想,这才是一天噩梦的开始。

DpEIbC2WUo9XGgx4PoLcEaLinGf

没想到重启后我的 Uptime Kuma 提醒我所有服务都下线了,也无法再通过 ssh 连上机子了。

KCyibCBPTogkAYxCuXOcjUEEnIg

于是赶紧登录到服务器的线上控制台,发现内核报错,无法启动,强制重启也依然不生效,并且赶紧求援我的 DevOps 朋友们。

拯救数据

STRRL 说应该 rootfs 出现了问题,不过鉴于我的服务器云厂商并没有提供什么高级启动等额外的功能,这条路堵住了。但想到我有一年半毫无备份的图床数据在上面,依然不甘心,于是开始想办法抢救数据。

Rj41b42odoBQ5PxQbcbcuytQnTf

研究了一下服务器的控制台,发现它提供一个大约每周一次的备份,并且可以一键将备份转为快照,最近的一次在 6 月 22 日,还好。我首先想到的是直接通过快照恢复机器,如果是我今天的操作导致了什么配置问题,那理应一周前的快照是能正常启动的,于是满怀信心地等待了十几分钟的快照恢复,结果报了同样的错误。依然不死心,把 6 月 15 的备份也恢复了一下,还是不行。

这下意识到了事情的严重性,甚至做好了数据全部丢失的最坏打算,同时开始检索类似情况,最后发现服务器的快照镜像是可以下载的。

于是先下载了快照镜像,得到了一个 .disk 文件,这个文件应该是一个专属格式,可以通过 Virtual Box 的命令行工具 vboxmanage convertfromraw 来进行格式转换,但官网下载后发现并不支持 M 芯片的 Mac,于是又在之前的老 19 款 Intel Mac 上安装并且执行转换,得到了一个 .vmdk 文件。

转换完成后将这个 .vmdk 作为一个磁盘挂载到 Virtual Box CentOS 虚拟机上,发现依然报同样的错误。

GjSFb2nmyoyVbgxMEK4cd9t7noe

于是另辟蹊径,发现 7-Zip 软件支持常见虚拟机格式的解压,但客户端只有 Windows 版本。

HIZGbOm1FoJLjqx17chcQcuOnke

虽然按理说可以在 macOS 上使用命令行版本 p7zip 来执行,但我解压时会报错,所以又堵住了一条路,想了个曲线救国的方式,通过虚拟机下载了一个 Win11,下载了 7-Zip 软件直接解压成功了。

问题又来了,解压得到的是 1.img2.img 这样格式的 Linux 磁盘镜像文件,macOS 上无法加载,又用 fuse 折腾了一下,还是无法加载。

A4VxboRf7o3SXExEJuTca6BgnQd

期间倒也是有好消息,在全网搜罗的时候发现了一个数据恢复软件 UFS Explorer,尝试了一下可以正常加载,只是超过 768k 的文件则需要付费,当然没打算,看到文件确实是可以识读之后心里就安心了许多,至少数据还在,剩下都是技术问题了。

STRRL 告诉我 OrbStack 可以启动一个 Linux Machine,然后可以把这个 img 作为一个 Linux 磁盘挂载上去。

sudo losetup -fP 1.img
mkdir /mnt/bwg

sudo mount /dev/loop0 /mnt/bwg

通过以上命令成功把我的 img 磁盘镜像挂载到了 OrbStack 的 Ununtu 机器上。

Q1Ygb0O9FoDsv5xOSeLc36oVnxb

当我看到我的图片出现在命令行输出结果时,感动得都快流泪了 😭。

tar -czvf cheverto_chevereto_images.tar.gz cheverto_chevereto_images/

rsync -acvP ./cheverto_chevereto_images.tar.gz pseudoyu@[yu-mac-studio]:~/Downloads/
HQscbjZ6LolKM0xrOqecqQIznpd

紧接着赶紧打个 tar 包,然后通过 rsync 传到了我本地的 Mac 上,本机解压后,终于看到了我所有的图片。

迁移图床系统至 r2

但由于这一次的遭遇,不再信任服务器单机部署的图床稳定性了,花了半天折腾了一套新的免费图床系统 —— 「从零开始搭建你的免费图床系统 (Cloudflare R2 + WebP Cloud + PicGo)」。

UoHHb8TBAoMmIux9zbqcBK6tnh9

至于现有的数据传到 r2,我则是使用了 rclone 来进行上传,彻底完成迁移,大功告成!

总结

经过这么一次,我也开始重新考虑了服务部署、数据安全等问题,准备还是将一些重要的数据上云而不再依赖单机,也继续把一些服务迁移到 fly.io、Zeabur 等 serverless 平台。

> 下载少数派 客户端、关注 少数派小红书,感受精彩数字生活 🍃

> 实用、好用的 正版软件,少数派为你呈现 🚀