记录一次fnos文件系统故障导致的磁盘无法挂载问题的解决方式

saltedfishjun 发布于 6 天前 13 次阅读 无~

AI 摘要

"创造力无限，手工 labor 的负担减少——在我们生活中，自动草稿已成为一个必不可少的工具。通过AI技术的介入，笔记的生成、写作的 suggestion 和 Editing 的推荐，让我们可以快速高效地完成我们的工作！但是，这种自动化带来了什么样的挑战和风险？让我们探索自动草稿的未来，及其对创造力和人工智能的影响。"

记录一次fnos文件系统故障导致的磁盘无法挂载问题的解决方式

!!!首先声明!!!

1.我本人是使用的raid卡组了raid1的,卡为lsi93628i

2.任何操作应该以尽可能完整的保留下数据为第一准则

3.如果你因为和我使用相同的操作导致数据丢失本人概不负责

4.文件系统为btrfs，博主本人为小白，大部分操作都是摸ai和大佬经验过河

注！ 如有操作方面问题欢迎大佬指正，同小白请勿轻易模仿

事件起因

这天本人回到家发现nas处于关机状态，感觉奇怪，因为本人电脑常年处于开机状态，到家时电脑并未关机但是nas处于关机的状态，本人当时就感到不妙，因为本人nas接入的太阳能发电系统，电脑关机了nas也不应该关机，好奇之下去查看太阳能发电系统发现系统关!机!了!。

此时本人并未发现事情的严重性，于是直接开机太阳能发电系统。接着开机nas，等nas完全开机后登录web管理界面发现有一个硬盘笼里面的两个阵列处于未激活的状态，于是激活并挂载上，此时还未发现问题，接下来第二天又出现了这个问题，但是相对的严重了点，因为我的盘居然在系统里面显示被移除了，我当时那个慌啊，甚至怀疑两个阵列组一起寄了，因为本人又是阵列卡小白，只能查资料解决，发现只是两个阵列的硬盘处于外来状态很好解决，此时心大的博主还没意识到问题的严重性

接下来两天都出现了相同的问题，太阳能发电系统莫名其妙关机了（其实是电池没电了，但是市电又没充电）导致nas都关机开机出现问题，直到这条突然我的存储资料的硬盘挂载不上了，博主开始慌了

好了，故事说完了，接下来就是博主的解决尝试的路径了，我会把查到的相关资料贴上以供参考

第一次尝试，fnos论坛的解决方式

发现不对的第一时间博主选择在互联网上查找相关问题的解决办法于是查到了这个

关于存储空间显示未挂载的情况 - 新手入门 飞牛私有云论坛 fnOS

根据教程进行尝试发现虽然能够挂载为只读硬盘，但是并不能把数据完整的拷贝出来，且文件管理器里面也没有这块硬盘的文件夹

操作步骤

第一步：SSH 登录设备并查找目标设备

首先，通过 SSH 登录到你的设备。登录成功后，以 root 用户身份执行以下命令：

lsblk -fp

通过该命令找出不能挂载的存储空间所对应的设备。执行命令后，你会看到一系列设备信息，从中找到类似 /dev/mapper/trim_77ecf8b7_97e4_4664_8a5e_a441ea2cde3a-0 这样的设备路径，这就是我们要找的目标设备。

第二步：尝试挂载目标设备

使用以下命令尝试挂载该设备：

mount -t btrfs -o ro,usebackuproot,rescue=all /dev/mapper/trim_77ecf8b7_97e4_4664_8a5e_a441ea2cde3a-0 /vol1

这里需要注意的是，/vol1 要对应正确的存储空间序号，你需要根据自己设备的实际情况进行调整。

其中 ​trim_77ecf8b7_97e4_4664_8a5e_a441ea2cde3a-0​​这段需要替换成你通过 ​lsblk -fp​​查询到的需要挂载的设备路径

第三步：查看挂载情况并拷贝文件

完成挂载操作后，查看存储空间管理界面，应该能看到一个只读挂载的存储空间。可以通过文件管理器拷贝出来，如果在文件管理器内看不到文件，还可以在命令行下进行查看或者添加新的存储空间。

按照以上步骤操作，可将存储空间通过只读挂载并拷贝出文件。如果在操作过程中遇到任何问题，请私信提供联系方式/发帖到bug反馈版块中。

该教程应该适用于大部分情况，但很显然我不属于大部分情况，问题未得到解决

第二次尝试，dd命令

接下来博主又查找了其他方式。第一个为使用dd命令全屏镜像，但是很显然因为博主是小白，并不清楚dd命令是怎样的执行逻辑，所以浪费了一晚上时间

因为博主不知道dd命令的逻辑，也不知道怎么针对性的拷贝文件，所以博主本人使用了全盘拷贝，但悲哀的是出问题的硬盘为10t而用来接收数据的硬盘只有3.7t，所以该方案在博主这注定会失败，但应该适合两块盘大小相同的人进行数据恢复或拷贝的人进行尝试

linux dd实现磁盘完整全盘镜像备份backup,恢复recover(restore) - 秦瑞It行程实录 - 博客园

于是博主使用了全盘镜像备份

dd if=/dev/sda of=/dev/sdb

此命令表示把硬盘sda全盘拷贝镜像到硬盘sdb， 需要保证目标盘sdb容量大于等于源盘sda，且会清空目标盘sdb，所以还需要保证目标硬盘sdb的数据不需要或者已经完全备份

因为博主的目标盘远远小于源盘的容量，所以最后以失败告终

第三次尝试，deepseek的多种方案尝试

其实直到这一步我都没想起来我是组了raid1阵列的，所以操作比较畏惧，且因为没有相关经验导致给出的信息不足所以大部分操作都为尝试

  1. 询问ai后的第一个尝试，使用rsync工具复制数据

    1. 操作步骤

      1. 连接磁盘并确认标识符
        将您的10T大盘和3.7T小盘都连接到机器上。然后使用 lsblk​ 或 fdisk -l​ 命令确认它们的系统标识符（比如 /dev/sdb​ 和 /dev/sdc​）。请务必再三确认哪个是源盘，哪个是目标盘，操作反了会导致数据全部丢失！
        bash

        root@fnos:~# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0 111.8G  0 disk
├─sda1        8:1    0   512M  0 part /boot/efi
└─sda2        8:2    0 111.3G  0 part /var/log
sdb           8:16   0   10T   0 disk           # <--- 这是你的10T大盘
└─sdb1        8:17   0   10T   0 part
sdc           8:32   0   3.7T  0 disk           # <--- 这是你的3.7T小盘

        假设您的源盘是 ​/dev/sdb​​ ，它有一个分区 ​/dev/sdb1​​ 。目标盘是 ​/dev/sdc​​ 。

      2. 格式化目标盘（小盘）
        小盘现在是空的，需要先创建文件系统（格式化）。
        bash

        # 假设目标盘是 /dev/sdc
# 使用 mkfs 命令创建一个文件系统，例如 ext4（Linux常用）
root@fnos:~# mkfs.ext4 /dev/sdc

        注意：此操作会清空 ​/dev/sdc​​ 上的所有数据！

      3. 挂载磁盘
        创建两个挂载点，并将源盘和目标盘都挂载上来。
        bash

        # 创建临时挂载点
root@fnos:~# mkdir /mnt/source
root@fnos:~# mkdir /mnt/target

# 挂载源盘（假设它的分区是 /dev/sdb1）
root@fnos:~# mount /dev/sdb1 /mnt/source

# 挂载目标盘
root@fnos:~# mount /dev/sdc /mnt/target

      4. 使用 ​rsync​​ 复制数据
        ​rsync 是强大的文件同步工具，非常适合此任务。
        bash

        root@fnos:~# rsync -avh --progress /mnt/source/ /mnt/target/
        • ​-a: 归档模式，保留所有文件属性（权限、所有者、时间戳等）。
        • ​-v: 显示详细过程。
        • ​-h: 以人类可读的格式输出数字。
        • ​--progress: 显示传输进度。
        • ​注意参数后的 ​/​ ​：source/​ 表示复制该目录下的​内容​，target/​ 表示复制到该目录下。如果不用 /​，则会在目标目录下创建一个 source 文件夹。

      5. 等待复制完成并验证
        等待命令运行完毕。完成后，您可以查看一下目标盘的数据量，确认是否复制完整。
        bash

        root@fnos:~# df -h /mnt/target # 查看挂载点容量使用情况
root@fnos:~# ls -lah /mnt/target # 查看文件列表

      6. 卸载磁盘
        数据复制完成后，安全地卸载磁盘。
        bash

        root@fnos:~# umount /mnt/source
root@fnos:~# umount /mnt/target
root@fnos:~# rmdir /mnt/source /mnt/target # 删除临时挂载点

      现在，您的 3.7T 小盘就已经包含了原来大盘里所有的数据，可以正常使用了。

    2. 经过尝试只能复制出很小部分数据，所以宣告失败

  2. 经过多次询问ai把过程输出发送给ai进行信息校准于是有了第二个方式的尝试

    1. 操作步骤

      1. 1. 使用 BTRFS 恢复工具尝试恢复文件

        bash

        # 确保源文件系统未挂载
umount /vol3

# 创建恢复目录
mkdir -p /vol2/recovered_data

# 使用 btrfs restore 尝试恢复文件
btrfs restore -v /dev/mapper/trim_3e754d94_3455_4091_a3b4_e3dce0914dae-0 /vol2/recovered_data

        2. 尝试修复文件系统（谨慎使用）

        如果恢复工具无法正常工作，可以尝试修复文件系统：

        bash

        # 首先尝试只读检查
btrfs check --readonly /dev/mapper/trim_3e754d94_3455_4091_a3b4_e3dce0914dae-0

# 如果发现问题，尝试修复（有风险！）
btrfs check --repair /dev/mapper/trim_3e754d94_3455_4091_a3b4_e3dce0914dae-0

        3. 使用 BTRFS 发送/接收功能

        如果文件系统可以挂载但某些文件无法访问，可以尝试使用 BTRFS 的发送/接收功能：

        bash

        # 创建只读快照
btrfs subvolume snapshot -r /vol3 /vol3/snapshot_backup

# 发送快照到目标位置
btrfs send /vol3/snapshot_backup | btrfs receive /vol2/

# 删除快照
btrfs subvolume delete /vol3/snapshot_backup

        4. 尝试挂载为只读并复制

        如果文件系统可以挂载，尝试以只读方式挂载并复制：

        bash

        # 以只读方式挂载
mount -o ro /dev/mapper/trim_3e754d94_3455_4091_a3b4_e3dce0914dae-0 /mnt/source

# 尝试使用 rsync 复制，跳过无法访问的文件
rsync -avh --progress --ignore-errors /mnt/source/ /vol2/backup_from_vol3/

# 卸载
umount /mnt/source

        5. 使用专业数据恢复工具

        如果以上方法都失败，可以考虑使用专业的数据恢复工具：

        bash

        # 安装并使用 extundelete（虽然主要用于 ext 文件系统，但有时对 BTRFS 也有用）
apt install extundelete
extundelete /dev/mapper/trim_3e754d94_3455_4091_a3b4_e3dce0914dae-0 --restore-all --output-dir /vol2/recovered_data

# 或使用 photorec
photorec /dev/mapper/trim_3e754d94_3455_4091_a3b4_e3dce0914dae-0

        推荐的操作顺序

        1. 首先尝试 btrfs restore 命令，这是最安全的方法
        2. 如果不行，尝试创建只读快照并使用发送/接收功能
        3. 如果仍然不行，尝试以只读方式挂载并使用 rsync --ignore-errors
        4. 最后考虑使用修复选项或专业工具

        重要注意事项

        1. ​优先保护源数据：在任何操作前，确保源文件系统以只读方式访问
        2. ​备份重要数据：如果可能，先备份当前状态
        3. ​记录操作过程：记录您尝试的每一步及其结果，这有助于诊断问题
        4. 考虑专业帮助：如果数据非常重要，考虑寻求专业数据恢复服务的帮助
    2. 因为过程中尝试修复有风险，所以我没有使用修复尝试，而是使用 btrfs restore 尝试恢复文件和BTRFS文件系统的快照接受和发送功能。但是恢复文件和快照创建失败，所以方式宣告失败（其实也不是完全失败，在尝试恢复文件过程中恢复了26g的文件）

  3. 经过持续询问和突然想起来我是raid1，所以有了以下尝试

    1. 关机进入raid卡管理界面下线其中一块硬盘并物理拔出

    2. 开机重新尝试数据恢复，使用了以下命令

      # 重新扫描设备
rescan-scsi-bus.sh

# 检查设备状态
lsblk
cat /proc/mdstat

# 尝试挂载文件系统（使用救援选项）
mount -t btrfs -o ro,usebackuproot,rescue=all /dev/mapper/trim_3e754d94_3455_4091_a3b4_e3dce0914dae-0 /vol3

# 尝试数据恢复
rsync -avh --progress --ignore-errors /vol3/ /vol2/backup_from_vol3/

    3. 经过尝试依旧同上一个方案只能恢复26g的数据，这显然不是我们要的，现在我们依旧拔掉了阵列中的一块硬盘，所以我们可以进行更激进大胆的尝试，修复文件，以下为修复步骤

      # 尝试修复文件系统
btrfs check --repair --force /dev/mapper/trim_3e754d94_3455_4091_a3b4_e3dce0914dae-0

# 或者尝试其他恢复工具
btrfs restore -i -v /dev/mapper/trim_3e754d94_3455_4091_a3b4_e3dce0914dae-0 /vol2/recovered_data
    4. 经过修复后再次使用数据恢复，这次恢复了1.3t的数据，虽然丢失了0.27t的数据，但是经过查看重要数据已经完成了拷贝，所以博主直接重建了该盘的文件系统然后把数据进行拷贝还原
  4. 完成后我们还需要重建阵列，关机后进入raid卡管理界面，插入硬盘后进行相关操作然后等待重建阵列完成即可

到此，我们的数据恢复就算大功告成了，虽然过程充满了艰辛，但是结果是好的

此作者没有提供个人介绍。
最后更新于 2025-10-17