跳到主要内容

数据备份与重建

· 阅读需 19 分钟
amass
amass
一个躺不平的板砖人

我有三台设备，准备重新分配硬盘。本文记录换盘前的备份步骤与换盘后的恢复步骤。

重组前​

N355 unRaid，其中：

XFS机械硬盘阵列：

  • ST1600ONT001-3LV101_ZRS0JTR1 - 16 TB (奇偶校验盘)
  • ST1600ONT001-3LV103_ZRS0JTEE - 16 TB (数据盘)
  • ST1600ONE000-2RW103_ZL2F1CL7 - 16 TB (数据盘)
  • ST1600ONE000-2RW103_ZL2PR2EN - 16 TB (数据盘)
  • ST1200ONE0008-2PK103_ZTN08BEM - 12 TB (数据盘)
  • WDC_WD40PURX-78AKYYO_WD-WX92DA06L221 - 4 TB (数据盘)

BTRFS raid1缓存池：

  • Seagate_ZP1000GV30012_71VO0RFY - 1 TB (nvme0n1)
  • Seagate_ZP1000GV30012_71VO0GR7 - 1 TB (nvme1n1)

Ultra 7 265K unRaid，三块 NVME 固态硬盘 + 一块 SATA3 固态硬盘组成的 ZFS RAIDZ1(1 vdev of 4 devices)池：

  • WD_Blue_SN5000_1TB_25105J804281 - 1 TB (nvme0n1)
  • Seagate_ZP1024CM30003_D2P00NX3 - 1 TB (nvme1n1)
  • Fanxiang_S690_1TB_FX232812233 - 1 TB (nvme2n1)
  • Fanxiang_S100Pro_1TB_MX_00000000000012217 - 1 TB (sdb)

i7-14700K Windows 11 PC主机，其中

  • HP SSD EX900 500GB，NVME PCIE3.0
  • Samsung SSD 860 EVO 500GB，SATA3

准备网购一个 宏碁 512G NVME 固态。

重组后​

N355 unRaid，其中：

XFS机械硬盘阵列（不变）：

  • ST1600ONT001-3LV101_ZRS0JTR1 - 16 TB (奇偶校验盘)
  • ST1600ONT001-3LV103_ZRS0JTEE - 16 TB (数据盘)
  • ST1600ONE000-2RW103_ZL2F1CL7 - 16 TB (数据盘)
  • ST1600ONE000-2RW103_ZL2PR2EN - 16 TB (数据盘)
  • ST1200ONE0008-2PK103_ZTN08BEM - 12 TB (数据盘)
  • WDC_WD40PURX-78AKYYO_WD-WX92DA06L221 - 4 TB (数据盘)

BTRFS raid1缓存池：

  • HP SSD EX900 500GB，NVME PCIE3.0
  • 网购的宏碁 512G NVME 固态

Ultra 7 265K unRaid，其中

四块 NVME 固态硬盘 ZFS RAIDZ1(1 vdev of 4 devices)池：

  • WD_Blue_SN5000_1TB_25105J804281 - 1 TB
  • Seagate_ZP1024CM30003_D2P00NX3 - 1 TB
  • Seagate_ZP1000GV30012_71VO0RFY - 1 TB
  • Seagate_ZP1000GV30012_71VO0GR7 - 1 TB

一块 Samsung SSD 860 EVO 500GB，SATA3 组成单盘 ZFS 池

i7-14700K Windows 11 PC主机，其中

  • Fanxiang_S690_1TB_FX232812233 - 1 TB (系统盘)
  • Fanxiang_S100Pro_1TB_MX_00000000000012217 - 1 TB (数据盘)

迁移总体思路​

硬盘是循环互换的：

硬盘从到新角色
Seagate ZP1000GV30012 ×2N355 缓存池Ultra 7RAIDZ1 成员
Fanxiang S690Ultra 7PC系统盘
Fanxiang S100ProUltra 7PC数据盘
HP EX900PCN355新缓存池成员
Samsung 860 EVOPCUltra 7单盘 ZFS 池
宏碁 512G（新购）—N355新缓存池成员

唯一不动的是 N355 机械阵列，它是全部数据的中转站。三条数据流：

  1. N355 缓存池 → 阵列（mover 撤离，重建缓存池后原路搬回）
  2. Ultra 7 ZFS 池 → 阵列（rsync over SSH，重建池后拉回）
  3. PC 两块盘 → 阵列（robocopy 到 SMB，重装系统后拉回）

Ultra 7 的池必须整体销毁：RAIDZ 顶层 vdev 不支持移除成员盘（见 zpool-remove(8)；unRaid 7.2 起 GUI 支持的 RAIDZ expansion 也只能加盘不能减盘）。

关键原则：物理换盘是不可逆点。换盘后各盘陆续被格式化，旧数据无法找回，所以全部备份校验通过之前绝不动硬件。换盘期间三台机器的数据全部集中在同一个阵列上（appdata 的 tar 包也在同一故障域内），只受单奇偶校验保护，真正不可替代的数据应另有一份离线或云端备份。

备份步骤​

〇、预检与准备​

  1. 硬件预检：重组后 Ultra 7 要同时插 4 块 M.2（现在只用 3 个槽），查主板手册确认有第 4 个空闲 M.2 槽（2280、NVMe 协议），以及该槽是否与 SATA 口共享通道（共享通道启用后可能禁用 860 EVO 要用的 SATA 口）；备好固定螺丝与散热片。这一步在备份开始前就要落实，否则会卡在盘已拆、装不进去的最尴尬位置。
  2. 两台 unRaid 各做一次引导盘备份：Main → Boot Device → Boot Device Backup 下载 zip，存到服务器之外（7.3 起 UI 中的 Flash 改称 Boot Device，7.2 及更早是 Flash → FLASH BACKUP）。
  3. 留档：zpool status -v、zfs list -o name,used,avail 输出，Shares 设置截图，Main 页阵列盘序列号截图；Ultra 7 如有虚拟机，逐个 virsh dumpxml 导出 XML 到 /boot。
  4. N355 新建中转 share migration（Primary storage: Array，不经过缓存——缓存马上要拆），下设 ultra7/、pc/ 子目录，开 SMB 私有访问给 PC 用。
  5. 两台 unRaid 暂停定时 mover（Settings → Scheduler），迁移期间全程用 Main → Move 手动触发，避免 share 设置改到一半时定时任务恰好开跑。
  6. 容量账：
    • 阵列空闲空间 ≥ Ultra 7 池实际数据量 + PC 数据量 + N355 缓存已用
    • Ultra 7 池的体量不要看 zfs list 的 used——池开了压缩时它远小于落到 XFS 上的真实占用，按 zfs list -o name,used,logicalused 的 logicalused（或 du -sb --apparent-size）估算，再留 10~20% 余量
    • 新缓存池可用约 465 GiB（BTRFS RAID1 取小盘）：确认 N355 现缓存占用低于此数，超了先清理
    • 新 RAIDZ1 实际可用约 2.6 TiB：确认 Ultra 7 现有数据装得回去
  7. 耗时账：1GbE 实跑约 100 MB/s，23 TB 需 69 小时；瓶颈常在 XFS 校验阵列的写入（50~120 MB/s），可临时开 Turbo write（Settings → Disk Settings → Tunable (md_write_method) → reconstruct write）。三条数据流可并行，但共享阵列写入带宽。

一、N355：缓存池撤到阵列​

  1. 给 appdata 加一层保险（二选一）：用 Appdata.Backup 插件（CA 中搜索，作者 KluthR）备份到阵列；或停掉容器后手动打包：

    tar -czf /mnt/user/migration/n355-appdata-$(date +%F).tar.gz -C /mnt/cache appdata

  2. 停服务：Settings → Docker → Enable Docker: No；Settings → VM Manager → Enable VMs: No。不停服务，docker.img/libvirt.img 始终被占用，mover 必然跳过它们。

  3. Shares 页逐个检查 Primary storage 为缓存池的 share，目标是 Mover action 全部指向 Cache → Array：

    • 常驻缓存的 share（appdata、system、domains 这类原 Secondary=None 或 Mover action 为 Array → Cache 的）：Secondary storage 设为 Array（否则 mover 没有目的地），Mover action 翻转为 Cache → Array。记下改动过哪些 share——回迁时只反转这一批
    • 写缓冲类 share（下载/媒体类，日常本就是 Cache → Array）：不用动，本轮 mover 会照常把它们冲到阵列，那就是它们的最终归宿，后面不回迁

  4. Main → Move，跑完确认缓存已空：

    ls -la /mnt/cache

    mover 不搬几类东西：被打开的文件、目标已有同名的文件、池顶层不属于任何 share 的散落文件（7.0.1 之前的版本还会跳过硬链接，7.3.1 无此问题）。开启 Mover logging（Settings → Scheduler → Mover Settings）后 syslog 会记录被跳过的文件。残留文件手动搬去阵列侧路径，如 mv /mnt/cache/<share>/x /mnt/user0/<share>/x 或 /mnt/diskN/<share>/；绝不要以 /mnt/user 为目标与 /mnt/cache 互拷——shfs 会把目标解析回缓存上的同一个文件，先截断再复制，文件直接清零消失，事后 /mnt/cache 照样是空的，察觉不到。

二、Ultra 7：ZFS 池全量推到 N355​

  1. 同样先停 Docker/VM 服务。

  2. 推送（unRaid 的 SSH 默认开启，root + webGUI 密码登录；连不上到 Settings → Management Access 确认）：

    rsync -avhHS --info=progress2 /mnt/<池名>/ root@<N355_IP>:/mnt/user/migration/ultra7/

    -H 保硬链接（否则拷成多份独立文件，容量膨胀且关系永久丢失）、-S 保稀疏（docker.img、vdisk 都是稀疏文件，不加它落到 XFS 会按标称大小实体化）；源路径末尾斜杠表示只拷内容、不带顶层目录；中断后重跑同一条命令即断点续传。

  3. 校验（-c 逐文件 checksum，相当于把数据再读一遍，耗时与复制同量级）：

    rsync -avhcHS --dry-run /mnt/<池名>/ root@<N355_IP>:/mnt/user/migration/ultra7/

    文件列表为空（只剩统计行）即一致。再辅以两端 du -sb 与 find <目录> -type f | wc -l 比对总字节数与文件数。

三、PC：数据推到 N355​

  1. 导出软件清单（管理员 PowerShell；winget 覆盖不到的商店应用、手装软件、Windows 可选功能——如 OpenSSH Server 及其 C:\ProgramData\ssh 配置——人工补清单）：

    winget export -o \\<N355_IP>\migration\pc\winget-packages.json --include-versions

  2. 逐项清点散落数据：

    • 浏览器：确认账号同步已开；否则手动导出书签和密码（密码 CSV 是明文，用完立刻删）

    • 密钥：%USERPROFILE%\.ssh 整目录、GPG 私钥

    • WSL 发行版：

      wsl --shutdown
      wsl --export <发行版名> \\<N355_IP>\migration\pc\<发行版名>.tar

    • 游戏存档常见位置：Documents\My Games、Saved Games、%APPDATA%、%LOCALAPPDATA%、Steam 的 userdata（确认 Steam 云存档已开）

  3. BitLocker 检查（管理员终端）：

    manage-bde -status

    任一卷 Protection On：先 manage-bde -protectors -get C: 抄下恢复密钥，或干脆 manage-bde -off C: 完全解密再动盘。密钥封在本机 TPM 里，盘一离机，没有恢复密钥就永远打不开。

  4. 清点 C 盘上用户目录之外的数据：Get-ChildItem C:\ -Directory -Force 列出顶层目录，自建文件夹、portable 工具、C:\ProgramData 下的本地数据，逐一决定纳入备份还是明确放弃——下面的命令只覆盖用户目录和数据盘。

  5. 用户数据备份（数据盘以 D: 为例；先关闭所有应用，尤其浏览器）：

    robocopy "C:\Users\<用户名>" "\\<N355_IP>\migration\pc\Users\<用户名>" /E /COPY:DAT /DCOPY:DAT /R:1 /W:1 /XJ /MT:16 /LOG:C:\robocopy-backup.log
    robocopy D:\ "\\<N355_IP>\migration\pc\D" /E /COPY:DAT /DCOPY:DAT /R:1 /W:1 /XJ /MT:16 /XD "System Volume Information" '$RECYCLE.BIN' /LOG:C:\robocopy-backup-d.log

    /XJ 必须加——AppData 里的 junction 会无限自循环撑爆目标；/R:1 /W:1 防止锁定文件卡死（默认重试一百万次、每次等 30 秒）；不要用 /COPYALL（NTFS ACL 写不进 Linux SMB，徒增报错）。结束后逐条核对日志中的 FAILED：NTUSER.DAT、UsrClass.dat 这类被系统独占的注册表文件必然失败、属预期（重装后系统会重建）；除这类已知项外必须为零，特别留意浏览器 profile 之类的业务数据有没有混在失败清单里。

  6. 检查激活状态：设置 → 系统 → 激活。数字许可证绑定主板硬件哈希，同一主板重装后联网即自动激活，不依赖账户；仍建议顺手关联微软账户，将来换硬件时能用激活疑难解答找回许可证。

  7. 制作 Win11 安装 U 盘：微软官网媒体创建工具，或 ISO + Rufus（可顺手勾选「禁用 BitLocker 自动设备加密」）。

四、换盘前的闸门​

全部满足才能关机拆盘：

  • /mnt/cache 已空，appdata 另有一份 tar 或插件备份
  • Ultra 7 的 rsync -c 校验通过，两端字节数/文件数一致
  • PC 的 robocopy 日志已逐条核对，FAILED 仅限已知被锁的系统文件；WSL tar、.ssh、BitLocker 恢复密钥已落到 migration share
  • 两台 unRaid 的 flash 备份已下载到第三处
  • Win11 安装 U 盘已制作并验证可引导

换盘​

  1. N355：Main → Stop 停阵列 → 缓存池两个槽位设为 no device → 关机。
  2. Ultra 7：Stop → ZFS 池所有槽位设为 no device → Start（让 unRaid 清掉池配置）→ Stop → 关机；也可在停阵列后直接点 Delete Pool 一步删池，同样不动盘上数据。
  3. PC 直接关机。
  4. 按硬盘流向表换盘，新购宏碁 512G 装入 N355。例外：PC 先只装 S690，S100Pro 留到系统装完再接——防止安装器把引导分区建到另一块盘上，也防 diskpart 时认错两块同为 1TB 的盘。
  5. N355 开机后先核对 6 块机械盘序列号与槽位无误再继续——阵列按序列号识别盘；万一配置异常，用 flash 备份恢复，不要凭记忆重新分配。

恢复步骤​

一、N355：重建缓存池并回迁​

  1. Main → 把 HP EX900 与宏碁 512G 分配到缓存池两个槽位（池已被删就 Add Pool，Slots=2）；File system 确认 btrfs。unRaid 对双盘 btrfs 池默认就是 raid1（data+metadata 均是），无需手动 balance。
  2. Start → 新盘显示 Unmountable 属预期 → 勾选 Yes, I want to do this → Format。可用容量约 465 GiB。
  3. Shares 页只把撤离时改动过的那批常驻缓存 share（appdata、system、domains 等）的 Mover action 反转为 Array → Cache → Main → Move。写缓冲类 share 不要碰——它们的主体数据本就常驻阵列，反转后 mover 会试图把整个 share 灌进 465 GiB 的新池，直接塞爆并连累其他 share 回迁失败。
  4. 跑完确认数据回到 /mnt/cache、阵列侧已空（如 ls /mnt/user0/appdata），恢复 Docker/VM 服务，逐个点验容器与虚拟机。
  5. share 设置改回日常：原 cache-only share 的 Secondary 改回 None。确认各 share 的 Mover action 都是日常方向后，到 Settings → Scheduler 恢复定时 mover。

二、Ultra 7：重建两个 ZFS 池并回迁​

  1. Add Pool：沿用旧池名（容器/VM 的 /mnt/<池名> 路径映射不用改；注意 7.3 起池名不得以 mirror/raidz/draid/spare 这些 ZFS 保留前缀开头），Slots=4，分配 4 块 NVME → 池设置 File system type: zfs、Allocation profile: raidz1、拓扑下拉选 1 vdev of 4 devices，建议开启 compression。

  2. 再 Add Pool：Slots=1，分配 860 EVO，File system: zfs。

  3. Start → Format。unRaid 新池启动时会自动擦除曾属其他池的盘；若仍报 Unmountable，停阵列后 wipefs -a /dev/sdX1 清掉残留签名再格。

  4. 先在 Shares 页重建各 share（unRaid 会在 ZFS 池上以 dataset 形式建顶层目录），再回迁；否则 rsync 直接建的顶层目录只是普通文件夹，失去按 share 做快照的能力：

    rsync -avhHS --info=progress2 root@<N355_IP>:/mnt/user/migration/ultra7/ /mnt/<池名>/
    rsync -avhcHS --dry-run root@<N355_IP>:/mnt/user/migration/ultra7/ /mnt/<池名>/

  5. 启用 Docker/VM；Docker 页 Add Container 下拉选 user templates 逐个一键重建容器（模板在 flash 上，不受删池影响）；虚拟机用之前导出的 XML virsh define 恢复（system share 整体搬回的话 libvirt.img 直接可用）。

三、PC：全新安装​

  1. 只接 S690 一块盘装系统（防止安装器把 EFI/恢复分区建到另一块盘上）。安装器分区界面删除 S690 上所有 ZFS 残留分区，选未分配空间继续；若报「无法创建新分区」：Shift+F10 → diskpart → list disk → 按容量核对后 select disk <N> → clean（清错盘不可逆，U 盘安装介质也在列表里）。

  2. 密钥页选「我没有产品密钥」，装好后登录微软账户，到 设置 → 系统 → 激活 确认数字许可证已激活。

  3. Win11 24H2 全新安装默认自动开启设备加密：设置 → 隐私和安全性 → 设备加密，决定保留或关闭；保留则到 https://aka.ms/myrecoverykey 确认新恢复密钥已上传账户。

  4. 接入 S100Pro：磁盘管理删除 ZFS 残留卷（或对它 diskpart clean）→ 初始化 GPT → NTFS 新建卷。

  5. 回迁与重装：

    robocopy "\\<N355_IP>\migration\pc\Users\<用户名>" "C:\Users\<用户名>" /E /COPY:DAT /DCOPY:DAT /R:1 /W:1 /MT:16 /LOG:C:\robocopy-restore.log
    robocopy "\\<N355_IP>\migration\pc\D" D:\ /E /COPY:DAT /DCOPY:DAT /R:1 /W:1 /MT:16 /LOG:C:\robocopy-restore-d.log
    winget import -i \\<N355_IP>\migration\pc\winget-packages.json --accept-package-agreements --accept-source-agreements
    wsl --install --no-distribution   # 全新系统没有 WSL，装好重启后再导入
    wsl --import <发行版名> D:\WSL\<发行版名> \\<N355_IP>\migration\pc\<发行版名>.tar --version 2

    导入的 WSL 默认以 root 登录：在发行版内 /etc/wsl.conf 写入 [user] 段 default=<用户名>，wsl --terminate 重启生效。

四、收尾​

  • 三台机器跑顺 1~2 周后再删 N355 上的 migration 中转数据，期间它是唯一的退路。删除前再核对一遍：PC 的 Users 与 D 盘均已回迁且日志无业务数据 FAILED，Ultra 7 回迁校验通过。
  • 池配置已变，重新做两台 unRaid 的 flash 备份。
  • 检查定时 mover 已恢复、Appdata.Backup 计划任务、Turbo write 设置是否改回日常值。

边界与坑​

  • 860 EVO 单盘 ZFS 池能发现数据损坏但无法自修复，只放可再生数据。
  • 4×1TB RAIDZ1 标称 3 TB，zfs list 实际约 2.6 TiB；池用到 80% 以上性能明显下降。
  • 新缓存池 465 GiB 不到原来的一半，回迁前先算账。
  • rsync 不带走 ZFS 快照，池销毁后历史版本全部消失；个别需要保留的快照可在销毁前 zfs send 单独导出成文件（单个快照流的脆性风险可接受，与下条不矛盾）。
  • 本文按 unRaid 7.3.1 的口径撰写（两台机器均为此版本）；Primary/Secondary/Mover action 语义自 6.12 引入，6.11 及更早的 Use cache 四值语义不适用。
  • 两个没用上的官方能力：7.1+ 可直接导入整体平移的 ZFS 池（本文的池要拆散重组，不适用）；7.2+ 单盘池支持 NTFS/exFAT，若千兆网络成瓶颈，PC 的盘理论上可拆下直插 unRaid 本地拷贝，但要自行权衡移动备份源盘的风险。

附：格式化引导盘与缓存池重装系统，阵列数据无损​

问题：N355 能不能把引导 U 盘和缓存池全部格式化、重装 unRaid，XFS 阵列数据都在且不触发重新校验？

可以。 阵列数据就在 6 块 XFS 盘自身上，系统在 U 盘、盘位配置在 U 盘的 config/super.dat，缓存池数据先按前文撤到阵列即可。奇偶校验只在两种情况被触发：不洁关机（自动发起校验）和 New Config 后的重建——避开这两条就免校验。

路径 A，有引导盘备份（推荐）：

  1. 缓存池数据按前文「备份步骤·一」撤到阵列。
  2. 先 Stop array，再做 Boot Device Backup——阵列运行状态写在 U 盘上，运行中做的备份恢复后首次启动可能被判为不洁关机、触发一次校验。
  3. 正常 Shutdown。
  4. 重写 U 盘：官方 USB Flash Creator 的 Operating System 下拉选 Use custom，直接把备份 zip 当镜像写入；或先写干净系统、再把 zip 里的 config/ 覆盖回去。只想要盘位和授权的话，最少恢复 config/super.dat、.key 文件和 config/pools/（要一键重建容器再加 config/plugins/dockerMan/templates-user/）。
  5. 开机后盘位原样恢复，Start array，不触发校验。缓存池重建与回迁按前文「恢复步骤·一」。

许可证绑定 U 盘控制器里的硬件 GUID，同一根 U 盘格式化重写后 GUID 不变，原 .key 继续有效（可随时从 account.unraid.net 重新下载）；换新 U 盘用 Tools → Registration → Replace Key 自助转移，首次随时可做、之后每 12 个月一次，旧 GUID 转移后永久作废。

路径 B，没有任何备份：

  1. 全新安装启动后，把 6 块盘全部分配为数据盘、奇偶槽留空，启动阵列：能挂载的 5 块是数据盘，显示 unmountable 的那块就是原奇偶校验盘（本文已留档：ZRS0JTR1）。这一步千万不要点 Format。
  2. Stop → Tools → New Config → 按序列号重新分配：ZRS0JTR1 进奇偶槽，其余 5 块进数据槽。单奇偶校验下数据盘放哪个槽位都不影响校验有效性；双奇偶（parity2）对盘序敏感，不适用此法。
  3. Start 前勾选紧邻 Start 按钮的 Parity is already valid，启动后不重建。
  4. 之后跑一次校验做最终确认。

致命风险：把还有数据的盘分配进奇偶槽并启动，阵列会立即开始 Parity-Sync 把整盘覆写为奇偶数据，不可逆。unRaid 不检测奇偶槽里的盘上是否有文件系统，没有硬性拦截——盘位只能靠序列号逐一核对，这正是本文反复留档序列号截图的原因。

  • 没走 zfs send/receive：N355 是 XFS 阵列收不了流，落成文件又太脆（单 bit 损坏整条流报废），此场景文件级 rsync 是正解。

评论

欢迎补充上下文、指出问题，或者留下进一步讨论的线索。

正在加载留言板…