场景：
前几天，我试图“卸载”一些逻辑卷，以便可以关闭它们所在的 LUKS 分区。我不小心使用了lvremove我认为这是正确的命令；在我意识到它不是之后，我使用它之前创建的备份恢复了我的 LVM 配置lvremove。
设置：
我有一个带有单个 LUKS 分区的单个 SSD，其中有一个 LVM 分区，其中包含三个逻辑卷，分别用于交换、根和主卷。根和主卷是 ext4 文件系统。因此SSD(LUKS(LVM(交换,根(ext4),主(ext4))))
结论：
我已确定描述我的 ext4 文件系统的元数据已损坏。我知道这一点是因为我曾尝试使用以下方法修复它
e2fsck -f /dev/ubuntu/home
我尝试使用备份超级块进行修复
e2fsck -f -b 12345 /dev/ubuntu-vg/home
我曾经TestDisk尝试修复它
我尝试过使用extundelete（但找不到超级块）
我甚至查看了原始十六进制用法
xxd -a /dev/ubuntu-vg/home | less
并将其与正在运行的 ext4 文件系统进行了比较。
问题：
是否可以使用某种“深度扫描”恢复文件？
这是 LVM 和 SSD 的已知问题还是异常现象？
当 LVM 释放 SSD 上的内存块时，是否发生了 TRIM 操作或“磨损均衡”并损坏了数据？
答案1
我正在阅读有关使用逻辑卷的资料。我偶然发现了以下建议维基百科：
“警告：在删除逻辑卷之前，请确保将所有要保留的数据移至其他位置；否则，数据将会丢失！”
基于此，您的文件似乎是“丢失的“。当然，这并不意味着没有其他人知道如何恢复您丢失的文件。