Why You Should Never Rely Solely on Snapshots for vCenter Backup
I once managed a VMware cluster with 8 ESXi hosts for a financial project. During a vCenter (VCSA) upgrade from version 6.7 to 7.0, I carefully took a snapshot of the VM. However, the upgrade failed midway, causing severe database corruption. When I rolled back the snapshot, vCenter suddenly “went on strike” and couldn’t start services due to metadata inconsistency.
The hard-earned lesson is: Snapshots are not a true backup solution for vCenter.
Instead of saving a bulky virtual hard drive, VMware integrates a File-Based Backup feature within the VAMI interface. It focuses solely on backing up configuration files, the database, and identity parameters. When an incident occurs, you simply deploy a fresh vCenter instance and “pour” the data in. This process is extremely clean, avoiding residual errors from the old operating system.
Quick Start: Fast Configuration so You Can Get Home Early
If you’re in a hurry, here is a 5-minute roadmap to setting up an automated system:
- Access VAMI via:
https://<IP_vCenter>:5480. - Log in with the root account.
- Find the Backup section in the left menu.
- Click Configure to start the scheduling.
- Declare the storage server (SFTP/SMB/NFS), set an encryption password, and click Create.
Detailed Explanation: What You Need to Prepare
1. Choosing a Storage Protocol
vCenter supports several protocols such as FTPS, HTTPS, SFTP, FTP, NFS, and SMB. Based on many projects, I recommend prioritizing SFTP or SMB (Windows Share). They are both secure and easy to manage access permissions.
For example, if you use a Linux server as the backup destination, you need to grant write permissions to a dedicated user:
# Create directory and set permissions on the Linux server
sudo mkdir -p /mnt/vcenter_backups
sudo chown -R backupuser:backupgroup /mnt/vcenter_backups
2. Setting Up an Automated Schedule
Never trust your memory; let the machines handle it. In the configuration section, pay attention to the following:
- Backup location: For example,
sftp://192.168.1.50/backup/vcsa/. - Encryption: This is mandatory if you want to protect the passwords of your ESXi hosts. Warning: If you lose this encryption password, the backup becomes useless because it cannot be restored.
- Retention Policy: Typically, I keep the last 30 versions. In an environment with about 10 hosts, each backup is only around 2-4GB, which doesn’t consume much space.
Actual Steps in the Interface
Step 1: Declare the Storage Location
Suppose you use a Windows Server as the storage repository via the SMB protocol. The standard path would be: smb://192.168.1.100/vCenterBackup.
Step 2: Enter Parameters into VAMI
In the Backup -> Configure section, fill in the information as follows:
- Backup Location:
smb://192.168.1.100/vCenterBackup - User:
[email protected] - Schedule: It’s best to choose Daily at 01:00 AM to avoid impacting system performance.
- DB Health Check: Make sure to check this box. It ensures the database is error-free before backing up, though it adds about 5-10 minutes to the process.
Step 3: Test and Verify
Once the configuration is saved, don’t close your browser yet. Click Backup Now to run a test. When you see the status turn a solid green Complete, only then can you sleep soundly.
Recovery (Restore) Techniques When vCenter Fails
When vCenter “goes down,” you cannot use the web interface to restore it. In this case, the rescue process is as follows:
- Mount the vCenter installation ISO (VCSA Installer) on a computer in the network.
- Open the installation folder and run
installer.exe. - On the main screen, select the Restore button instead of Install.
- Point the path to the storage server (SFTP/SMB) where you stored the backup.
- Stage 1: The installer automatically creates a new vCenter VM with the exact hardware configuration as the old one.
- Stage 2: The system will pour the data from the backup into the new VM and activate the services.
Important Note: When restoring, you must select the correct Port Group or VLAN that the old vCenter used. If the network is incorrect, the installer will be unable to connect to the new VM to push the data, leading to an error in Stage 2.
Real-World Experience for Sysadmins
- Stay Away from VMware Storage: It sounds counterintuitive, but never store backup files on the same Datastore managed by that vCenter. If the SAN cluster dies, you lose both your vCenter and your lifeline.
- Monitor Capacity: If you choose to back up Stats, Events, and Tasks, the backup file will grow very quickly. If you don’t need detailed operation history, just select Inventory and Configuration to optimize speed.
- Password Management: Throw your encryption password into Bitwarden or LastPass immediately. I’ve seen colleagues forced to rebuild entire systems from scratch just because they forgot a single string of characters.
Setting up File-Based Backup is the first thing I do when deploying any VMware system. It’s like buying insurance. It might seem tedious during normal times, but when disaster strikes, it’s the only thing that keeps you calm and maintains your reputation with management.

