Most teams running VMware ESXi back up their virtual machines carefully. Far fewer back up the host itself. When a host fails or needs reinstalling, the virtual machine images can be restored, but someone still has to rebuild the networking, storage connections, users and settings that made those machines work. Without documentation, that rebuild can take far longer than the restore.
This guide covers what lives on the host, how to capture it, how to make VM backups restorable and how to make sure the whole environment can be brought back.
What Lives on the Host
An ESXi host carries configuration that no VM backup contains:
- Networking: virtual switches, port groups, VLAN IDs, uplink assignments and VMkernel interfaces for management, storage and migration traffic.
- Storage: datastore definitions, iSCSI or NFS connections and multipathing settings.
- Access: local users, roles, permissions and lockdown mode settings.
- System settings: NTP servers, DNS, syslog targets, advanced parameters and SSH status.
- Certificates and licenses: the host certificate and the license key in use.
- Hardware settings: BIOS options, firmware versions and RAID controller configuration that the hypervisor depends on.
Each item is small, but together they define how the host behaves. Missing one, such as a VLAN ID on a storage port group, can stop a restored VM from reaching its data. Hardware settings are often set once at installation and never written down, which is exactly why they belong on the list.
If the host is managed by vCenter, part of the configuration, such as distributed switches, lives in vCenter rather than on the host. In that case vCenter needs its own backup. The vCenter Server Appliance includes a file-based backup function that can send backups to a remote location on a schedule.
Export the Host Configuration
ESXi can export its configuration to a file that can later be applied to a reinstalled host of the same version. On many versions this is done from the command line with vim-cmd hostsvc/firmware/backup_config, which produces a download link for the configuration bundle. Procedures and supported restore scenarios differ between versions, so confirm the exact steps in Broadcom’s current documentation for your release and have the commands reviewed by the engineer who maintains the environment.
Store the exported file somewhere that does not depend on the host: an offsite storage service, a configuration repository or both. Export again after every significant change, and record the ESXi version and build number alongside each file, because a restore generally expects matching versions. Some teams also keep a plain-text record of key settings next to the export, such as switch names, VLAN IDs and IP addresses. It is readable without any tools and helps when a restore needs manual corrections.
Manual exports are easy to forget. Teams with several hosts often schedule the export with a small script run from a management machine, name each file after the host and date, and keep a limited number of older copies so that a bad change can be rolled back.
VM Backups That Actually Restore
Snapshots are not backups. They live on the same datastore as the VM and grow over time, which can fill the datastore and harm performance. Use a backup tool that creates independent copies, ideally with application-consistent options for databases, so that a restored database starts cleanly instead of needing repair.
Keep at least one copy outside the host and outside the data center. A backup stored on a datastore of the failed host does not help when that host is gone. Where the backup tool or storage supports it, make one copy immutable for a set period, so that ransomware or an accidental deletion cannot remove every restore point at once. Test restores should cover more than booting the VM: log in, check that applications start and that data is current, and note how long each step took.
Also check that the backup tool supports your ESXi version before upgrading the host, because an upgrade can break integrations that relied on older interfaces. Define retention in writing: how many daily, weekly and monthly restore points you keep, and how far back the business may need to go.
Document and Rehearse
Write a short recovery document and keep it with the backups. Store it where it can be read when the environment is down, for example as a printed copy and a file outside the virtualized infrastructure. The table below shows what it should track.
|
Item |
Where it is stored |
Last tested |
|
Host configuration export |
Offsite storage, with version noted |
Date of last restore test |
|
VM backups |
Backup repository outside the host |
Date of last test restore |
|
Network diagram and VLAN list |
Documentation repository |
Reviewed after each change |
|
License keys and support contracts |
Password manager or vault |
Checked at renewal |
|
Recovery steps |
Printed and digital copy |
Date of last rehearsal |
Rehearse once a year: reinstall ESXi on spare or temporary hardware, apply the configuration and restore one VM. The first rehearsal usually reveals a missing step. Time each stage of the rehearsal as well, because the total tells the business how long a real recovery would take and whether that is acceptable.
Consider the Hardware Side
If the host runs on VMware server hosting rented from a provider such as Unihost, part of recovery depends on that provider. Unihost lists IPMI access for its ESXi servers, which lets an administrator reinstall the hypervisor and reach the console remotely without waiting for data center staff. Ask any provider how quickly failed hardware is replaced and whether spare servers of the same model are available, because restoring onto different hardware can require driver changes. Out-of-band access deserves its own protection: use strong unique credentials for IPMI, restrict who can reach it and keep it off the public internet where the provider allows.
Licensing is a separate question: confirm with Broadcom or your reseller what your ESXi edition requires, rather than assuming it comes with the server. Record the answer in the recovery document, since license questions tend to surface at the worst possible moment.
A complete ESXi backup covers the virtual machines, the host configuration, the documentation and a tested recovery path. Capture the configuration after every change, keep copies away from the host and rehearse the rebuild before a real failure forces you to.