Symantec Backup Exec 备份 ESXi 超融合虚拟机完整实战教程

一、为什么用 Backup Exec 备份 ESXi 超融合虚拟机

企业在 ESXi 超融合架构上跑了几十台甚至上百台虚拟机后,数据保护立刻变成第一优先级问题。虚拟机数量一多,传统的”在每台 VM 里装备份 Agent”的方案就显出三个致命问题:一是每台 VM 都要消耗资源跑 Agent,100 台就是 100 个 Agent 进程;二是 Agent 备份走的是 Guest OS 内部通道,无法做到整机一致性快照,SQL Server 正在写入的事务可能只备份了一半;三是恢复粒度差,只能恢复整个卷,不能恢复到任意一台 ESXi 主机的任意路径。

Symantec Backup Exec(现归属 Veritas,后文统一称 Backup Exec)在 VMware 备份领域的核心价值,就是解决以上三个问题。它通过 VMware vStorage APIs for Data Protection(VADP)接口,在 vCenter/ESXi 层面接管备份流程,无需在每个 VM 里装 Agent。这就是Agentless 备份的核心思路。

对比几类主流方案的差异,可以更清楚看到 Backup Exec 的定位:

方案	是否需要 Agent	一致性快照	整机恢复	授权成本
Backup Exec + VADP	不需要(Agentless)	支持(快照+静默)	支持	中
VM 内装 Agent	每台都要装	依赖 Guest OS	只恢复到本机	低
Veeam Backup & Replication	不需要	支持	支持	中高
VMware vDP/vSphere Data Protection	不需要	支持	支持	捆绑

结论:如果你已经有 Backup Exec 授权(很多企业买它是为了备份 SQL/Exchange/文件服务器),那么用现有授权顺带把 VMware 也覆盖了,边际成本最低,统一管理界面也省培训成本。如果你专门为了备份 VMware 而新购,需要权衡 Veeam 这类纯虚拟化备份工具——Veeam 在虚拟化备份的功能深度上更专业,但 Backup Exec 在物理/虚拟/云端统一备份上的覆盖面更广。

二、Backup Exec 架构与 VMware 集成原理

动手部署前,先把 Backup Exec 的几个核心概念和 VMware 集成链路理清楚,避免后面排查故障时一头雾水。

2.1 Backup Exec 的三层架构

Backup Exec 不是单机软件,它由三部分组成,理解清楚后部署才不会乱:

• Central Administration Server(CAS,中央管理服务器):整个备份域的大脑,统一管理所有 Backup Exec Server、策略、作业、报告。一个备份域里只能有一台 CAS(也可以没有,但失去集中管理能力)。
• Media Server(介质服务器):真正负责读写备份数据的服务器,把数据写到磁盘存储、去重池、磁带库或云端。一个备份域可以有多台 Media Server 做负载均衡和分布式备份。小型环境一般 CAS 和 Media Server 装在同一台机器。
• Remote Agent(远程代理,简称 RAWS):装在被备份的客户端 上。在 VMware Agentless 场景下,RAWS 实际上不需要装在每台 VM 里,而是装在 vCenter Server 或一台专门的代理 VM 上,作为 VADP 调用的桥梁。

VMware 备份链路:Backup Exec Media Server 通过 vCenter Server(或直连 ESXi)调用 VADP 接口 → ESXi 创建虚拟机快照 → 快照数据通过 SAN/NBD/nbdssl 传输到 Backup Exec 存储 → 备份完成,快照删除。整个过程不需要在每台 VM 里装任何东西。

2.2 VADP 与三种传输模式

VADP 是 VMware 官方开放的备份接口,Backup Exec 通过它来读取虚拟机磁盘数据。传输模式有三种,性能差异极大:

模式	传输路径	性能	适用场景
SAN(基于存储阵列)	直接从 FC/iSCSI 存储读 LUN,绕过 ESXi	最快(几乎本地盘速度)	有 FC SAN 的传统架构
Hot-Add(热添加)	把 VM 磁盘热插到备份代理 VM	快(几乎本地盘速度)	超融合架构首选
NBD/NBDSSL(网络)	通过 ESXi 管理网络读	最慢(网络瓶颈)	无 SAN 时的兜底方案

关键点:超融合架构下,Hot-Add 是最优选择。因为超融合(如 vSAN、Nutanix、华三、深信服等)的本质是把存储和计算融合在同一个 ESXi 集群,数据本来就在 ESXi 本地盘上,Hot-Add 模式可以把要备份的 VM 磁盘临时挂载到 Backup Exec 代理 VM 上,直接从本地 SSD 读数据,速度能达到每秒数百 MB,比走管理网络的 NBD 模式快 5-10 倍。

Backup Exec 默认按”SAN > Hot-Add > NBD”顺序自动协商,只要配置正确,通常会自动用 Hot-Add。后面章节会讲具体配置。

2.3 一致性快照与应用静默

Agentless 备份的关键挑战是:备份过程中 VM 还在运行,数据可能在变化。VADP 提供两种快照处理方式:

• Crash-consistent(崩溃一致):只冻结 VM 整个磁盘的 IO,不通知 Guest OS。这相当于物理机拔电源的状态——文件系统结构完整,但正在写入的事务可能不完整。SQL Server 等数据库在恢复时需要做事务日志回滚。
• File-system consistent(文件系统一致):Backup Exec 通过 VMware Tools 在 Guest OS 里调用 VSS(Windows)或 fsfreeze(Linux),先静默应用再冻结磁盘。SQL Server 收到 VSS 信号后会完成当前事务并冻结日志,恢复后无需回滚。这是生产环境必须的方式。

要让 Backup Exec 自动调用 VSS,需要在 VM 里装 VMware Tools(绝大多数 VM 默认装了),并且 Backup Exec 备份任务的”启用应用程序静默“选项要勾选。

三、Backup Exec 安装与超融合环境部署

理论铺垫够了,现在动手装。下面的步骤以 Backup Exec 22.x(2022 年后的长期支持版本)为例,操作系统推荐 Windows Server 2019/2022 标准版或数据中心版。

3.1 硬件规划:Media Server 最低配置

Backup Exec Media Server 是 IO 密集型,内存和磁盘是重点:

• CPU:8 核起步,备份任务并行越多越要堆 CPU,默认情况下每核同时处理 1-2 个 VM 流。
• 内存:32GB 是底线。如果开启客户端去重(Client-side Deduplication),每处理 1TB 备份数据约占用 1GB 内存用于去重索引,50TB 数据就需要至少 50GB 内存。
• 系统盘:RAID 1 的 SSD,300GB 起步。Backup Exec 的目录库(Database)会持续增长。
• 备份目标盘:强烈建议用独立磁盘池,不要和系统盘混。可以是本地大容量 HDD(价格便宜)、直连的 JBOD 柜、iSCSI SAN,或者云端(B2D Cloud)。
• 网络:至少 2 块万兆网卡。一块走 vCenter/ESXi 管理流量,一块走备份数据传输。

3.2 安装顺序与组件选择

把 Backup Exec 安装包拷贝到 Media Server,以管理员权限运行 setup.exe。按这个顺序选组件:

1. 第一阶段:安装主程序,选 “Install on this computer”。
2. 组件勾选:勾上 Backup Exec Server、Administration Console、Agent for Windows、Agent for VMware、VMware vCenter/ESXi Server。Agent for VMware 必须勾,这是 Agentless 备份的核心组件。
3. 数据库选择:本地 SQL Server(Backup Exec 自带 SQL Express 或挂外部 SQL Server 标准版)。生产环境强烈建议挂外部 SQL Server,SQL Express 只能管到 100 个作业就撑不住。
4. 服务账户:用一个专用的域账户(如 DOMAIN\svc-backup)运行 Backup Exec 服务,不要用 Administrator。这个账户需要加入 vCenter 的管理员组、ESXi 的本地管理员、所有被备份 VM 的 Backup Operators 组(如果走 RAWS 备份)。
5. 重启:装完自动重启,启动 Backup Exec 服务。

超融合环境的关键补充:需要在一台专用 Windows VM(备份代理 VM)上再装一遍 Backup Exec Agent for Windows + Agent for VMware。这台 VM 是 Hot-Add 模式的”目标 VM”,Backup Exec 通过它来挂载其他 VM 的磁盘。

3.3 防火墙与端口规划

Backup Exec 涉及的端口比较多,提前在防火墙里放行,否则后面调试会被端口问题卡半天:

端口	用途	方向
10000	Backup Exec 服务主端口	Media Server ↔ Agent
10101	CAS 管理端口	CAS ↔ Media Server
443	vCenter HTTPS API	Media Server → vCenter
902	VMware VADP 数据(NBD 模式)	Media Server → ESXi
445	SMB(备份目标为 Windows 共享时)	Media Server → 存储
3260	iSCSI(备份目标为 iSCSI 时)	Media Server → 存储

四、连接 vCenter 与 ESXi 接入配置

Backup Exec 装好后,下一步是告诉它”我要备份哪台 vCenter 下面的哪些 VM”。

4.1 添加 VMware vCenter/ESXi Server 凭据

打开 Backup Exec 管理控制台 → 左侧”配置和设置” → “VMware 凭据” → “新建”。填入:

• 显示名称:自定义,例如 vCenter-Production。
• 服务器地址:vCenter 的 FQDN 或 IP(如 vcenter01.corp.local)。
• 用户名:vCenter 的管理员账号(如 DOMAIN\backup-admin 或 administrator@vsphere.local)。
• 密码:对应密码。
• 端口:默认 443。

添加后点”测试连接”,看到绿色的对勾才说明凭据可用。常见失败原因:① vCenter 用了自签名证书,Backup Exec 默认不信任——需要在 Backup Exec 的”设置 → 网络与安全 → 信任的根证书”里导入 vCenter 证书;② 账号权限不足——vCenter 账号至少需要虚拟机 → 快照管理 → 创建快照 + 删除快照 + 读取数据三组权限,以及存储读取权限。

4.2 添加 VMware 服务器到备份域

凭据通过后,在 Backup Exec 主界面 → “备份和还原” → 左侧树形菜单右键 “VMware vCenter/ESXi 服务器” → “添加 VMware 服务器”。这一步让 Backup Exec 通过 vCenter 列举所有 VM,并按文件夹、数据中心、集群、单机来组织视图。

添加成功后,你应该能在 Backup Exec 资源树里看到类似这样的结构:

vCenter-Production
└── Datacenter-DC01
    └── Cluster-Prod
        ├── ESXi-Host01 (192.168.10.11)
        │   ├── VM-WebServer01
        │   ├── VM-DBServer01
        │   └── VM-AppServer01
        ├── ESXi-Host02 (192.168.10.12)
        │   ├── VM-WebServer02
        │   ├── VM-DBServer02
        │   └── VM-DC01
        └── ESXi-Host03 (192.168.10.13)
            └── VM-FileServer01

4.3 配置 Hot-Add 备份模式

超融合架构下,要启用 Hot-Add 才能发挥本地 SSD 的性能。打开 Backup Exec → “配置和设置” → “VMware” → “虚拟设备设置” → 勾选 “Use Hot-Add to backup virtual machines“。

同时,需要指定 Hot-Add 用的代理 VM(Backup Exec Proxy / Appliance):

1. 在之前那台专用的 Windows 备份代理 VM 上,装好 Backup Exec Remote Agent。
2. 这台 VM 需要放在每个 ESXi 主机本地存储上(不是共享存储上),否则 Hot-Add 性能提升有限。
3. VM 至少配置 4 个 vCPU、8GB 内存,操作系统用 Windows Server 2019/2022。
4. 在 Backup Exec → “配置和设置” → “VMware” → “代理 VM” 里,把每台 ESXi 主机的代理 VM 都加进去(可以共用一台,只要它在每台 ESXi 上都能访问)。

验证 Hot-Add 是否生效:右键任意 VM → “备份” → “高级” → “传输方式”,能看到 “Hot-Add (Recommended)” 选项且默认被选中即可。

五、创建备份策略与任务

基础设施都连通了,现在开始配置实际的备份作业。这是核心中的核心,做好备份策略,数据才能真正被保护。

5.1 选择备份方式:完整 vs 增量 vs 差异

Backup Exec 在 VMware 备份场景下支持三种模式:

• 完整备份(Full):每次备份整台 VM 的所有磁盘。数据量最大、耗时最长,但恢复最快——一份数据就是完整的。
• 增量备份(Incremental):只备份自上次任意备份后变化的数据块。数据量最小,但恢复时需要”完整 + 所有增量”按顺序回放,链条长恢复慢。
• 差异备份(Differential):只备份自上次”完整备份”后变化的数据。数据量介于两者之间,恢复只需”完整 + 最近一次差异”。

推荐方案:周日完整 + 周一至周六增量(经典 6+1)。完整备份每周覆盖一次,确保数据完整性;增量备份每晚做,减少网络和存储压力。恢复时最多回放 6 个增量,链条在可控范围。

5.2 启用客户端去重(可选)

如果备份数据量大(超过 10TB),强烈建议开启 客户端去重(Client-side Deduplication)。原理:在 Media Server 上对备份数据块计算哈希,相同的数据块只写一份。开启前后的存储对比:

场景	原始数据	去重后存储	节省比例
50 台同 OS 模板 VM	5TB	800GB	84%
20 台文件/数据库 VM	3TB	1.6TB	47%
大量小文件为主的 VM	2TB	1.5TB	25%

配置:创建备份任务 → “存储”选项卡 → “启用重复数据删除”→ 选择现有的去重池(或者让 Backup Exec 自动创建)。代价:启用去重后,备份和恢复时的 CPU/内存占用会显著上升,Media Server 必须配备至少 32GB 内存。

5.3 创建第一个备份任务

以”每周日完整 + 周一至周六增量”为例,具体步骤:

1. 主界面 → “备份和还原” → 工具栏 → “备份向导”。
2. 选择备份源:展开 VMware 树,勾选要备份的 VM(支持多选,也可以选择整个集群或文件夹)。
3. 选择目标:选择已配置的备份存储(去重池 / 磁盘文件夹 / 磁带)。
4. 备份方式:选 “Full – Up to the latest backup set”。
5. 调度:”完整备份”调度:每周日 23:00。”增量备份”调度:每天 23:00,但要排除周日——具体做法是创建两个独立的策略,或者用一个策略里设”每周日完整 + 其他日子增量”。
6. 高级选项:勾选”启用应用程序静默”(“Enable application quiescing”);勾选”使用 Hot-Add 模式”;保留期设 30 天(按合规要求调整)。
7. 完成向导,任务出现在列表里。右键”立即运行”做一次手动测试,确认成功后再交给调度。

5.4 关键参数详解

备份任务里几个容易被忽略但很重要的参数:

• 作业数上限(Job count limit):同时跑多少个备份任务并行,默认 4。ESXi 集群规模大的话可以调到 8-16,但要考虑 IO 压力。
• 块大小(Block size):默认 64KB。VM 磁盘是大量小文件(如文件服务器)用 64KB;大文件为主(如 SQL Server、Exchange)用 128KB-256KB 能减少元数据开销。
• 快照保留(Snapshot retention):备份过程中会先在 ESXi 上创建快照,备份完成后删除。如果备份失败或中断,可能留下孤儿快照——这个参数控制自动清理孤儿快照的等待时间,默认 24 小时。
• 启用变更块跟踪(CBT, Changed Block Tracking):必须勾选。CBT 让 ESXi 记录哪些磁盘块发生变化,增量备份只读变化部分,不读整个磁盘。不勾的话增量备份会退化成全量扫描,性能极差。

六、超融合实战:50 台 VM 备份方案设计

现在把所有内容串起来,用一个真实场景讲一遍完整设计。

6.1 场景描述

假设企业有一套 ESXi 超融合集群,配置如下:

• 3 台 ESXi 主机(Host01-03),每台配 2 颗 16 核 CPU、256GB 内存、4 块 1.92TB SSD(本地 NVMe)。
• 集群总容量约 11TB(扣除冗余后),已部署 50 台 VM,包括 10 台 Windows Server(AD、Exchange、SQL、文件服务器)、30 台 Windows 10/11 办公终端、10 台 Linux(CentOS、Ubuntu)。
• 已有 Backup Exec 22.x 授权,授权容量覆盖 VMware Infinite Library(按 CPU 数授权)。
• 备份目标:1 台独立的备份存储服务器(Windows Server 2022 + 50TB RAID 6 HDD),10GbE 网络连接。

6.2 备份策略矩阵

VM 类型	数量	备份频率	保留期	传输模式
核心业务(AD、SQL、Exchange)	10	完整+增量,每天	30 天	Hot-Add
办公终端(Win10/11)	30	增量,每天	14 天	Hot-Add
Linux 业务	10	完整+增量,每天	30 天	Hot-Add

6.3 任务分组与调度窗口

50 台 VM 不能一次性跑完,峰值会拖垮存储和网络。按业务优先级分三个任务组,错开调度窗口:

1. 组 A(核心业务):周日至周五 23:00 完整备份(周日)/ 增量(其他日),10 台 VM 并发跑,预计 1.5 小时完成。
2. 组 B(办公终端):每天 22:00 增量备份,30 台 VM 分 5 批跑,每批 6 台,预计 2 小时完成。
3. 组 C(Linux 业务):周日至周五 01:00(组 A 跑完后),10 台 VM 并发,预计 1 小时完成。

关键约束:每台 ESXi 主机同时承载的备份任务不超过 4 个,否则快照创建会排队,VM 性能下降明显。如果一台 ESXi 上 VM 数量多,在 Backup Exec 里设置”每主机最大并发任务数”限制。

6.4 容量规划与增长预测

50 台 VM 原始数据约 8TB,启用客户端去重后预计 4TB。每月按 30 天完整备份 + 4 个周日重复数据估算:

每日增量平均变化率:5%(保守估计)
每日增量数据:8TB × 5% × 60台 = 24GB
每周完整数据:8TB × 70%(去重率) = 5.6TB
每月总数据:(24GB × 30天) + (5.6TB × 4周) = 720GB + 22.4TB ≈ 23TB

三年增长预测:23TB × 12月 × 3年 × 1.2(膨胀系数) = 996TB
结论:三年内需要约 1PB 的备份存储,推荐 1.2PB 起配。

6.5 实战部署步骤

按这套设计,完整部署流程:

1. 准备阶段:在 vCenter 上创建专用账号 DOMAIN\svc-backup,加入本地管理员组,授予”VADP 备份”权限。
2. 网络配置:备份存储服务器和 Media Server 之间配 10GbE 专线,MTU 9000;Media Server 到 vCenter/ESXi 走独立 VLAN(避开业务网络)。
3. Media Server 安装:按 3.2 节步骤安装 Backup Exec,挂外部 SQL Server,服务账户用 svc-backup。
4. 备份代理 VM 部署:创建一台 Windows Server 2022 VM(8 vCPU、16GB 内存、系统盘 100GB SSD),放在每台 ESXi 的本地存储上,装 Remote Agent + Agent for VMware。
5. 凭据配置:按 4.1 节添加 vCenter 凭据,测试通过。
6. 添加 VMware 服务器:按 4.2 节添加 vCenter 到 Backup Exec,展开资源树确认所有 50 台 VM 可见。
7. 配置 Hot-Add:按 4.3 节启用 Hot-Add,把 3 台 ESXi 的代理 VM 都注册进去。
8. 配置去重池:创建去重池,容量上限设为备份存储的 90%(留 10% 给元数据)。
9. 创建三个备份任务组:按 6.3 节的策略矩阵创建。
10. 首次完整备份测试:手动触发组 A 的完整备份,观察 1.5-2 小时跑完,验证数据完整性。
11. 调度交接:确认手动测试通过后,把三个任务交给调度,24 小时后检查增量备份是否成功。

七、备份恢复:从单文件到整机灾难恢复

备份只是开始,数据能不能恢复出来才是关键。这一节讲 Backup Exec 的恢复能力。

7.1 文件级恢复(GRT)

Granular Recovery Technology(GRT)是 Backup Exec 的核心优势——不用恢复整个 VM,可以从 VM 备份里直接抽取单个文件/邮件/数据库表。这在用户误删文件场景下极其有用。

操作:右键备份任务 → “还原” → “浏览还原点” → 选择时间点 → 进入文件树浏览,找到要的文件 → 还原到指定位置。注意 GRT 要求目标 VM 运行 VMware Tools,且原始 VM 的 Windows 版本支持 VSS 索引。

7.2 整机恢复

整机恢复有两种:

• 还原到原始位置:直接把 VM 还原到原来的 vCenter/ESXi,自动覆盖当前 VM(或保留为新 VM)。这种方式适合灾难恢复——VM 整个被删了,从备份里重建。
• 还原到备用位置(Instant Recovery):VMware 的即时恢复能力,Backup Exec 把备份文件直接挂载成 VM 启动,无需先复制完整数据到存储。几分钟内就能拉起 VM,数据在后台慢慢回写。适合生产环境故障应急。

操作:右键备份任务 → “还原” → “VMware 还原” → 选择目标 vCenter、ESXi 主机、文件夹、资源池 → 选还原点 → 确认。

7.3 灾难恢复演练流程

每季度必须做一次真实恢复演练。流程:

1. 选一台非关键业务 VM 作为演练目标(不要选生产库)。
2. 在 Backup Exec 里记录它的最新备份时间点。
3. 删除这台 VM(模拟灾难)。
4. 从 Backup Exec 整机还原。
5. 启动 VM,验证业务能正常起来。
6. 记录恢复时间(从删到业务恢复),作为 RTO 指标。
7. 删除演练用的 VM,清理环境。

八、性能调优与常见故障

8.1 性能调优要点

• 并发任务数:Media Server 的并行任务数 = CPU 核心数 × 0.8。盲目加大并发会因磁盘 IO 争抢反而变慢。
• 去重池位置:去重池放在独立磁盘上,不要和备份数据存同盘,否则读写互相影响。
• 备份窗口监控:用 Backup Exec 报告 → “作业完成时间趋势”,看每天备份耗时是否在增长。增长超过 20% 说明数据膨胀超过规划,要考虑扩容或调整策略。
• 网络 MTU:备份走 10GbE 时开启巨型帧(MTU 9000),传输效率提升 30%+。

8.2 高频故障速查

故障 1:备份作业提示 “Unable to quiesce guest filesystem“。
原因:VM 没装 VMware Tools,或者 Guest OS 里 VSS 服务异常。
修法:确保所有 VM 都装了 VMware Tools 并启动;Windows 检查 Volume Shadow Copy 服务是否自动启动。

故障 2:Hot-Add 失败,自动降级到 NBD,速度变慢。
原因:通常是代理 VM 没有访问源 VM 磁盘所在 datastore 的权限,或者代理 VM 自身的 datastore 不在本地。
修法:把代理 VM 迁到本地存储(非共享),确保每台 ESXi 至少一台代理 VM 可用。

故障 3:备份任务跑了一半失败,提示 “Snapshot consolidation needed“。
原因:快照未正确删除,累积成”快照链”,既占空间又影响后续备份。
修法:在 vSphere Client 里找到该 VM → 右键 → “快照” → “管理快照” → “删除所有快照” → “整合”。

故障 4:GRT 文件恢复时找不到文件。
原因:VM 是 Linux 系统且没装 VMware Tools,或文件系统是 ext4 但 Backup Exec 版本不支持 GRT 索引。
修法:Linux VM 必须装 VMware Tools 才能 GRT。Windows NTFS 默认支持。

九、与其他备份方案的对比

最后,客观比较一下 Backup Exec 与同类方案,帮你做选型决策。

维度	Backup Exec 22.x	Veeam B&R	Commvault
VMware 备份深度	标准 Agentless,支持 CBT	专业级,VM 备份的标杆	企业级,功能最全
物理/虚拟/云统一	✓ 最强	△ 需要 Veeam ONE + 云连接器	✓
授权方式	按 CPU 数 + 实例数	按 VM 数	按前端 TB
学习曲线	中等	友好	陡峭
成本	中等	中偏高	高
适合场景	已有 BE 授权 + 物理+虚拟混合	VMware/Hyper-V 纯虚拟化环境	大型企业多云多平台

结论清晰:已有 BE 授权 → 继续用 BE 备份 VMware,边际成本最低;VMware 为主 → Veeam 更专业;多云多平台超大型企业 → Commvault。

十、最佳实践清单

最后整理一份日常运维 checklist,按这个清单做能避免绝大多数常见问题:

• 3-2-1 备份原则:3 份数据副本、2 种介质、1 份异地。本地一份、备份存储一份、云端归档一份。
• 定期演练:每季度一次真实恢复演练,验证 RTO/RPO 符合业务要求。
• 监控告警:配置 Backup Exec 的告警邮件,任何备份失败立即通知管理员。
• CBT 必须开启:VMware 6.0+ 默认开启 CBT,Backup Exec 必须勾选 Use CBT,否则增量备份会全盘扫描。
• VMware Tools 全量部署:每台 VM 必须装且保持最新,影响 VSS 静默和 CBT 跟踪。
• 日志定期清理:Backup Exec 的日志和事件库会持续增长,每月清理一次 90 天前的日志。
• 授权合规检查:每季度核对授权覆盖的 VM 数量,避免超授权被厂商审计罚款。
• 网络隔离:备份流量走独立 VLAN,不与业务网络混用,避免相互影响。

Backing up ESXi 超融合环境是”做一次就能睡 5 年”的事,前期投入多一点精力把架构和策略设计好,后面日常运维就会非常省心。反之,生产环境真出问题再去救火,代价远高于前期多花一周精心规划。