nand.bin怎么备份如何备份ESXi主机的配置信息

发布时间 : 2024-11-24

作者 : 小编

访问数量 : 23

扫码分享至微信

如何备份ESXi主机的配置信息

在做ESXi主机升级时，一般建议对ESXi主机的配置进行备份，这些配置包括ESXi主机的NTP配置，标准虚拟交换机的配置，主机名，高级配置参数设置等等，这些设置在esxi主机升级失败，回滚失败时，又或者重新安装esxi主机时，都会用到，当然有人会说我可以重新配置，是的，没错，确实是可以这样，但是多麻烦对吧。

好了，言归正传，我们看下备份过程。

备份ESXi主机配置需要满足两个前提条件：

主机的目标内部版本号与进行备份的内部版本匹配。主机的 UUID 保持不变。

您可以使用以下方法之一备份和还原主机配置：

1、ESXi 命令行

2、vSphere CLI

3、vSphere PowerCLI

一、ESXi 命令行

（1）备份 ESXi 主机配置数据，要将已更改的配置与持久存储同步，请运行以下命令：

vim-cmd hostsvc/firmware/sync_config

（2）要备份 ESXi 主机的配置数据，请运行以下命令：

vim-cmd hostsvc/firmware/backup_config

注意：此命令将输出一个 URL (http://*/downloads/123456/configBundle-xx.xx.xx.xx.tgz)，可以使用 Web 浏览器下载文件。

* 表示主机 IP/FQDN。

从 Web 浏览器，导航到 http://Host_FQDN/downloads/123456/configBundle-xx.xx.xx.xx.tgz

在此示例中，主机的 IP 地址为 192.168.0.81

备份文件将以 configBundle-HostFQDN.tgz 形式存放在 /downloads 目录（浏览器的默认目录或选择下载到特定目录）

（3）还原 ESXi 主机配置数据

注意：要还原配置，目标 ESXi 主机必须与 ESXi 主机配置数据具有相同的内部版本。可以使用 vmware -vl 命令获取主机内部版本。

在启动还原命令之前，应首先将 configBundle-HostFQDN.tgz 重命名为 configBundle.tgz。

运行以下命令，将主机置于维护模式：

vim-cmd hostsvc/maintenance_mode_enter

将备份配置文件复制到 ESXi 主机或可用数据存储。

运行以下命令，还原 ESXi 主机配置：

vim-cmd hostsvc/firmware/restore_config /backup_location/configBundle.tgz

注意：

添加 1 可强制替代不匹配的 UUID。

例如：

vim-cmd hostsvc/firmware/restore_config 1 /tmp/configBundle.tgz

执行此命令将在命令完成后启动主机的自动重新引导。

但是，从 vSphere 7.0 U2 开始，可以使用 TPM 对配置进行加密，在这种情况下，如果主机发生更改，则 -force 选项将不起作用。我们需要使用备份期间在主机上使用的相同 TPM 进行还原。也就是说，从 vSphere 7.0U2 开始，如果主机启用 TPM，替代将不起作用。

二、vSphere CLI

（1）备份 ESXi 主机配置数据

运行以下命令，备份 ESXi 配置：

vicfg-cfgbackup --server=ESXi_host_IP_address --username=root -s output_file_name

例如：

vicfg-cfgbackup --server=10.0.0.1 --username=root -s ESXi_test1_backup.tgz

在适用于 Windows 的 vSphere CLI 中：导航到 C:\Program Files\VMware\VMware vSphere CLI\bin运行以下命令，备份 ESXi 配置：

vicfg-cfgbackup.pl --server=ESXi_host_IP_address --username=root -s output_file_name

例如：

vicfg-cfgbackup.pl --server=10.0.0.1 --username=root -s ESXi_test1_backup.tgz

注意：

使用 --password=root_password 选项可跳过密码提示。备份文本文件保存在运行 vicfg-cfgbackup 脚本的当前工作目录中。

（2）还原 ESXi 主机配置数据

还原主机配置将还原 ESXi 的状态以及任何 vSphere 标准交换机网络连接配置。

注意：还原配置数据时，主机的内部版本号必须与备份文件上的主机内部版本号匹配，同时主机的 UUID（可使用“esxcfg-info -u”命令获取）应与备份文件上的主机 UUID 匹配。使用 -f 选项（强制）可替代不匹配的 UUID。但是，从 vSphere 7.0 U2 开始，可以使用 TPM 对配置进行加密，在这种情况下，如果主机发生更改，则 -force 选项将不起作用。我们需要使用备份期间在主机上使用的相同 TPM 进行还原。也就是说，从 vSphere 7.0U2 开始，如果主机启用 TPM，替代将不起作用。

在 vSphere CLI 中，要使用 vSphere CLI 还原 ESXi 主机的配置数据，请执行以下操作：

1、将要还原的主机置于维护模式。

2、登录到安装了 vCLI 的服务器。

3、运行带 -l 标记的 vicfg-cfgbackup 脚本，以便从指定的备份文件加载主机配置：

vicfg-cfgbackup --server=ESXi_host_IP_address --username=root -l backup_file

例如：

vicfg-cfgbackup --server=10.0.0.1 --username=root -l ESXi_test1_backup.txt

适用于 Windows 的 vSphere CLI：

vicfg-cfgbackup.pl --server=ESXi_host_IP_address --username=root -l backup_file

例如：

vicfg-cfgbackup.pl --server=10.0.0.1 --username=root -l ESXi_test1_backup.txt

注意：绕过确认可继续使用 -q 选项。

要将 ESXi 主机还原为常用配置设置，请运行以下命令：

vicfg-cfgbackup --server=ESXi_host_IP_address --username=root -r

例如：

vicfg-cfgbackup --server=10.0.0.1 --username=root -r

注意：应重新引导 ESXi 主机，配置更改才会生效。

三、在 vSphere PowerCLI 中

（1）备份 ESXi 主机配置数据

Get-VMHostFirmware -VMHost ESXi_host_IP_address -BackupConfiguration -DestinationPath output_directory

对于 ESXi 6.7，请参见 Reset the System Configuration

例如：

Get-VMHostFirmware -VMHost 10.0.0.1 -BackupConfiguration -DestinationPath C:\Downloads

注意：备份文件保存在使用 -DestinationPath 选项指定的目录中。

（3）还原 ESXi 主机配置数据

注意：还原配置数据时，主机的内部版本号必须与备份文件上的主机内部版本号匹配，同时主机的 UUID（可使用 esxcfg-info -u 命令获取）应与备份文件上的主机 UUID 匹配。使用 -force 选项可替代不匹配的 UUID。但是，从 vSphere 7.0 U2 开始，可以使用 TPM 对配置进行加密，在这种情况下，如果主机发生更改，则 -force 选项将不起作用。我们需要使用备份期间在主机上使用的相同 TPM 进行还原。也就是说，从 vSphere 7.0U2 开始，如果主机启用 TPM，替代将不起作用。

1、运行以下命令，将主机置于维护模式：

Set-VMHost -VMHost ESXi_host_IP_address -State 'Maintenance'

2、运行以下命令，从备份包还原配置：

Set-VMHostFirmware -VMHost ESXi_host_IP_address -Restore -SourcePath backup_file -HostUser username -HostPassword password

例如：

Set-VMHostFirmware -VMHost 10.0.0.1 -Restore -SourcePath c:\bundleToRestore.tgz -HostUser root -HostPassword exampleRootPassword

Related Information

注意：有关虚拟机的信息不会存储在配置备份中，且必须在配置备份还原后从数据存储浏览器中将虚拟机重新列入清单。此外，引导槽信息也不会存储在配置备份中。如果需要，必须使用压缩的 tar 文件单独备份和下载这些信息。

注意：

如果安装的 vSphere 版本高于 5.1，请参见 VMware 文档库中与该版本对应的命令行文档和 PowerCLI 参考。PowerCLI 说明：请注意，PowerCLI 的 64 位版本安装在 C:\Program Files 下，32 位版本安装在 C:\Program Files (x86) 下。必须始终以管理员身份运行 PowerCLI。

PolarDB-X 20 全局 Binlog 和备份恢复能力解读

简介： PolarDB-X 2.0 针对数据孤岛问题提供了全局 Binlog 能力，该能力为下游生态提供了与 MySQL Binlog 完全一致的增量日志消费体验。针对数据损坏问题提供了实例级、表级、SQL 级和行级等不同粒度的数据恢复能力，包括一致性备份恢复、表回收站、SQL 闪回、Flashback Query 等。

发布会传送门：https://yqh.aliyun.com/live/polardbx2021

背景

我们作为开发者都了解或熟悉后台系统，后台系统可以抽象为两个组成部分：一个是业务系统，该部分负责处理系统的业务逻辑，在现代化的架构中，该部分通常设计成可水平扩展的无状态节点；另一个是数据库系统，该部分负责存储系统的状态，这其中便包括最核心的业务数据。站在数据库的视角，数据的流入包括两个部分，一个是业务系统的实时写入，这是核心数据来源的主要部分；另一个是从上游数据系统一次性或周期性导入的数据。因为这些核心数据在这里首次产生，所以这个数据库也被称为 SSOT（Single Source of Truth）。

SSOT 是后台系统中最重要的数据资产，那么随之便产生两个问题需要妥善处理。第一个问题是，作为最重要的资产，通常我们需要将这些数据实时同步到其他系统进行 BI 分析等进一步的处理，如果没有这样的实时同步机制，那么这份数据将成为数据孤岛。第二个问题是，这份数据可能因为各种原因遭到破坏，比如硬件故障或软件 Bug 导致的数据损坏、不当操作引起的数据损坏、错误 SQL 引起的数据错乱等，提供多种机制保障这份数据的安全显得非常必要。

全局 Binlog

PolarDB-X 是一款高度兼容 MySQL 生态的分布式数据库产品，所以我们首先来看下 MySQL 是如果解决数据孤岛问题的。

从 DB-Engines 排行榜可以看出，MySQL 的流行度比其他开源数据库的总和还要高，这意味着 MySQL 的生态非常繁荣，比如 MySQL 的下游系统有 Kafka、MySQL 备节点、Canal 多种数据同步工具、Pulsar 等等。MySQL 通过 Binlog 机制实现了与下游系统的实时增量数据同步。Binlog 可以看做是一个消息队列，队列中按顺序保存了 MySQL 中详细的增量变更信息，通过消费这个队列，下游系统或工具实现了与 MySQL 的实时数据同步，这样的机制也称为 CDC（Change Data Capture），即增量数据捕捉。

分布式数据库提供 CDC 能力相对于单机有更高的复杂度。一个分布式数据库通常包含多个节点，这些节点会产生多个增量日志队列，那么下游如果要消费多个队列会涉及几个问题。

因为是多个队列，那么下游消费时多个队列内变更事件的顺序如何确定？分布式事务的变更可能涉及多个队列，如果要保证消费时事务的完整性，那么如何发现并合并同一个事务的变更事件？系统发生了扩缩容（也就是队列的增减）下游如何正确处理？DDL 会涉及多个队列，下游如何精确识别出每个队列 Schema 变化前后的位置并协调好消费进度？

面对这些问题，分布式数据库的 CDC 能力需要在实现难度、支持特性、易用性等方面做 trade-off。通常来说，给下游提供多个队列、不保障事务完整性仅提供最终一致性、提供自定义格式的增量日志是一种较易实现的方案，但该方案会对下游消费提出更高的要求，比如要开发相应的消费代码或工具、需要考虑多个队列的协同问题等。一种体验更友好的方式是，通过提供与 MySQL Binlog 完全一致体验的 CDC 能力，让下游可以像消费 MySQL Binlog 一样透明的消费分布式数据库的增量变更，从而极大降低数据同步链路的搭建成本，这也是 PolarDB-X 2.0 采用的方案，我们称为全局 Binlog。

PolarDB-X 2.0 采用的是可水平扩展的 Share-Nothing 架构，系统基本组成单位是节点（即 Node），每个节点又可分为计算节点（即CN）和数据节点（即DN）两个部分。如上图所示，为提供全局 Binlog 能力，PolarDB-X 2.0 在此基础上增加了 CDC 组件，CDC 是一个具备弹性能力的集群。

全局 Binlog 的生成过程可分为三个阶段：

CDC 组件从每个 DN 拉取其增量日志，也就是物理 Binlog，之后进行单队列排序、内部事件过滤、DDL 相关的整形等操作，以便为下一阶段提供一个“干净”的增量事件队列，同时若系统发生了扩缩容，CDC 组件会在该阶段自动感知并做相关处理；CDC 组件将所有“干净”的增量事件队列进行合并，期间会对属于同一分布式事务的事件进行合并，并会根据事务时间戳进行全局排序，这样便得到一个全局有序的保障事务完整性的事件队列，同时该阶段还会处理好 DDL 在队列中的位置。之后 CDC 组件会将该队列生成兼容 MySQL Binlog 格式的文件，即全局 Binlog 文件；CN 组件在收到下游订阅全局 Binlog 请求后，会按照 MySQL DUMP 协议将全局 Binlog 发送给下游消费。

经过上面三个阶段，PolarDB-X 2.0 实现了完全兼容 MySQL Binlog 的全局 Binlog 能力。如果对详细的实现原理感兴趣，欢迎关注我们的知乎专栏《PolarDB-X 知乎专栏》。

备份恢复

对于数据损坏问题，PolarDB-X 2.0 提供不同粒度的数据恢复能力，包括实例级的一致性备份恢复能力、表级的表回收站能力、SQL 级的 SQL 闪回能力、行级的 Flashback Query 能力等。下面分别介绍这四项能力的特点和使用场景。

一致性备份恢复

首先来看下一致性备份恢复，该能力的特点是可以提供实例级任意时间点的历史数据恢复能力，这个时间点可以精确到秒级。单机数据库中，可以认为全量数据和增量日志都存储在一台机器上，实现一致性备份和恢复的话，只需要将全量数据和增量日志备份就好。分布式数据库中若要做到一致性备份恢复，因为全量数据和增量日志都存储在多台机器上的缘故，实现上会有额外的复杂度。PolarDB-X 2.0 中通过将所有 DN 做全量备份+全局 Binlog 的方式实现了一致性备份恢复能力。以上图为例，比如我们有一个 PolarDB-X 2.0 实例每周一、周二和周五的零点进行备份，某天产生一个需求，需要将数据恢复到周日的 14:25:26，那么我们的系统会选择离恢复点最近的一个全量备份集---- 也就是周五零点点这份，并从周五零点开始重放全局 Binlog，直到周日 14:25:26 结束，这样我们便得到了想要的快照。PolarDB-X 2.0 的一致性备份恢复能力备份期间不会锁库，该能力依赖全局 Binlog，也就是可恢复的区间是全局 Binlog 的保存区间。该能力目前有几个限制，比如备份期间不能进行扩缩容、仅支持同构恢复等。

表回收站

PolarDB-X 2.0 提供的第二项数据恢复能力叫做表回收站。顾名思义，我们会将 DROP 的表临时放入一个回收站，若两小时内发现需要恢复该表，那么可以在回收站中找回。表回收站提供了完整的管理功能，比如查看回收站中所有的表、彻底删除某张表、恢复某张表等。回收站目前仅缓存两小时内删除的表，并且不支持找回通过 TRUNCATE TABLE 删除的表。

SQL 闪回（即将上线）

PolarDB-X 2.0 提供的第三项数据恢复能力叫做 SQL 闪回。该能力可精确恢复一条误操作 SQL 影响的数据。PolarDB-X 1.0 中同样提供了该能力，上线以来，该能力帮助众多误删数据的用户找回了数据，是一项被广泛认可的数据恢复能力。下面我们以一个例子来介绍这项能力的具体使用过程。如上图所示，在 T1 时我们想把职位是 "Developer" 名字是 "Ralph" 的记录删掉，但 WHERE 条件中忘了加 "name='Ralph'" ，导致名字为 "Mary" 的记录被一同删掉了。这两个删除事件以及对应 SQL 的 ID 会被记录在全局 Binlog 中。T2 时，我们发现了误删问题，并通过 PolarDB-X 的审计功能找到了对应的 SQL 和 ID。T3 时，我们通过 SQL ID 和 SQL 闪回能力生成了恢复 SQL。SQL 闪回的原理是，在拿到 SQL ID 后，通过在全局 Binlog 中进行搜索，找到该 SQL 对应的所有变更事件（此处为两个删除事件），并逐个生成逆向恢复 SQL。T4 时，我们将恢复 SQL 执行后得到了被误删的两条数据。SQL 闪回针对 SQL 误操作场景可提供精确的数据恢复能力，可以看出，能够恢复的时间区间依赖于全局 Binlog 的保存区间。

Flashback Query（即将上线）

PolarDB-X 2.0 提供的第四项数据恢复能力叫做 Flashback Query。该能力可提供一定时间范围内行级的数据精确恢复能力。下面我们仍以 SQL 误操作场景为例。如上图所示，T1 时我们想把职位是 "Developer" 名字是 "Ralph" 的记录职位更新为 "CTO"，但 WHERE 条件中忘了加 "name='Ralph'"，导致所有职位是 "Developer" 的记录都被更新成了 "CTO"。这些变更都会记录在版本为 Vn+1 的 undo log 中（undo log 是数据库中的一个基础数据结构，里面详细的记录了每行数据的变更内容，可简单类比成 GIT commit log）。T2 时，我们马上发现了误改问题并确定了误操作时间和影响的数据范围。T3 时，我们通过 Flashback Query 能力直接查到了被影响的两行记录在 T1 时刻正确的值。T4 时，我们根据 Flashback Query 返回的正确值对数据进行了订正。可以看出，Flashback Query 能力依赖 undo log 的保存时长。与 SQL 闪回相比，该能力可提供更快速、精确到行级的恢复能力，但 undo log 通常不如全局 Binlog 保存的时间长，所以可恢复区间上弱于 SQL 闪回。

总结

PolarDB-X 2.0 针对数据孤岛问题提供了全局 Binlog 能力，该能力为下游生态提供了与 MySQL Binlog 完全一致的增量日志消费体验。针对数据损坏问题提供了实例级、表级、SQL 级和行级等不同粒度的数据恢复能力，包括一致性备份恢复、表回收站、SQL 闪回、Flashback Query 等。PolarDB-X 2.0 还在持续打造更多产品能力，敬请期待

本文为阿里云原创内容，未经允许不得转载。