最近在我的绿联NAS上折腾LVM cache，配了个只读缓存想提升点性能。结果进SSH 折腾了LVM Cache的配置，结果系统卡死了，WebUI 进入桌面会卡死，SSH 操作一下硬盘存储相关的命令也会卡死。

当时心想，既然是只读缓存，直接把SSD拔了不就行了嘛。拔了之后进绿联系统一看整个存储池直接损坏。

绿联的UI里不支持强制移除缓存，WEB UI 的说法是只能删掉整个存储池重建。

不过我通过SSH先自己试了一下，居然把数据捞回来了。后面也搞清楚了工程师是怎么帮我修的。记录一下整个过程，万一有人遇到同样的情况可以参考。

第一步：自己用SSH抢救

系统卡死后，我先尝试SSH登录NAS。登录成功后第一件事是看看LVM的状态。

root@Even-NAS:~# vgdisplay

能看到卷组还在，但逻辑卷应该是deactivated的状态。

LVM的archive目录里会存着历史配置，我进去翻了一下：

ls /etc/lvm/archive/

找到跟当前卷组名匹配的配置文件，然后用它恢复：

vgcfgrestore -f /etc/lvm/archive/ug_224439_1741062901_pool1_00188-1970012948.vg ug_224439_1741062901_pool1

输出：

Restored volume group ug_224439_1741062901_pool1.

然后激活卷组：

vgchange -ay

1 logical volume(s) in volume group "ug_224439_1741062901_pool1" now active

这时候逻辑卷已经起来了，磁盘阵列也能挂载上了。

第二步：Web UI还是报损

挂载成功不代表万事大吉。我回到绿联的Web管理界面一看，存储池仍然显示”损毁”状态。

这是因为绿联有自己的存储管理服务，负责识别和自动挂载存储池。光靠LVM层面的恢复，绿联的存储服务并不知道存储池已经恢复了。

我试着重启了NAS，期望存储服务能重新扫描到存储池。结果重启之后，存储池又没挂上。

问题在于绿联的存储管理服务没有自动识别到这个已经恢复的卷组，或者它的状态记录还停留在”损毁”。

第三步：联系工程师

实在搞不定，就联系了绿联的客服工程师。工程师远程帮我处理了一下，存储池就恢复正常了，Web UI也不报损了。

不过工程师是怎么操作的，我没有全程盯着看。后来存储池恢复之后，我翻了命令历史，大致还原出了工程师的处理过程。

事后复盘：工程师大概率做了什么

工程师处理完之后，我去查了bash history，看到了一组命令：

cd /etc/
cd nas_storage
cp -rf nas_storage/ nas_storage.bak
sqlite3 storage_db.db
systemctl restart storage_serv.service

大概的流程是这样的：

  1. 进入/etc/nas_storage目录，这是绿联存储服务存放配置的地方
  2. 先备份了整个目录（nas_storage.bak），这个习惯很好
  3. 操作了storage_db.db这个SQLite数据库，里面存的应该是绿联对存储池状态的记录
  4. 最后重启了storage_serv.service服务，让绿联的存储服务重新加载配置

我猜工程师在sqlite里做的操作大概是把存储池的状态从”损毁”改回了正常，或者清除了缓存相关的标记。具体sql操作我没有追问，因为已经恢复成功了。

总结

这次折腾下来有几个教训：

  • LVM cache不管是只读还是读写，都别随便拔盘。拔了就是搞崩存储池
  • 通过SSH用vgcfgrestore可以恢复卷组配置，但这只是LVM层面的恢复
  • 绿联有自己的存储服务来管理存储池，光恢复LVM不够，还需要让绿联的服务重新识别
  • 如果搞不定，找工程师恢复也是个办法，至少知道恢复的大致流程
  • 工程师的操作核心就是改绿联的存储数据库，然后重启存储服务