Most organizations focus on backing up virtual machines and their workloads, but the hypervisor itself is often left unprotected. Many administrators treat ESXi hosts as disposable: if one fails, just reinstall and reconfigure. In practice, manually recreating network settings, storage configurations, security policies, and user permissions can take hours. A configuration backup turns that into a few-minute restore.
This article covers the available methods for backing up and restoring VMware ESXi host configurations, how to automate the process, and the best practices worth following.
Why back up ESXi host configurations?
Reinstalling ESXi from scratch is easy. Rebuilding the configuration is not. A typical host carries dozens of settings that accumulate over time: virtual switches, port groups, storage adapters, multipathing policies, firewall rules, user accounts, SSL certificates, and advanced system settings. In clustered environments with High Availability, losing a node doesn’t affect running workloads, which makes it tempting to skip host-level backups entirely. But when it’s time to bring that node back, every setting needs to be recreated manually, and each step is an opportunity for human error.
Configuration backups solve three problems. They cut recovery time from hours to minutes by restoring a host to its exact previous state. They serve as living documentation of your current setup, which is useful for troubleshooting or replicating settings across multiple hosts. And they give you a safety net before upgrades or major changes: if something goes wrong, you roll back.
What about Host Profiles and Configuration Profiles?
VMware offers cluster-level tools for managing host configurations at scale. It’s worth understanding how they relate to the backup methods covered in this article.
Host Profiles (legacy) were introduced in vSphere 4.
They let you extract a configuration template from a reference ESXi host and apply it across a cluster, ensuring uniform network, storage, and security settings. Host Profiles require vCenter and an Enterprise Plus license.
Configuration Profiles are the modern replacement, introduced in vSphere 8.0 and generally available since 8.0 Update 1.
Instead of the old Host Profile interface, Configuration Profiles manage host configuration at the cluster level using a human-readable JSON document backed by a JSON schema. Starting with vSphere 8.0 Update 3, they also support baseline-managed clusters, so converting to image-based lifecycle management is no longer a prerequisite. However, some limitations remain: NSX-enabled clusters and DPU-equipped clusters are not yet supported, and once Configuration Profiles are activated on a cluster, they cannot be deactivated. Like Host Profiles, they require Enterprise Plus licensing.
The key distinction is purpose. Both Host Profiles and Configuration Profiles are fleet standardization tools: they ensure all hosts in a cluster match a desired state and let you remediate drift. The vim-cmd and PowerCLI backup methods covered in this article capture the exact point-in-time state of an individual host for disaster recovery purposes. These approaches are complementary, not interchangeable. Use Configuration Profiles (or Host Profiles in older environments) to keep your cluster consistent, and use configuration backups to protect against host-level failures and to enable fast recovery.
What’s inside the backup bundle?
The backup is a compressed .tgz archive, typically just a few hundred KB to a few MB, containing configuration files from the /etc directory and other critical system settings. This includes network configuration (virtual switches, port groups, VMkernel adapters), storage configuration (iSCSI targets, NFS mounts, multipathing policies), security settings (firewall rules, user accounts, SSL certificates), and advanced system settings. It does not include custom VIBs or third-party drivers, VM data, or VMFS datastore contents. If you rely on custom drivers or VIBs, you’ll need to track and reinstall those separately after a restore.
A note on vCenter-managed configurations
If your hosts are managed through vCenter, be aware that some configuration elements live at the vCenter level rather than on the individual host. Distributed virtual switches, for example, are vCenter objects. Backing up an ESXi host configuration captures the host’s local view (standard switches, VMkernel adapters, local users), but not the distributed switch configuration itself. Make sure your backup strategy accounts for both layers.
Using the ESXi host CLI to perform a backup
The ESXi command-line interface has built-in backup functionality. No additional software is required. The process creates a compressed archive containing all configuration files necessary to restore the host.
First, enable SSH access through the vSphere Client (Host > Actions > Services > Enable Secure Shell) or directly on the host console.
Once connected via SSH, sync the configuration files with persistent storage:
vim-cmd hostsvc/firmware/sync_config
Then run the backup command:
vim-cmd hostsvc/firmware/backup_config
This generates a URL for downloading the configuration bundle. The output looks like:
Bundle can be downloaded at : http://<host>/downloads/configBundle-esxi01.tgz
Open this URL in a browser, or use curl from another system:
curl -k -u root https://<host>/downloads/configBundle-esxi01.tgz -o esxi01-backup.tgz
Store the backup file outside the ESXi host itself, on network storage or a dedicated backup repository.
Automate backups using the host CLI
Manual backups get forgotten. Automating the process ensures consistent protection without relying on anyone’s memory.
The following example stores backups on a local datastore for simplicity. In production, you should copy backups off-host using SCP or a similar mechanism.
1. Create a script file:
vi /vmfs/volumes/datastore1/backup-config.sh
2. Add the following content:
#!/bin/sh
vim-cmd hostsvc/firmware/sync_config
vim-cmd hostsvc/firmware/backup_config
find /scratch/downloads/ -name \*.tgz -exec cp {} \
/vmfs/volumes/datastore1/ESXi_backup/ESXi_config_backup_$(date +'%Y%m%d_%H%M%S').tgz \;
3. Save and exit (:wq), then make the script executable:
chmod +x /vmfs/volumes/datastore1/backup-config.sh
4. Schedule the script using cron. Edit the cron configuration:
vi /var/spool/cron/crontabs/root
5. Add the following line to run the backup daily at 2 AM:
0 2 * * * /vmfs/volumes/datastore1/backup-config.sh
6. Save the changes and restart cron:
kill $(cat /var/run/crond.pid)
crond
7. Cron changes do not survive ESXi reboots. To make them persistent, add the following to /etc/rc.local.d/local.sh (before the exit 0 line):
/bin/echo "0 2 * * * /vmfs/volumes/datastore1/backup-config.sh" >> /var/spool/cron/crontabs/root /bin/kill $(cat /var/run/crond.pid) crond
8. Test the script before walking away:
/vmfs/volumes/datastore1/backup-config.sh
Verify that backup files are being created in the expected location and, if you added an SCP step, that the remote copy completed.
Restore a configuration from backup
Restoring requires the host to be in maintenance mode or freshly installed. The restore process overwrites all existing settings with those from the backup file.
Upload the backup bundle to the ESXi host using SCP or place it on an accessible datastore. Then enter maintenance mode (if the host is running):
vim-cmd hostsvc/maintenance_mode_enter
Run the restore:
vim-cmd hostsvc/firmware/restore_config /vmfs/volumes/datastore1/esxi01-backup.tgz
The host reboots automatically once the restore completes. After restart, all configurations from the backup are applied.
Important: The backup must come from the same ESXi version or a compatible build. Restoring from a mismatched version may fail or produce an unstable configuration. With vSphere 9.0 and its more frequent update cadence, matching the exact build number is increasingly important.
Important: Starting with VMware vSphere 7.0 Update 2, if a host uses a TPM for configuration encryption, you cannot restore configuration backups to a different physical host without the recovery key. Plan accordingly and keep your TPM recovery keys accessible.
Using remote CLI tools to perform a backup
Managing backups host-by-host doesn’t scale. Remote CLI tools let you back up multiple ESXi hosts from a single workstation.
Two options are available: vSphere CLI (vCLI), a Perl-based toolkit for Linux, and PowerCLI, a PowerShell-based toolkit primarily for Windows (also available on Linux/macOS). Both provide equivalent backup and restore functionality. Choose based on your OS and scripting preferences.
Back up using vSphere CLI
With the vCLI package installed on a Linux system, use vicfg-cfgbackup:
vicfg-cfgbackup --server esxi01.example.com --username root \ --password 'yourpassword' --backup --output /backups/esxi01-config.tgz
Note: If vicfg commands are unavailable in your version, consult the ESXCLI reference for alternative methods.
Back up using PowerCLI
PowerCLI uses the Get-VMHostFirmware cmdlet. Connect to the host or vCenter Server first:
Connect-VIServer -Server esxi01.example.com -User root -Password 'yourpassword' Get-VMHostFirmware -VMHost esxi01.example.com -BackupConfiguration -DestinationPath C:\Backups\
For environments with multiple hosts, loop through all of them:
Connect-VIServer -Server vcenter.example.com
Get-VMHost | ForEach-Object {
Get-VMHostFirmware -VMHost $_ -BackupConfiguration -DestinationPath "C:\Backups\$($_.Name)\"
}
Automate remote backups
When automating remote backups, follow these practices:
- For vSphere CLI, use credential stores or session files instead of hardcoding passwords in scripts.
- For PowerCLI, use New-VICredentialStoreItem or secure strings to avoid plaintext credentials.
- Make sure scripts are executable and schedule them using cron (Linux) or Task Scheduler (Windows).
- If running PowerShell scripts on Windows, you may need the -ExecutionPolicy Bypass flag.
Restore using remote CLI
The target ESXi host must be in maintenance mode or freshly installed.
Using vSphere CLI:
vicfg-cfgbackup --server esxi01.example.com --username root \ --password 'yourpassword' --restore --input /backups/esxi01-config.tgz
Using PowerCLI:
Connect-VIServer -Server esxi01.example.com -User root -Password 'yourpassword' Set-VMHost -VMHost esxi01.example.com -State Maintenance Set-VMHostFirmware -VMHost esxi01.example.com -Restore ` -SourcePath "C:\Backups\esxi01-20240115.tgz" -HostUser root -HostPassword 'yourpassword'
The host reboots automatically after the restore completes.
Best practices for ESXi host configuration backups
Back up regularly. At minimum, create configuration backups weekly. In dynamic environments, increase the frequency to daily or after every significant change. Automated, scheduled backups prevent the common scenario where administrators forget to back up before making critical changes.
- Store backups off-host.
Never keep backups solely on the ESXi host or on datastores that depend on it. Use network storage, a dedicated backup repository, or cloud storage. Follow the 3-2-1 rule: three copies, two different media types, one copy off-site.
- Implement a retention policy.
A common approach: retain daily backups for one week, weekly backups for one month, and monthly backups for one year. This gives you granular recovery options for recent changes while preserving long-term history.
- Use clear naming conventions.
Include the hostname, date, and ESXi version in backup filenames. For example: esxi01-v7.0U3-20240115.tgz. This makes it easy to find the right backup during a recovery.
- Test restores regularly.
A backup you’ve never restored from is a backup you can’t trust. Periodically test restores in a lab environment to verify integrity and to keep administrators familiar with the procedure. This also validates compatibility after ESXi version updates.
- Document your procedures.
Write down the specific commands, file locations, credential storage locations, and step-by-step restoration instructions. During a disaster recovery scenario, no one wants to be piecing together syntax from memory.
- Secure your backup files.
Configuration backups contain sensitive data: passwords, certificates, and network topology details. Restrict access to backup repositories and consider encrypting backups at rest and in transit.
- Plan for common failures.
Know what to do if the backup command produces no output, if the .tgz file is corrupt, or if a restore fails midway through. Having a fallback plan (even if it’s “reinstall and reconfigure manually”) documented in advance saves time during an incident.
Conclusion
ESXi host configuration backups turn a multi-hour rebuild into a quick restore. The methods available (host CLI, vSphere CLI, PowerCLI) all work well. The important thing is picking one, automating it, and testing your restores. A few minutes of setup now saves hours of recovery time later.
from StarWind Blog https://ift.tt/YaikDTJ
via IFTTT
No comments:
Post a Comment