2024，七月初某日，年初购入的西数 SN580 2T 在一次重启后突然罢工。排查后注意到无法读写、块设备间或可被识别。Smart 信息和分区表均不能读取。奇怪的是，Fedora Live 自带的 Gnome Partitioning Tool 能识别出硬盘厂商和部分正确大小的分区。但一番折腾后仍完全读不出数据，遂放弃、联系售后。

遗憾的是具体错误日志和报错信息并没有保存，无法展示。

受灾范围

我在笔电上安装了 Windows 11 和 Arch Linux 双系统，罪魁祸首西数 SN580 2T 按容量对半分给

  • Arch Linux 的 Btrfs，子卷包含根目录及家目录等所有目录。
  • Windows 系统分区 C:\

高考结后旧主机的重要数据、拾掇出的初中所用 Thinkpad 里的数据、以及大一至大二上的全部数据几乎都在 SN850 Windows 系统分区的用户目录下。大二下由于主力系统迁移回 Arch，数据集中存于 Btrfs。由于掉盘突然且彻底、且原硬盘是固态硬盘，直接的数据恢复不大可能。

此外还有一块幸存的 Windows 数据盘，是高考后购入的三星 980 1T，尽管被我嫌弃无缓 + 中低端，但还是勤勤恳恳撑过两年，令人感叹。其中数据为备份的手机照片、Vegrant 和 Virtual Box 虚拟机的磁盘镜像、及 Steam 的游戏仓库。

重新配置环境

硬盘送修需要时间、为了有盘用而新购入的海力士 P41（非 Plus）也要三天才能送到。幸存的数据盘内数据除了不重要、可再获取的游戏／虚拟机磁盘镜像，就只有在 Google Photos 和 Homelab 上均有备份的照片库，为了有能用的电脑，先果断格了重装。

Arch 的重新安装相对简单，按下不表。将 Windows 安装媒介通过 Rufus 启动：惊喜出现：本地硬盘神秘失踪。起初以为是 Rufus 的问题，但写好裸的 Windows 安装媒介盘同样无法识别任何一个硬盘。Google，这是因为幻 16 Intel 的 Rapid Storage Technology 需要在 Windows 上安装专用驱动。都 2024 年了……

漫长的数据恢复

Windows 11 / 10 中，在控制面板下，仍可访问被废弃但尚未移除的 Legacy 系统备份与恢复工具，提供文件备份和磁盘镜像备份两种备份方式，之前两种都有做。

ADisasRec-WindowsLegacyBackup.png

从 Windows 文件备份恢复数据

在仓库盘里先找到了以备份时系统主机名命名的文件夹，其子目录为对应备份的时间。Windows 在子目录下将备份的文件以 Zip 归档存储、未加密。每一个归档文件采用与所备份的主机相同的目录结构、以盘符为最上一级目录。解压后合并即可；或者也可在 Windows 下访问对应目录，可直接列出、恢复已有的备份。

找到的数据中：

  • 2024-03-06 时年初迁移回 [Arch Linux](Arch Linux) 时的备份不全。
  • 2024-04-15 的数据是全量的非隐藏文件

合并两者就恢复了过半从 2022 年至 2024 年初的数据。

ADisasRec-WinBackupDir.png

从 Windows 磁盘镜像备份恢复数据

通过恢复镜像创建的 VHDX 并不能被 Windows 11 成功挂载：

ADisasRec-FailToMountVHDX.png

通过计算机管理得知 Windows 已挂载该虚拟磁盘、但并未分配盘符；磁盘管理器将整个数据分区识别为 RAW，而非应有的 NTFS。

ADisasRec-DiskImgRecgAsRAW.png

猜测是分区表错误，通过 testdisk 尝试恢复分区表，恢复完成后写入。

ADisasRec-repairGPTviaTestDisk.png

重新挂载后分区文件系统被正确识别为 NTFS。

ADisasRec-VHDX_FS_RecgAsRAW.png

该文件系统中包含原系统用户权限，无法读取文件，在管理员权限下执行 takeown /f F:\ /r /d y 获取所有权后将所需文件复制出即获得了同为 2024 年初的数据。

插曲：丢失 key 目录的 Restic 仓库

原本 Windows 镜像/文件备份只是备份的备份，而主力备份通过 Restic 进行。试图提取数据时提示：

using temporary cache in C:\Users\yaoyu\AppData\Local\Temp\restic-check-cache-3354514141
create exclusive lock for repository
enter password for repository:
wrong password or no key found. Try again

GG。密码通过密码管理器直接输入，肯定不是输入错误。怀着不好的预感，一看仓库，keys 文件夹丢了——而我只有另一半钥匙。keys 文件夹是潜在的 single point of failure 这一点显然没有在 restic 的文档中得到足够的强调，但总的来说，手上的 300G 锁死的数据还是我的问题。这里丢失的包括

  • 从初中至 2023 的照片集合（有备份）
  • Windows 用户文件夹（从上文中的磁盘镜像中恢复了不少）
  • 手机刷机期间备份的 Swift Backup 库：在拆机塞盒里的固态里存了一份学期末刷 Lineage 时的备份，所以应用数据并未损失。
  • 额外值得一提的，还有
    • Obsidian 库：始终多设备同步，所以只丢失了某几个历史快照
    • ssh 私钥：从上文的磁盘镜像里恢复；但重新配置环境期间已经将可以物理访问的设备的密钥对全换了一遍
    • Windows 应用数据：除了 QQ/微信，大部分个人服务本身都完全上云，所以没有丢失。
    • 游戏存档：Steam 云存档
    • 文档/视频/音乐等库文件夹中的个人/办公文件：如上，从磁盘镜像中恢复。

概括地说，所幸有额外备份除了导致我需要从 Windows 的文件/镜像备份里淘数据以外，丢失 Restic 库的密钥文件并没造成太多麻烦。

总结

之前一时兴起折腾的备份系统终于派上了用场，倒是换到 Arch 后疏于备份，导致 2024 上半年的大部分数据丢失：大都是些作业文件之类，没有严重损失。教训是备份频率和冗余量尽量尽量管够、已有的备份也要定时检查完整性。

新环境下照例用 Btrfs，但新增了

  • Snapper 打根目录快照，按不同周期打快照并按时间长度分粒度保留
  • AutoRestic 每晚备份 Arch 家目录到 4T 的冷备盘

此外建议手边多备几份容量充足的存储设备，不然出问题时挪都挪不过来……