业内新闻

阿里云重启完数据盘没有了？一个老工程师的现场记录

你是不是也遇到过，阿里云ECS重启之后，数据盘突然就消失了？登录控制台，磁盘列表里只剩系统盘，挂载点空空如也，数据盘像是人间蒸发。别急，这事儿我处理过不下几十次，今天就把真实思路和步骤写出来，不一定按顺序来，想到哪说到哪。

www.fixhdd.cn

先说一个让我印象挺深的案例。去年年底有个客户，某电商公司运维，半夜重启了一台跑MySQL的ECS，结果重启完数据盘没有了。他当时快疯了——业务直接挂掉，监控告警响个不停。控制台里看，磁盘列表只有/dev/vda1（系统盘），原本挂载在/data的/dev/vdb1不见了，但ECS详情页的“云盘”标签里还显示这块盘“已挂载”。 www.fixhdd.cn

关键判断点：控制台显示“已挂载”但系统内看不到，基本不是云盘被卸载，而是系统层面的挂载丢失或驱动问题。这个区别很重要，因为后续操作完全不同。技王数据恢复

我当时远程上去，先让他别重启，也别重置系统。然后一步步排查。先执行lsblk，结果只有vda，没有vdb。再fdisk -l，也没列出数据盘。心里咯噔一下——难道是磁盘被热移除？但阿里云API里磁盘状态是“使用中”。后来通过cat /proc/partitions发现根本没有vdb的块设备号。这大概率是实例内部驱动的bug，或者内核声卡？不对，说错了，是内核模块没加载。特别是使用了某些自定义镜像或者旧内核的实例，重启后virtio驱动未重新扫描。技王数据恢复

第一步：冷静判断，别乱操作

大部分人遇到阿里云重启完数据盘没有了，第一反应是去控制台“卸载”再“挂载”，甚至直接重启第二次。千万别！卸载操作会让云盘从实例解绑，如果文件系统有异常，可能造成metadata损坏，后面恢复难度翻倍。

技王数据恢复

先看控制台云盘状态：如果显示“挂载中”或“已挂载”，说明阿里云底层认定这块盘绑定正常。
检查ECS系统内是否识别：用ls /sys/block/看看有没有vdb、xvd等设备名。
内核日志：dmesg | grep -i vdb 或 dmesg | grep -i block，经常能看到类似“virtio_blk: probe of virtio2 failed with error -22”的报错。

第二个案例，一个做AI训练的小团队，重启后数据盘也丢了，而且他们更急——因为训练数据全在/opt/data上。我让他们通过阿里云控制台的“远程连接”用VNC进去，执行echo 1 > /sys/bus/pci/rescan，结果奇迹般地出现了vdb。这个方法在80%以上的驱动没挂载场景有效。但注意，如果是NVMe云盘，命令不同，要用echo 1 > /sys/bus/pci/drivers/nvme/rescan（实际上NVMe是/sys/bus/pci/drivers/nvme，但阿里云大多用virtio，不是NVMe）。

www.fixhdd.cn

如果rescann没反应？试试重新挂载驱动模块

对于CentOS 7/8，可以尝试modprobe -r virtio_blk && modprobe virtio_blk。风险在于卸载模块时如果系统盘也在virtio上，会导致系统崩溃。我一般只在有其他控制台辅助的情况下才用。有一次我帮一个用户这么做，结果模块卸载后系统卡死，只能用控制台强制重启——好在重启后数据盘自动回来了。这不科学，但确实发生了。 www.fixhdd.cn

顺便提一句，技王数据恢复的同事当年在处理一个类似案例时，遇到过更奇葩的：云盘在控制台显示“已挂载”，但内核里连virtio总线都找不到。查出来是用户误删了/lib/modules下的内核模块文件，重启后virtio驱动缺失。我们团队后来都会让客户先检查一下/lib/modules/$(uname -r)/kernel/drivers/block/里有没有virtio_blk.ko。技王数据恢复

中段：更深层的排查与恢复

刚才说的都是“假丢失”，但确实有一小部分是真实的数据盘被误操作卸载或释放了。判断方法：控制台云盘列表里如果找不到该数据盘，或者状态是“待挂载”、“已释放”，那就真麻烦了。特别是“释放”意味着磁盘可能已经被销毁，数据基本没救……除非有自动快照。

有一次客户说“阿里云重启完数据盘没有了”，我一看控制台，磁盘列表里什么都没有。追问下他承认，重启前手动在控制台点了“卸载”，然后忘记挂载了，重启后盘自然就没了。但这其实不算真丢，重新挂载就行。只要挂载点没变，文件系统还能直接mount。注意：挂载时指定正确的设备名，比如/dev/vdb1，或者用UUID。

最让人头疼的是文件系统损坏导致mount失败，系统里能看见设备，但挂载时报错“unknown filesystem type”或者“wrong fs type”。这种情况，数据其实还在，需要用fsck修复，或者用数据恢复工具扫描。比如ext4文件系统，先尝试fsck -n /dev/vdb1看错误，再用fsck -y修复。但一定要先备份磁盘快照，否则fsck可能让数据更糟。

经验教训：快照才是终极保险

不管问题大小，阿里云重启完数据盘没有了，第一件事应该去ECS控制台看“快照”。如果有自动快照策略，直接回滚到重启前的快照，最省心。没有快照？那只能走下面几种方式：

使用数据恢复工具：比如testdisk、photorec。在一个相同内核的临时实例上挂载受损磁盘的镜像（通过快照或从控制台创建云盘挂载到其他实例），扫描恢复文件。
联系阿里云售后：他们可以尝试后台强制重新扫描总线，但成功率看运气。
找专业数据恢复机构：比如我们技王数据恢复，遇到过客户磁盘被误释放后通过底层物理恢复的案例——但云上物理恢复基本不可能，因为磁盘是分布式存储。我们更多是处理文件系统逻辑损坏。

再讲一个有点戏剧性的案例。有个做视频素材的up主，阿里云ECS重启完数据盘没有了，急得直接打电话骂客服。我让他先别急，执行mount -a，结果fstab里没写。他根本不知道数据盘之前是怎么挂载的。后来通过blkid发现有个设备有文件系统签名，但设备名是/dev/vdc？奇怪，之前挂载的是/dev/vdb。实际上重启后设备名可能被操作系统重新分配，比如从vdb变成了vdc。检查/etc/fstab里的UUID，如果没有用UUID而是用了设备名，就会挂载失败。：强烈建议用UUID挂载数据盘。