vCenter ESXi Config Backup Script

2024年7月7日 LOG admin

原文：vCenter ESXi Config Backup Script — theDXT (Daniel Keer)

When using VMware vCenter, you may only occasionally need a configuration backup of each VMware ESXi host. However, there are some situations where having a config backup of each ESXi host is nice to have.

I didn’t want to back up each ESXi host manually, as it doesn’t scale well. Instead, I created a PowerShell script called vCenter ESXi Config Backup to do everything for me.

You can find the script on my GitHub. https://github.com/thedxt/VMware#vcenter-esxi-config-backup

Prerequisites

VMware PowerCLI installed (here’s the Broadcom documentation on how to do that)
VMware vCenter certificate installed. My blog post, Install VMware vCenter Certificate in Windows, covers how to do this.

How It Works

The vCenter ESXi config backup script connects to VMware vCenter, uses vCenter to connect to each ESXi host, and takes a configuration backup for each host. Because the script uses vCenter, you don’t need to enable SSH on any of the ESXi hosts for the backup to work.

By default, the vCenter ESXi config backup script assumes you are not connected to vCenter and will prompt you to connect to vCenter. You can suppress this behavior if you are already connected to vCenter by setting the optional parameter named connected to the value of Yes.

The script checks to see if the backup folder you defined exists. If the folder does not exist, the script will create it.

Next, the vCenter ESXi config backup script enumerates all of the ESXi hosts in vCenter, it connects to each one and takes a configuration backup. The script outputs the backup into the folder you defined.

Once the backup is completed, the script renames the backup file to include the ESXi hostname, the ESXi installed version, the ESXi build number, and the backup date.

To use the script, you must provide it with a few parameters. The first parameter is vcenter, followed by the FQDN of your vCenter. The second parameter is folder, followed by the location where you want the ESXi config backups saved.

You will be prompted to log in to vCenter unless you suppress it with the optional parameter connected followed by the value of Yes.

Here’s an example of what the command should look like esxi-conf-backup -vcenter "vcenter.contoso.com" -folder "C:\ESXi-Backup"

Here’s the example output from that command.

vCenter Config Backup output

Here’s an example of what the command should look like if you are already connected to vCenteresxi-conf-backup -vcenter "vcenter.contoso.com" -folder "C:\ESXi-Backup" -connected Yes

Here’s the example output from that command.

vCenter Config Backup output when already connected to vCenter

If you ever need to restore the backup my blog post, ESXi Config Restore covers how to do that.

Why an ESXi Configuration Backup Matters

An ESXi host holds far more state than the virtual machines running on it: the host name and FQDN, the management network configuration, standard and distributed switch membership, port groups and VLAN IDs, NTP and DNS settings, local user accounts and the root password, SSH and ESXi Shell access policy, syslog targets, multipath and storage adapter claims, iSCSI and NFS datastore mounts, PCI passthrough mappings, and the license assignment. When a boot device fails, when a firmware update bricks a USB or SD-card installation, or when a change quietly breaks management access, rebuilding all of that by hand is slow and error-prone. A configuration backup is a small archive that restores the host to a known-good state in minutes instead of hours.

It also matters for compliance and change control. A dated snapshot of each host's configuration, stored off the host, records what the build looked like at a point in time. That is exactly what you need during an incident post-mortem or an upgrade plan, where the first question is always which ESXi build and which network configuration the host was actually running when things broke.

What an ESXi Configuration Backup Actually Contains

The ESXi configuration backup is a compressed archive produced by the host's own backup engine, the same mechanism used by vim-cmd hostsvc/firmware/backup_config. Inside you find the archived configuration database, the host's published certificates, and a manifest that records the release level, the build number and the host UUID. It deliberately excludes the virtual machine files themselves, so it is tiny - typically a few megabytes - and it is not a replacement for a virtual machine backup product. Think of it as the host's settings rather than the host's data.

ESXi only keeps a limited number of configuration backups in its own scratch area, and those copies live on the very host you are trying to protect. Exporting them to a central repository is what turns a convenience feature into a real disaster-recovery control, and that export is exactly what the PowerCLI script automates.

Installing PowerCLI and Preparing the Environment

The script is written in PowerShell and depends on VMware PowerCLI. Install it from the PowerShell Gallery, ideally on an administrative jump host rather than a workstation, and pin the module version so a future PowerCLI upgrade cannot change behaviour underneath you:

Install-Module -Name VMware.PowerCLI -Scope AllUsers -MinimumVersion 13.0
Import-Module VMware.PowerCLI
Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false
Set-PowerCLIConfiguration -DefaultVIServerMode Multiple -Confirm:$false

Two settings matter in practice. First, certificate validation: if you have not installed your vCenter certificate on the machine running the script, PowerCLI refuses to connect to a vCenter presenting an untrusted certificate, so either trust the issuing CA - the recommended route - or set InvalidCertificateAction deliberately after weighing the risk. Second, environments with more than one vCenter should set DefaultVIServerMode Multiple so the session can hold several connections at once. Keep the script in a folder on the module path, or dot-source it, so the esxi-conf-backup function is available when the job runs.

Script Parameters at a Glance

-vcenter - FQDN of the vCenter Server to connect to, for example vcenter.contoso.com.
-folder - local or UNC path where the exported configuration backups are written; the script creates it if it does not exist.
-connected - optional parameter set to Yes when you are already authenticated to vCenter, which suppresses the credential prompt and makes the script safe to run from a scheduler.

Because the script reaches each host through vCenter, no ESXi host needs SSH or the ESXi Shell enabled. The hosts stay hardened and you avoid leaving a remote shell open as a permanent attack surface, which is the main operational reason to prefer this approach over a per-host SSH loop.

Scheduling the Backup as a Recurring Job

Running the script by hand defeats the purpose. Register a scheduled task that invokes PowerShell, loads PowerCLI and calls the script with stored credentials, or better, run it under a service account that holds only read-only privileges at the vCenter level. A weekly cadence is usually enough for stable hosts, with an extra run after any change window:

$action  = New-ScheduledTaskAction -Execute "powershell.exe" `
  -Argument "-NoProfile -File C:\Scripts\Invoke-EsxiConfigBackup.ps1"
$trigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Sunday -At 2am
Register-ScheduledTask -TaskName "ESXi Config Backup" `
  -Action $action -Trigger $trigger -RunLevel Highest `
  -User "CONTOSO\svc-esxibackup"

Write the timestamped output into a folder that is itself backed up or replicated, so a single lost management server does not take your only copies with it. In a lab or a small site, pointing -folder at a network share or a sync folder is a cheap way to get a second copy off the box.

Verifying the Backup

After each run, confirm the expected files exist and that every archive is the right size and freshly stamped. A backup that silently stopped running a month ago is worse than no backup at all, because you believe you are covered:

Get-ChildItem "C:\ESXi-Backup" -Filter *.tgz |
  Sort-Object LastWriteTime -Descending |
  Select-Object Name, Length, LastWriteTime -First 10

The filenames the script produces are deliberately self-describing: they include the host name, the installed ESXi version, the build number and the date. That makes the folder usable as an inventory of what is running where and when each host was last captured, which is handy long before you ever need a restore.

Restoring an ESXi Configuration

Restoration is a console operation, not a PowerCLI one. Boot the host, press Shift+O at the boot prompt or use the host's recovery mode, and supply the URL of the backup archive. The host must be in maintenance or rebuild state, and after a restore you should confirm the build number matches what you captured, re-verify network and storage paths, and reattach the host to vCenter. A restore is also a convenient moment to move the host onto a newer ESXi build if the old one is the reason it failed.

Best Practices for ESXi Configuration Backups

Back up every host, not just production ones: lab and edge hosts are the machines whose rebuild steps nobody remembers.
Store copies off the host and off the management server, ideally in versioned object storage.
Record the ESXi build and the date in the filename so each archive documents itself.
Restore one host into a lab once a year to prove the procedure still works.
Keep the vCenter Server's own configuration backup enabled as well: it is a different file and protects against a different failure.
Re-run the backup after every firmware, driver or ESXi upgrade, and after any network redesign.

Together, the host configuration backup, the vCenter file-based backup and your virtual machine backup product cover three different failure domains. Treat the ESXi config export as the fast, cheap layer that returns a broken host to its exact prior state, and let the script produce it on schedule so it is never the task that gets skipped.