Veeam Backup & Replication 13 实战 01：从 FC SAN 或 iSCSI LUN 到备份存储库

一、这次实验做了什么

这次我在飞牛 NAS 上创建了两块 500 GB Thin iSCSI LUN，分别交给一台 Windows Server 2022 和一台 Rocky Linux 9 虚拟机使用。Windows 分支采用 ReFS 64 KB，Rocky 分支采用支持 reflink 的 XFS；最后我在 Veeam Backup & Replication 13 中分别创建普通 Windows Repository 和 Hardened Repository。

本篇实际操作使用的是 iSCSI。标题中保留 FC SAN，是因为 FC LUN 进入 Veeam 存储库服务器后的文件系统与存储库创建逻辑相同；FC zoning、WWPN、LUN masking 和 FC 多路径没有在这次实验中执行，相关内容只用于说明架构边界，不作为实测结论。

整条实验链路包括下面七个阶段。本篇已经完成到第 5 步，第 6、7 步留到下一阶段继续验证：

1. 在存储阵列上创建存储池、LUN 和主机映射关系。
2. 通过 FC zoning/masking 或 iSCSI 网络把 LUN 提供给存储库服务器。
3. 在 Windows 或 Linux 上识别设备、确认多路径并创建文件系统。
4. 把文件系统挂载为 Veeam 备份目录。
5. 将存储库服务器加入 Veeam，并创建 Backup Repository。
6. 通过真实备份、容量检查和文件级还原验证整条链路。
7. 对 Hardened Repository 继续验证 XFS Fast Clone 和不可变保留边界。

我不会把“界面显示 Online”当成整个实验已经完成。完整验收还包括：

• 操作系统能稳定识别正确的 LUN。
• 多路径状态符合设计，没有重复磁盘或单路径误判。
• 文件系统、挂载点、容量和权限均经过检查。
• Veeam 存储库创建成功并完成重新扫描。
• 实际备份写入成功。
• 至少完成一次可验证的还原。

二、我的实验环境与验证边界

我在本次实验中使用并确认了以下环境：

为了避免公开实验环境的身份信息，我隐去了真实主机名、IP、IQN、WWPN、存储序列号和登录用户名；产品版本、命令、错误信息、容量测量与验证结论均按实验结果保留。

三、先理解数据链路

FC 和 iSCSI 提供的是块设备。Veeam 不能把一个未经操作系统接管的裸 LUN 直接作为备份存储库使用。

正确的数据链路是：

flowchart LR
    V["VBR 13 Backup Server<br/>负责配置与调度"]
    P["Backup Proxy / Data Mover<br/>读取备份源数据"]
    R["Windows 或 Linux Repository<br/>文件系统与 Veeam 组件"]
    L["FC 或 iSCSI LUN<br/>块设备"]
    S["SAN 存储阵列"]

    V -->|"下发任务"| P
    P -->|"传输备份数据"| R
    R -->|"文件系统 I/O"| L
    L --> S

存储阵列只负责提供块设备。真正承载 Veeam Backup Repository 的是 Windows 或 Linux 存储库服务器：它负责识别 LUN、创建文件系统、提供目录，并运行 Veeam Transport/Data Mover 等组件。

正常情况下，这些 Veeam 组件由 VBR 在添加托管服务器或创建存储库时自动部署。只有证书身份验证、隔离环境或禁止远程推送组件等场景，才需要提前使用 Veeam Deployment Kit。

四、实验开始前先做选型

1. FC 还是 iSCSI

如果后续再补做 FC 或多路径实验，我会继续核对：

• 阵列侧目标端口及链路状态。
• 主机侧发起端标识。
• LUN 与主机或主机组的映射关系。
• 路径数量及多路径策略。
• 故障切换前后的路径状态。

2. Windows、Linux 还是 Hardened Linux

我在同一次实验中创建了 Windows Server 与 Rocky Linux 9 两套存储库，用相同容量的 iSCSI LUN 对比 ReFS 和 XFS。Windows 分支使用普通 Microsoft Windows Repository；Rocky Linux 分支直接创建 Hardened Repository，用来验证 XFS Fast Clone、单次部署凭据和不可变备份。

五、阶段一：在存储阵列上创建 LUN

状态：已完成两块 LUN 的创建和 Target 映射；Rocky 与 Windows 均已通过各自的 iSCSI Target 识别并初始化对应 LUN。

1. 我的存储环境

2. 已执行的操作

• 选择飞牛 NAS 的 存储空间 2。
• 创建 LUN-1，容量 500 GB，Thin Provisioning，用于 Rocky Linux/Veeam 存储库。
• 创建 LUN-2，容量 500 GB，Thin Provisioning，用于 Windows/Veeam 存储库。
• 将 LUN-1 映射到 Target-1。
• 将 LUN-2 映射到 Target-2。
• 确认两块 LUN 状态正常，两个 Target 均显示已启用。

创建 Linux 存储库 LUN：

创建 Windows 存储库 LUN：

创建完成后，两块 LUN 分别映射到独立 Target：

“Target 已启用”当时只能证明 NAS 侧目标已经开放。我随后分别在 Windows 和 Rocky 中确认了 iSCSI 会话、对应的 500 GB 块设备以及文件系统，才继续执行格式化和存储库创建。

3. 我用来确认映射关系的证据

除了 NAS 管理界面，我还交叉核对了 iSCSI Portal、Windows/Rocky Initiator IQN、Target IQN、登录会话、设备容量和稳定设备标识。这些证据共同确认了“两台主机分别登录专用 Target，并且各自只接管一块 500 GB LUN”的映射关系。

六、阶段二：让存储库服务器发现 LUN

状态：Linux 与 Windows 分支均已完成 iSCSI 登录和 LUN 识别；本次实验均为单路径，不代表生产环境多路径设计。

我让两台虚拟机直接在客户机操作系统内部连接飞牛 NAS 的 iSCSI Target：

Windows Server VM → Windows iSCSI Initiator → Target-2 → LUN-2
Rocky Linux 9 VM → open-iscsi → Target-1 → LUN-1

我没有先把这两个 LUN 添加到 ESXi 并格式化成 VMFS，因为那样虚拟机最终看到的是 VMDK，而不是我这次要验证的客户机内 iSCSI LUN 链路。

Windows 实测：只连接 Windows 专用 Target

Windows Server 使用系统自带的“iSCSI 发起程序”连接 NAS Portal。快速连接发现了两个 Target，但只选择并连接映射 Windows LUN 的专用 Target，Linux Target 保持未连接。

这一步的关键不是“发现了几个 Target”，而是确认下面四层关系保持一一对应：

Windows Initiator IQN
  → Windows 专用 Target
  → Windows 专用 LUN
  → Windows 磁盘管理中的 500 GB 新磁盘

在生产环境中，还应结合 Target ACL 或 CHAP，避免仅依赖操作者在客户端手工选择。我已经从截图中隐去了真实 IP、IQN 和 Target 标识。

本次没有配置 Windows MPIO，因此不能把当前单路径结果当成冗余链路验证。需要多路径时，应先安装 MPIO、让多个 Portal/连接归并为同一个磁盘，再执行初始化和格式化。

Linux 分支

本次 Rocky Linux 虚拟机通过客户机操作系统内的 open-iscsi 直接连接 NAS，不经过 ESXi VMFS，也没有把 LUN 封装成 VMDK。

为了不公开我的真实 Portal 和 IQN，下面的 NAS_IP、TARGET_IQN、<INITIATOR_IQN> 和序列号均使用示例值。照着操作时要替换成自己的环境值，也不要在 Shell 参数中直接写未加引号的 <NAS_IP>，因为尖括号会被 Bash 解析为输入重定向。

1. 安装并启动 iSCSI Initiator

风险等级：CAUTION（安装软件并启用开机服务）

作用： 在 Rocky Linux 存储库服务器上安装 iscsi-initiator-utils，立即启动 iscsid.service，并设置为开机自动启动。 执行条件： 使用具备 sudo 权限的账户；先确认当前系统使用 DNF/RPM 包管理，并且没有由其他方式维护 iSCSI Initiator。 影响与回退： 该操作会安装软件包并持久化服务配置。若不再使用 iSCSI，可先执行 systemctl disable --now iscsid.service；卸载软件包前还要确认没有其他存储依赖它。 完成验证： systemctl is-active iscsid.service 应返回 active，systemctl is-enabled iscsid.service 应返回 enabled。

sudo dnf install -y iscsi-initiator-utils
sudo systemctl enable --now iscsid.service

风险等级：INFO（只读）

作用： 读取 Rocky Linux 当前的 iSCSI Initiator IQN，用于在 NAS Target 侧配置访问控制。 注意事项： IQN 属于环境身份信息，公开日志或截图前应脱敏；该命令不会修改配置。

sudo cat /etc/iscsi/initiatorname.iscsi

记录 Rocky 的 InitiatorName=<INITIATOR_IQN> 后，将它加入 NAS Target 的访问控制范围；如果启用了 CHAP，还要按实际安全设计配置认证，不能把实验环境的认证方式直接套到生产环境。

2. 发现 Target，但只登录 Linux 专用 Target

风险等级：INFO（发现操作，只读查询 Target）

作用： 在 Rocky Linux 上查询指定 NAS Portal 发布的 iSCSI Target。 需要替换： NAS_IP 必须替换为 NAS 的 iSCSI Portal 地址；192.0.2.10 是文档示例地址，不是我的现场地址。 预期结果： 输出中应出现 Linux 专用 Target IQN；发现到 Target 不代表已经登录，也不会自动挂载 LUN。

NAS_IP='192.0.2.10'  # 文档示例地址，替换为 NAS 的 iSCSI Portal 地址
sudo iscsiadm -m discovery -t sendtargets -p "${NAS_IP}:3260"

风险等级：CAUTION（建立 iSCSI 会话并让主机发现块设备）

作用： 只登录分配给 Rocky Linux 的专用 Target。 需要替换： NAS_IP 和 TARGET_IQN 都必须换成已经通过 NAS 映射关系核对过的值。 影响： 登录后系统会发现新的块设备。登录错误 Target 可能让主机看到不属于自己的 LUN，因此不能把发现结果中的所有 Target 全部登录。 回退： 如果登录错误，使用相同 Portal 和 IQN 执行 iscsiadm -m node -T "$TARGET_IQN" -p "${NAS_IP}:3260" --logout，然后重新核对 Target 映射。 完成验证： iscsiadm -m session 只应显示 Linux 专用 Target，随后再通过容量、WWN/序列号和路径确认新设备。

NAS_IP='192.0.2.10'  # 替换为 NAS 的 iSCSI Portal 地址
TARGET_IQN='iqn.2000-01.example:veeam-linux'  # 替换为 Linux 专用 Target IQN

sudo iscsiadm -m node \
  -T "$TARGET_IQN" \
  -p "${NAS_IP}:3260" \
  --login

本次发现阶段能看到两个 Target，但 Rocky 只登录映射 LUN-1 的 Linux 专用 Target。另一个 Target 留给 Windows，不能因为“发现到了”就全部登录，否则可能让两台主机看到或误操作不属于自己的 LUN。

登录成功后，继续在同一个 Shell 会话中使用前面确认过的变量，把该节点设置为自动登录：

风险等级：CAUTION（修改持久化自动登录配置）

作用： 把当前 Linux 专用 iSCSI 节点设置为开机自动登录，为后续 XFS 自动挂载提供前提。 执行条件： 当前会话已经确认只连接 Linux 专用 Target，并且 NAS、网络和 Target ACL 能在主机启动时使用。 影响与回退： 配置会持久化到 open-iscsi 节点数据库。需要取消时，将 node.startup 改回 manual，或删除确认无用的节点记录。 完成验证： 查询结果应显示 node.startup = automatic。

NAS_IP='192.0.2.10'  # 替换为 NAS 的 iSCSI Portal 地址
TARGET_IQN='iqn.2000-01.example:veeam-linux'  # 替换为 Linux 专用 Target IQN

sudo iscsiadm -m node \
  -T "$TARGET_IQN" \
  -p "${NAS_IP}:3260" \
  --op update \
  -n node.startup \
  -v automatic

风险等级：INFO（只读验证）

作用： 检查当前 iSCSI 会话以及节点的自动登录值，不修改节点配置。 预期结果： 会话指向 Linux 专用 Target，节点配置包含 node.startup = automatic。

NAS_IP='192.0.2.10'  # 与前面使用同一个 Portal
TARGET_IQN='iqn.2000-01.example:veeam-linux'  # 与前面使用同一个 Target IQN

sudo iscsiadm -m session

sudo iscsiadm -m node \
  -T "$TARGET_IQN" \
  -p "${NAS_IP}:3260" \
  -o show | grep 'node.startup'

现场确认结果为：会话登录成功，且 node.startup = automatic。

3. 交叉确认新发现的 LUN

刚发现设备时，绝对不能看到 /dev/sdb 就直接格式化。本次先检查磁盘拓扑：

风险等级：INFO（只读）

作用： 查看 Rocky Linux 的系统盘、iSCSI LUN、文件系统和挂载点，初步区分系统盘与新发现的存储 LUN。 注意事项： 容量和 /dev/sdX 名称只能作为线索，不能单独作为后续分区或格式化依据。

lsblk -o NAME,HCTL,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL

现场结果显示：

• /dev/sda 是 60 GiB 系统盘，包含 /、/boot、/home 和 swap，绝对不能操作。
• /dev/sdb 是新出现的 500 GiB iSCSI LUN。
• 当前只有一个 HCTL 路径，因此本次是单路径实验，不涉及 /dev/mapper/mpath*。

继续通过设备模型、序列号、iSCSI Portal、Target IQN 和容量交叉确认：

风险等级：INFO（只读设备预检）

作用： 读取候选设备的型号、序列号、WWN、iSCSI 路径、文件系统签名和分区表。 执行对象： /dev/sdb 是我当时实验环境中识别到的临时设备名；其他环境必须替换为刚刚通过 lsblk 找到的候选设备，并继续核对持久化 /dev/disk/by-id/ 路径。 注意事项： wipefs -n 中的 -n 表示只读检查，不会擦除签名；不要去掉该选项。 预期结果： 容量、稳定标识和 iSCSI 路径与 Linux 专用 LUN 一致，且没有未知文件系统、LVM、RAID 或分区签名。

sudo udevadm info --query=property --name=/dev/sdb | \
  grep -E '^(DEVNAME|ID_MODEL|ID_SERIAL|ID_SERIAL_SHORT|ID_WWN|ID_PATH)='

sudo wipefs -n /dev/sdb
sudo fdisk -l /dev/sdb

其中 wipefs -n 只读取签名，不会擦除数据。本次结果满足以下条件：

确认这组证据后，我才把 /dev/sdb 作为初始化目标。若其他环境配置了多路径，应先完成 device-mapper-multipath 聚合并使用确认后的 /dev/mapper/<multipath-device>，不能照搬我这次单路径环境中的 /dev/sdb。

七、阶段三：初始化文件系统并挂载

状态：我已在 Linux 上完成 GPT、XFS、临时挂载、永久挂载、systemd 依赖和读写验证；Windows 已完成 GPT、ReFS 64 KB 格式化，并在一次重启后保持 iSCSI 会话与卷正常。Linux 的重启恢复还没有验证。

这一阶段包含不可逆操作。我在格式化前通过容量、WWN/序列号和路径信息交叉确认目标设备，没有只凭 /dev/sdX 或 Windows 磁盘编号判断。

飞牛页面显示的 存储空间 2 ext4 是 NAS 自身用于承载 LUN 文件或块对象的底层文件系统。通过 iSCSI 提供给客户端后，Windows 和 Rocky 看到的是新的裸块设备，可以分别创建 ReFS 和 XFS，不需要跟随 NAS 底层的 ext4。

Windows 实测：初始化 GPT 并格式化为 ReFS 64 KB

我在 Windows 上实际执行的流程是：

确认唯一磁盘
  → 初始化 GPT
  → 创建分区
  → 格式化 ReFS 3.1 或更高版本
  → 使用盘符或卷挂载点
  → 创建 `D:\Backups`

Veeam Fast Clone 在 Windows 存储库上依赖 ReFS Block Cloning。Veeam 13 要求 ReFS 3.1 或更高版本，并建议使用 64 KB cluster size。

风险等级：INFO（只读）

作用： 在 Windows Server 的管理员 PowerShell 或命令提示符中读取 D: 卷的 ReFS 版本、扇区大小和分配单元大小。 需要替换： 如果实际存储库不是 D:，应替换为已经确认的卷盘符；不要对不确定的卷继续执行后面的格式化操作。 预期结果： 本次实测显示 ReFS 版本为 3.7，每簇 65536 字节。

fsutil fsinfo refsinfo D:

NTFS 可以作为普通 Windows Repository 使用，但不具备 ReFS Fast Clone。本实验为了对比 ReFS 与 XFS，Windows LUN 实际采用：

GPT + ReFS 3.1 或更高版本 + 64 KB 分配单元

风险等级：DANGER（初始化和格式化会破坏目标磁盘上的原有数据）

作用： 在 Windows“磁盘管理”中把已经确认的专用 500 GB iSCSI LUN 初始化为 GPT，创建覆盖全盘的简单卷，并格式化为 ReFS 64 KB。 执行对象： 必须是通过 iSCSI Session、Target 映射、容量、磁盘唯一标识共同确认的 Windows 专用空白 LUN，不能只凭“磁盘 1”之类的临时编号判断。 执行前检查： 确认目标磁盘不包含现有分区、文件系统或业务数据，并再次排除系统盘、其他数据盘和 Linux 专用 LUN。 不可恢复点： 初始化、创建分区和格式化都会改变磁盘元数据；选错磁盘可能造成数据丢失。没有备份时无法通过简单撤销恢复，只能从备份恢复数据或重新创建本来就是空白的实验 LUN。 完成验证： 格式化后检查卷状态为正常，再执行上面的 fsutil fsinfo refsinfo D:，确认 ReFS 版本和 64 KB 分配单元，并确认 D:\Backups 可以创建和访问。

磁盘管理中确认新磁盘容量约 500 GB 后，我将其初始化为 GPT，创建一个覆盖全盘的简单卷，并使用下面的格式化参数：

• 文件系统：ReFS。
• 分配单元大小：64 KB。
• 快速格式化：启用。
• 文件和文件夹压缩：不启用。
• 盘符：D:。
• 备份目录：D:\Backups。

Windows 后续发生过一次重启。我重新连接后确认 iSCSI Session 仍为 Connected，D: 仍是 ReFS 3.7/64 KB，卷状态正常，D:\Backups 目录仍然存在；因此 Windows 分支的开机恢复已经完成一次实测。

这里没有给出按磁盘编号直接执行的 Initialize-Disk 或 Format-Volume 命令，因为磁盘编号属于现场变量。无论使用 GUI 还是 PowerShell，都必须先通过容量、唯一标识和 iSCSI 会话确认目标磁盘，不能把实验中的磁盘编号复制到其他环境。

Linux 实测：创建支持 Fast Clone 的 XFS 存储卷

我在 Rocky Linux 上实际执行的流程是：

确认单路径 iSCSI LUN 的唯一身份
  → 创建 GPT 和 8 MiB 对齐分区
  → 创建 XFS
  → 创建挂载点
  → 按 UUID 写入 /etc/fstab
  → 验证 systemd/iSCSI 依赖
  → 完成实际读写测试

我当时确认的临时设备名是 /dev/sdb，但 /dev/sdX 可能在重启或设备发现顺序变化后漂移。下面把实测过程整理为可复用命令时，改用 /dev/disk/by-id/<TARGET_LUN_ID> 表示经过 WWN、序列号和 iSCSI 路径共同确认的持久化设备路径。<TARGET_LUN_ID> 必须替换，尤其不能指向系统盘或其他已有数据的磁盘。

1. 创建 GPT 分区并检查对齐

设备报告的最佳 I/O 大小为 8 MiB，因此分区从 8MiB 开始：

风险等级：CAUTION（安装普通软件包）

作用： 在 Rocky Linux 上安装 GNU Parted，为后续创建 GPT 分区表提供工具。 影响与回退： 安装操作会写入系统软件包数据库，但不会修改目标 LUN。确认没有其他软件依赖后，可通过 DNF 删除该软件包。 完成验证： rpm -q parted 应返回已安装版本。

sudo dnf install -y parted
rpm -q parted

风险等级：INFO（只读的最终设备预检）

作用： 在任何分区操作前，再次解析持久化设备路径，并核对容量、型号、序列号、WWN、现有签名和挂载状态。 需要替换： <TARGET_LUN_ID> 必须替换为 /dev/disk/by-id/ 下已经与 Linux 专用 iSCSI LUN 对应的名称。 通过条件： readlink 最终指向本次 500 GiB LUN；wipefs -n 不显示未知签名；findmnt 不应显示该设备或其分区已被挂载。任何一项不一致都应停止。

LUN_DISK='/dev/disk/by-id/<TARGET_LUN_ID>'

readlink -f "$LUN_DISK"
lsblk -o NAME,HCTL,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL,WWN "$LUN_DISK"
sudo wipefs -n "$LUN_DISK"
findmnt -S "$LUN_DISK"

风险等级：DANGER（会重写目标设备的分区表）

作用： 在已确认的空白专用 LUN 上创建 GPT 分区表，并创建从 8 MiB 起始、占用剩余空间的 XFS 分区。 执行对象： 仅限 LUN_DISK 指向的 Linux 专用实验 LUN。执行前必须完成上面的只读预检，并在命令执行前再次检查变量内容。 不可恢复点： mklabel gpt 会重写分区表，选错设备会破坏原有分区和数据。没有有效备份时不能靠撤销命令恢复；本次实验 LUN 为空，因此恢复路径是删除并重新创建该实验 LUN。 完成验证： 命令结束后使用后面的只读检查确认分区起点为 8 MiB、分区大小正确且对齐检查通过。

LUN_DISK='/dev/disk/by-id/<TARGET_LUN_ID>'

sudo parted -s -a optimal "$LUN_DISK" \
  mklabel gpt \
  mkpart primary xfs 8MiB 100%

sudo partprobe "$LUN_DISK"
sudo udevadm settle

风险等级：INFO（只读验证）

作用： 读取刚创建的分区表和对齐状态，并确认系统只识别出预期的一块新分区。 预期结果： 第 1 分区起点为 8.00MiB，align-check 返回已对齐，容量约为 500 GiB。

LUN_DISK='/dev/disk/by-id/<TARGET_LUN_ID>'

sudo parted "$LUN_DISK" unit MiB print
sudo parted "$LUN_DISK" align-check optimal 1
lsblk -o NAME,HCTL,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL

现场得到约 500 GiB 的 /dev/sdb1，分区起点为 8.00MiB，align-check 返回“1 已对齐”。这行是命令输出，不需要再把 1 aligned 当成 shell 命令执行。

2. 创建 XFS

Veeam Fast Clone 在 Linux 存储库上依赖 XFS reflink。Veeam 13 官方给出的格式要求是：

风险等级：DANGER（会在目标分区上创建新文件系统）

作用： 在 Linux 专用 LUN 的第 1 分区上创建 4 KB block、启用 CRC 与 reflink 的 XFS 文件系统。 执行对象： <TARGET_LUN_ID>-part1 必须是上一步刚创建并验证的空白分区；执行前用 lsblk -f、blkid 和 findmnt 再次确认它没有已有文件系统、没有挂载，也不是系统分区。 不可恢复点： mkfs.xfs 会覆盖目标分区上的文件系统元数据。选错分区会导致数据丢失；没有备份时无法撤销。本次空白实验 LUN 的恢复方式是重新分区并重新创建文件系统。 重要参数： -b size=4096 指定 4 KB block；reflink=1 启用 Fast Clone 所需能力；crc=1 启用元数据校验；-L VEEAM_REPO 设置卷标。 完成验证： 执行后用 lsblk -f 和 xfs_info 确认 XFS、bsize=4096、crc=1、reflink=1、ftype=1。

LUN_PART='/dev/disk/by-id/<TARGET_LUN_ID>-part1'

lsblk -f "$LUN_PART"
sudo blkid "$LUN_PART" || true
findmnt -S "$LUN_PART"

sudo mkfs.xfs \
  -b size=4096 \
  -m reflink=1,crc=1 \
  -L VEEAM_REPO \
  "$LUN_PART"

其中：

• size=4096：设置 4 KB 文件系统块大小。
• reflink=1：启用 XFS reflink，为 Fast Clone 提供基础能力。
• crc=1：启用 XFS 元数据校验，也是 reflink 所需条件。

Rocky Linux 9 可以作为 Veeam 13 Linux Backup Repository。ext4 也能承载普通 Linux 文件存储，但不能提供 XFS Fast Clone 集成，因此我为这块 Rocky LUN 选择了 XFS，并显式启用 reflink 和 CRC。

格式化完成后，我读取到以下关键值。下面是结果摘录，不是需要执行的命令：

bsize=4096
crc=1
reflink=1
ftype=1

这四项均满足本次 XFS/Fast Clone 文件系统目标。输出中的 sunit=0、swidth=0 表示没有为文件系统显式声明阵列条带参数；本次是 NAS 提供的单个 iSCSI LUN，已在分区层按设备报告的 8 MiB 最佳 I/O 大小完成起始对齐。

3. 临时挂载并验证文件系统

风险等级：CAUTION（创建目录并挂载文件系统）

作用： 在 Rocky Linux 上创建 /backup/veeam，并把刚格式化的 XFS 分区临时挂载到该目录。 执行条件： <TARGET_LUN_ID>-part1 必须是前面已经完成 XFS 格式化的 Linux 专用分区；挂载点中不能有需要保留的现有文件，否则挂载后这些文件会暂时被遮蔽。 影响与回退： 挂载会改变当前文件系统视图。需要回退时先离开该目录、确认没有进程占用，再执行 umount /backup/veeam；确认目录为空后才可删除挂载点。 完成验证： findmnt 应显示持久化设备对应的分区以 XFS 挂载到 /backup/veeam。

LUN_PART='/dev/disk/by-id/<TARGET_LUN_ID>-part1'

sudo mkdir -p /backup/veeam
sudo mount "$LUN_PART" /backup/veeam

风险等级：INFO（只读验证）

作用： 检查实际设备、挂载点、容量、XFS 特性和文件系统 UUID。 预期结果： 挂载点为 /backup/veeam，文件系统为 XFS，容量约 500 GiB，并显示 bsize=4096、crc=1、reflink=1、ftype=1。

LUN_PART='/dev/disk/by-id/<TARGET_LUN_ID>-part1'

findmnt /backup/veeam
df -hT /backup/veeam
sudo xfs_info /backup/veeam
sudo blkid "$LUN_PART"

现场结果为：

• /dev/sdb1 以 XFS 挂载到 /backup/veeam。
• 文件系统总容量约 500 GiB，可用约 497 GiB。
• 初始显示约 3.6 GiB 已用空间，主要来自 XFS 初始化后的元数据和内部日志，并非已有备份数据。
• xfs_info 再次确认 bsize=4096、crc=1、reflink=1、ftype=1。

4. 使用 UUID 配置永久挂载

长期挂载不能依赖可能变化的 /dev/sdX。先读取实际 UUID 和现有配置，不能直接覆盖 /etc/fstab：

风险等级：INFO（只读）

作用： 读取目标 XFS 分区的 UUID 和当前 /etc/fstab，用于确认即将追加的配置不会与现有条目冲突。 注意事项： /etc/fstab 可能包含其他存储和系统挂载信息，公开输出前应脱敏；此处只读取，不覆盖文件。

LUN_PART='/dev/disk/by-id/<TARGET_LUN_ID>-part1'

sudo blkid "$LUN_PART"
sudo cat /etc/fstab

下面是根据本次实测整理的可复用配置脚本。它先备份现有文件，再读取目标分区 UUID，并且仅在没有相同条目时追加配置：

风险等级：CAUTION（修改系统永久挂载配置）

作用： 把 XFS 分区按 UUID 写入 /etc/fstab，设置 _netdev 和 iSCSI systemd 依赖，使系统在网络与 iSCSI 服务就绪后挂载存储库。 执行前检查： 确认 LUN_PART、UUID、挂载点和现有 fstab 条目；确认 /backup/veeam 当前确实挂载在目标 XFS 分区上。 影响： 错误的 UUID、挂载点或依赖关系可能导致重启时长时间等待或进入故障处理流程。本次故意没有使用 nofail，避免 LUN 缺失时 Veeam 误写根文件系统。 回退： 记录脚本输出的 FSTAB_BACKUP 路径。若验证失败，用该备份恢复 /etc/fstab，执行 systemctl daemon-reload，再重新运行只读验证。 完成验证： findmnt --verify --verbose 必须返回成功且无错误或警告，文件末尾应只出现一条目标挂载配置。

LUN_PART='/dev/disk/by-id/<TARGET_LUN_ID>-part1'
FSTAB_BACKUP="/etc/fstab.bak.$(date +%Y%m%d-%H%M%S)"

sudo cp -a /etc/fstab "$FSTAB_BACKUP"
printf 'FSTAB_BACKUP=%s\n' "$FSTAB_BACKUP"

XFS_UUID="$(sudo blkid -s UUID -o value "$LUN_PART")"
printf 'XFS_UUID=%s\n' "$XFS_UUID"

if [ -n "$XFS_UUID" ]; then
  FSTAB_ENTRY="UUID=${XFS_UUID} /backup/veeam xfs defaults,_netdev,x-systemd.requires=iscsi.service,x-systemd.after=iscsi.service 0 0"
  grep -Fqx "$FSTAB_ENTRY" /etc/fstab || \
    printf '%s\n' "$FSTAB_ENTRY" | sudo tee -a /etc/fstab
else
  echo "未读取到目标 LUN 分区的 UUID，未修改 /etc/fstab"
fi

sudo systemctl daemon-reload
sudo findmnt --verify --verbose
sudo tail -n 3 /etc/fstab

本次 findmnt --verify --verbose 返回“成功，未检测到错误或警告”，UUID 能正确解析到 /dev/sdb1。

挂载选项的作用如下：

• _netdev：声明该 XFS 虽然是块文件系统，但底层依赖网络存储。
• x-systemd.requires=iscsi.service：挂载单元显式依赖 iSCSI 自动登录服务。
• x-systemd.after=iscsi.service：要求挂载操作排在 iSCSI 服务之后。
• 本次没有使用 nofail，目的是在 LUN 缺失时阻止系统把 /backup/veeam 当作根文件系统中的普通目录继续使用，避免 Veeam 误写满系统盘。代价是 NAS 或网络长期不可用时，系统启动可能等待或进入故障处理流程，生产环境应结合可用性要求评估。

5. 验证 systemd 挂载依赖

先停止当前挂载单元，再让 systemd 根据 /etc/fstab 重新挂载：

风险等级：CAUTION（会短暂卸载存储库文件系统）

作用： 验证 systemd 能否根据 /etc/fstab 和 iSCSI 依赖重新挂载 /backup/veeam。 执行前检查： 仅在实验环境或维护窗口执行；先在 Veeam 中确认没有备份、还原、Rescan 或健康检查作业，再确认没有进程打开挂载点中的文件。当前 Shell 必须先离开 /backup/veeam。 影响： stop backup-veeam.mount 会短暂中断对存储库的访问。如果重新挂载失败，Veeam 存储库会离线。 回退： 修正 /etc/fstab 或恢复前面的备份文件后，执行 systemctl daemon-reload 和 systemctl start backup-veeam.mount；不要在未挂载状态下让 Veeam 写入同名空目录。 完成验证： 挂载单元应为 active (mounted)，findmnt 和 df 应指向目标 XFS 分区，Requires/After 应包含预期的 iSCSI 与网络依赖。

cd /

sudo fuser -vm /backup/veeam || true
sudo systemctl stop backup-veeam.mount
findmnt /backup/veeam || echo "已成功卸载"

sudo systemctl start backup-veeam.mount

systemctl --no-pager --full status backup-veeam.mount
findmnt /backup/veeam
df -hT /backup/veeam

systemctl is-active iscsid.service iscsi.service
systemctl show --no-pager backup-veeam.mount -p Requires -p After

现场验证结果：

6. 实际写入、读取和删除测试

风险等级：CAUTION（会在存储库文件系统中写入并删除测试文件）

作用： 使用唯一临时文件验证 /backup/veeam 的实际写入、同步、读取、元数据查询和删除能力。 执行前检查： 确认 /backup/veeam 是目标 XFS 挂载点，而不是根文件系统中的普通目录；确认当前没有把该目录交给生产备份作业使用。 影响与回退： 测试只操作 mktemp 创建的唯一文件，不覆盖固定文件名。脚本通过 trap 在退出时清理测试文件；如果异常中断，可根据输出的 TEST_FILE 路径手工核对并删除。 完成验证： cat 应返回写入内容，stat 应显示目标文件，最后 mountpoint 应确认挂载点有效，且临时文件不再存在。

TEST_FILE="$(sudo mktemp /backup/veeam/.write-test.XXXXXX)"
printf 'TEST_FILE=%s\n' "$TEST_FILE"

cleanup_test_file() {
  sudo rm -f -- "$TEST_FILE"
}
trap cleanup_test_file EXIT

printf 'Veeam repository write test\n' | sudo tee "$TEST_FILE" >/dev/null
sudo sync
sudo cat "$TEST_FILE"
sudo stat "$TEST_FILE"

cleanup_test_file
trap - EXIT

mountpoint /backup/veeam

文件成功写入和读取，stat 显示文件位于 4096 字节 I/O 块的目标文件系统，测试文件随后已删除，mountpoint 确认 /backup/veeam 是有效挂载点。

至此我已经验证“当前 iSCSI 会话 → LUN → GPT → XFS → systemd 挂载 → 文件读写”链路。我还没有重启 Rocky 验证自动登录和自动挂载恢复，因此没有把 Linux 开机恢复写成已完成。

另外，本次最初的文件系统读写测试使用 root 完成。确定采用 Hardened Repository 后，才按单次凭据流程创建受限账户并调整挂载点权限；这个顺序可以避免在存储库类型尚未确定时提前猜测账户或错误地递归修改目录属主。

Thin Provisioning 的容量边界

两块 LUN 都使用 Thin Provisioning，因此客户端看到的 500 GB 是逻辑容量，飞牛 NAS 实际空间会随写入增长。在后续备份测试中我会同时观察：

• Windows/ReFS 或 Rocky/XFS 中的可用容量。
• Veeam Repository 页面显示的总容量与可用空间。
• 飞牛 NAS 存储空间 2（对应 /vol2）的真实已用容量；我采集环境数据时实测约 204 GB。
• 删除备份后是否支持并正确传递 SCSI UNMAP/TRIM 空间回收。

不能只看 Windows/Linux 仍有可用空间；如果飞牛底层存储池被 Thin LUN 实际写满，两台存储库都可能同时出现 I/O 错误。

八、阶段四：在 Veeam 中创建备份存储库

状态：已完成。Linux XFS 加固存储库与 Windows ReFS 普通存储库均已创建，状态为在线，容量与路径显示正常。

根据当前 VBR 13.0 Web UI，可直接选择的存储库类型包括：

• Microsoft Windows
• Linux
• Hardened Repository
• Veeam Data Cloud Vault

这两块 iSCSI LUN 已经分别挂载到 Windows 和 Rocky，因此我选择了与主机和安全目标对应的 Windows Repository 与 Hardened Repository。

我实际执行的步骤是：

1. 将存储库服务器添加为 Managed Server。
2. 检查 Veeam 组件部署结果。
3. 进入 Backup Repositories 创建新存储库。
4. 选择存储库服务器和实际挂载路径。
5. 设置最大并发任务数及读写速率限制。
6. 配置 Mount Server 和即时恢复缓存目录。
7. 如果使用 XFS，确认 Fast Clone 检测结果。
8. 如果使用 Hardened Repository，设置不可变天数并记录权限边界。
9. 完成向导，并在存储库列表确认状态、路径和容量。

Linux 实测：使用单次凭据登记 Hardened Repository 服务器

Hardened Repository 不能使用 Veeam 数据库中长期保存的 Linux 登录凭据。正确入口不是在存储库向导中直接输入服务器，而是先进入“备份基础设施 → 受管服务器 → 添加 Linux”，在 Access/SSH 凭据步骤中点击“添加”，并选择 Single-use credentials。

这组凭据只用于首次部署 Veeam Data Mover/Transport Service，不会作为长期 SSH 凭据保存在 Veeam 配置数据库中。

1. 普通已保存凭据不能直接改成加固存储库

我第一次尝试时，先把 Rocky Linux 按普通 Linux 受管服务器添加，随后在 Hardened Repository 向导中选择该服务器，出现错误：

Unable to use server <SERVER_IP> as it is registered with saved credentials.

这不是 XFS、iSCSI 或挂载点故障，而是凭据类型不符合加固存储库的安全要求。我确认该服务器还没有承载其他 Veeam 角色后，删除了普通受管服务器记录，然后使用单次凭据重新登记。这个操作不需要重新格式化 /dev/sdb1，也不需要删除 /backup/veeam。

2. 单次凭据不接受 root 用户

直接输入 root 账户时，Veeam 拒绝继续：

Root user cannot be accepted for single-use credentials due to security considerations.
Please specify a limited user account for the transport service, and use the root
password to elevate its privileges temporarily for the deployment.

因此我创建了一个带 home 目录的非 root 受限账户。下面是根据本次实测整理的可复用模板，<REPO_USER> 必须替换为专门用于 Hardened Repository 首次部署的非 root 账户；它不是现场账户的原值。

风险等级：CAUTION（创建本地账户并设置密码）

作用： 在 Rocky Linux 上创建带 home 目录和 Bash Shell 的受限账户，并交互式设置密码，供 Veeam 的 Single-use credentials 首次部署使用。 执行前检查： 用 getent passwd <REPO_USER> 确认目标用户名没有被其他服务占用；确认密码策略和 SSH 策略允许该账户完成一次性部署。 影响与回退： 创建账户会持久化修改本地用户数据库。只有在确认 Veeam 组件未使用该账户、home 目录中没有需要保留的数据时，才能通过受控的账户删除流程回退；不能在存储库投入使用后直接删除。 完成验证： id 和 getent passwd 应显示新账户、home 目录和预期 Shell。

REPO_USER='<REPO_USER>'

getent passwd "$REPO_USER" || true
sudo useradd --create-home --shell /bin/bash "$REPO_USER"
sudo passwd "$REPO_USER"

id "$REPO_USER"
getent passwd "$REPO_USER"

风险等级：CAUTION（修改存储库挂载点属主和权限）

作用： 让专用受限账户拥有 /backup/veeam 挂载点，并把权限收紧为仅属主可访问。 执行前检查： 先用 findmnt 确认该路径确实是目标 XFS 挂载点，再用 stat 记录原属主、属组和权限。这里只修改挂载点根目录，不递归修改已有备份数据。 影响与回退： chown 和 chmod 0700 会改变其他账户的访问能力。需要回退时，根据执行前记录恢复原属主、属组和权限。 完成验证： ls -ld 应显示新属主和 drwx------，runuser 写权限测试应成功。

REPO_USER='<REPO_USER>'

findmnt /backup/veeam
stat -c 'original_owner=%U:%G original_mode=%a path=%n' /backup/veeam

sudo chown "$REPO_USER:$REPO_USER" /backup/veeam
sudo chmod 0700 /backup/veeam

ls -ld /backup/veeam
sudo runuser -u "$REPO_USER" -- test -w /backup/veeam && echo "存储库目录可写"

这里只修改挂载点根目录的属主，不对未经检查的存量数据目录执行递归 chown。验证通过后，受限账户拥有 home 目录，并可写入 /backup/veeam。

3. sudo 失败且 su 回退超时

第一次使用新账户部署时，该账户还没有临时 sudo 权限，Veeam 先尝试 sudo，失败后又尝试通过 su 切换为 root，最终等待 60 秒后超时：

Unable to create elevated SSH connection: sudo failed and failover to su has failed
(Failed to switch to root. Timeout occurred (60 sec))

我采用 Rocky Linux 的 wheel 组临时授权，使 Veeam 在部署期间能使用受限账户自身的密码执行 sudo：

风险等级：DANGER（临时授予 root 级提权能力）

作用： 临时把 Hardened Repository 部署账户加入 Rocky Linux 的 wheel 组，使 Veeam 首次部署组件时可以通过 sudo 提权。 执行对象： 仅限已经确认的专用部署账户 <REPO_USER>。不要对日常账户、共享账户或来源不明的账户执行。 执行前检查： 用 id 和 getent group wheel 检查当前组成员，确认账户密码、SSH 登录和 sudo 策略符合预期，并安排在组件部署完成后立即回收。 安全边界： wheel 成员通常可以执行任意 root 命令。账户密码泄露会直接扩大为主机完全控制风险，因此授权窗口应尽可能短。 回退： 部署完成后立即执行下一节的 gpasswd -d，再通过 id、getent group wheel 和 sudo -l 确认提权能力已经回收。 完成验证： 授权阶段 id 应显示 wheel，切换到该账户后 sudo id 应返回 uid=0(root)；验证完成后不要长期保留该权限。

REPO_USER='<REPO_USER>'

id "$REPO_USER"
getent group wheel
sudo usermod -aG wheel "$REPO_USER"
id "$REPO_USER"

su - "$REPO_USER"
sudo id
exit

id 应显示用户属于 wheel；sudo id 需输入受限账户自身的密码，成功时返回 uid=0(root)。完成这项验证后，重新执行单次凭据向导，前述提权错误消失，服务器登记和组件部署成功完成。

4. 部署完成后回收提权能力

wheel 只用于首次部署。确认 Linux 服务器已通过单次凭据登记、Veeam 组件已成功部署后，应移除该用户的临时 sudo 权限：

风险等级：CAUTION（回收部署账户的提权权限）

作用： 从 wheel 组移除专用部署账户，缩短其 root 级提权窗口，同时保留 Veeam Transport Service 所需账户本身。 执行前检查： 确认 Managed Server 添加、组件部署和 Hardened Repository 创建均已成功；不要在部署仍进行时提前回收权限。 影响与回退： 回收后该账户不再能通过 wheel 使用 sudo。如果后续经过确认确实需要重新部署，可在受控维护窗口临时重新加入，并再次执行完整回收验证。 完成验证： id 和 getent group wheel 中都不应再出现该账户；sudo -l -U <REPO_USER> 不应显示通过 wheel 获得的授权。

REPO_USER='<REPO_USER>'

sudo gpasswd -d "$REPO_USER" wheel
id "$REPO_USER"
getent group wheel
sudo -l -U "$REPO_USER"

移除后，id 结果不应再包含 wheel。不要删除这个账户，因为它仍用于加固存储库的 Veeam Transport Service。在管理方式允许时，还可在部署完成后限制该账户的 SSH 登录，但不能在组件和存储库验证完成前盲目锁定账户。

我已经完成单次凭据登记、组件部署和存储库创建。不过，我还没有在部署结束后重新读取该账户的 id 结果，因此没有把“临时 wheel 权限已经回收”标记为已验证。

Linux 实测：创建 XFS 加固存储库

在“存储库 → 添加”菜单中选择“加固存储库”，而不是普通“Linux”。普通 Linux 存储库可以使用长期保存的凭据；加固存储库必须使用前面完成的一次性凭据登记。

向导识别到 /backup/veeam 位于约 500 GB 的 XFS 文件系统上。我最终使用 /backup/veeam/backups 作为实际备份目录，并采用以下设置：

我把不可变期限设为 7 天，方便在实验周期内观察保护与到期行为。这个值只对应我的实验；生产环境仍需按保留策略、勒索软件响应周期、存储容量和合规要求重新计算。

创建完成后，Veeam 显示 Linux 加固存储库在线，总容量约 499.7 GB，可用约 496.2 GB。这个结果证明管理面、目录访问和容量查询已经通过，但还不能代替真实备份和还原验证。

Windows 实测：创建 ReFS 普通存储库

Windows 分支中，我选择“Microsoft Windows”存储库类型，选中已经加入受管服务器的 Windows Server，并指定前面格式化完成的 D: 卷。

我的实际配置如下：

检查页面显示 Windows Mount Service、VMware VDDK、vPower NFS 等组件需要安装，这是该服务器首次承担存储库和挂载服务器角色时的正常行为。组件部署完成后，Windows 存储库显示在线，总容量约 499.9 GB，可用约 496.9 GB。

两套存储库创建结果

完成后，我在存储库列表中同时看到：

• Linux XFS 加固存储库：在线，路径 /backup/veeam/backups。
• Windows ReFS 普通存储库：在线，路径 D:\Backups。
• VBR Appliance 自带的默认存储库：在线，不作为本次 500 GB LUN 对比测试的目标。

九、阶段五：用真实备份和还原验证

状态：我还没有执行真实备份和还原。

存储库显示 Online 只能证明管理面连接成功，不能证明备份链和还原路径可用。下一阶段我至少会完成以下验证：

如果会话出现错误，我会保留完整错误信息、发生阶段、日志位置和处理过程，而不是只留下成功截图。

十、容易踩的坑

1. 把 SAN 注册到 Veeam 不等于创建存储库

Veeam 的存储阵列集成可以用于快照编排，但不能代替操作系统文件系统和 Backup Repository。FC/iSCSI LUN 仍需由存储库服务器接管。

2. 同一个普通 LUN 不可被多台主机同时读写挂载

普通 XFS、NTFS 或 ReFS 不是共享集群文件系统。除非明确使用受支持的集群方案，否则一个 LUN 只能由一台主机读写挂载。

3. 不能依赖 /dev/sdX

Linux 的 /dev/sdX 名称可能因重启、链路变化或设备发现顺序改变。涉及分区和格式化时必须使用 WWN、序列号和 multipath 映射交叉确认。

4. 多路径未配置好时不要创建文件系统

如果每条 FC/iSCSI 路径被识别成独立磁盘，在任意一条路径上格式化都可能造成错误或数据破坏。必须先确认 multipath 聚合结果。

5. NAS 挂载不等同于 Hardened Repository

把 SMB/NFS 目录挂到 Linux 上，不能自然获得 Hardened Repository 的安全边界。不可变存储需要结合受支持的 Linux、XFS、权限隔离和 Veeam 部署流程。

6. 不可变不能防住存储阵列最高管理员

Linux 文件系统级不可变可以防止普通删除和多数勒索软件攻击，但持有 SAN 最高权限的人仍可能删除 LUN、取消映射或破坏底层存储。生产环境应拆分 Veeam、Linux 和 SAN 管理权限。

十一、我目前得到的结论

到当前阶段，我已经完成并验证了下面两条数据链路：

飞牛 NAS Thin LUN
  → iSCSI
  → Windows Server
  → GPT + ReFS 64 KB
  → D:\Backups
  → Veeam Windows Repository（Online）

飞牛 NAS Thin LUN
  → iSCSI
  → Rocky Linux 9
  → GPT + XFS 4 KB / reflink / CRC
  → /backup/veeam/backups
  → Veeam Hardened Repository（Online，7 天不可变）

这次实验也让我确认了几个容易混淆的边界：

• FC/iSCSI LUN 是块设备，不能绕过 Windows/Linux 文件系统直接变成 Veeam Backup Repository。
• ReFS 64 KB 与 XFS reflink 分别为 Windows 和 Linux Fast Clone 提供文件系统基础。
• “长期保存的 Linux 凭据不能用于加固存储库”，不等于所有 Linux 存储库都不能使用长期凭据。
• 存储库显示 Online 只代表当前管理面和目录访问正常。Windows 重启恢复已经实测；Rocky 重启恢复、真实备份、还原与不可变删除仍需单独验证。
• Linux 文件系统不可变不能阻止 NAS 最高管理员删除整个 LUN，因此存储、Veeam 和 Linux 管理权限仍需分离。

十二、我接下来要验证什么

我会按以下顺序完成最终验收：

1. 重启 Rocky Linux，验证 iSCSI 节点自动登录、持久化 LUN 分区重新出现以及 /backup/veeam 自动挂载。
2. 读取 Hardened Repository 部署账户的组成员，确认部署期间使用的临时 wheel 权限已回收。
3. 分别对 Windows/ReFS 与 Linux/XFS Hardened Repository 创建小型测试备份作业，记录会话结果、备份文件和容量变化。
4. 对测试备份执行文件级还原，验证 Windows 与 Linux Mount Server 路径均可使用。
5. 在专用测试备份上验证 7 天不可变边界，并确认普通删除、Veeam 删除与期限到期后的行为差异。
6. 观察删除备份后的 SCSI UNMAP/TRIM 传递情况，确认 Thin LUN 和 NAS 存储池空间是否按预期回收。

参考资料

• Veeam Backup & Replication 13 User Guide：Fast Clone
• Veeam Backup & Replication 13 User Guide：Backup Repository System Requirements
• Veeam Backup & Replication 13 User Guide：Adding Hardened Repositories
• Veeam Backup & Replication 13 User Guide：Specify Credentials and SSH Settings

这是我记录 Veeam Backup & Replication 13 实验过程的第一篇。接下来我会继续记录测试备份、文件级还原、不可变边界与存储空间回收验证。