vCenter Server Backup Best Practices: A Complete Guide for VCSA 8.x and 9.x
If vCenter Server is down and you have no usable backup, you are not just missing a management console. You are missing your inventory, permissions, networking configuration and the control plane for the whole virtual environment.
The good news is that the vCenter Server Appliance (VCSA) has a built-in, supported backup tool. The harder part is using it well: choosing a safe destination, encrypting the data, keeping copies off site, watching for silent failures and, above all, proving you can restore. This guide collects the practices I recommend for VCSA 8.x and 9.x, based on Broadcom documentation and knowledge base articles, and explains the pitfalls that catch administrators out.
⚡ Quick Summary
- Use native file-based backup from the VAMI as your primary vCenter backup, on a daily schedule.
- Store it off the vCenter and off the cluster, over a secure protocol (SFTP, FTPS, HTTPS, SMB or NFS). Avoid plain FTP and HTTP.
- Encrypt the backup and keep the encryption password in a vault, because you need it to restore.
- Give every vCenter its own backup folder, and monitor that backups are actually completing.
- Back up before every change, keep an off-site or immutable copy, and test a restore at least twice a year.
What a vCenter backup includes
vCenter’s file-based backup captures the appliance’s core configuration and inventory, and can optionally include historical data such as statistics, events and tasks. When you start a backup you choose which data to include.
| Data set | What it is | Typical advice |
|---|---|---|
| Common (required) | Core configuration and inventory: the data needed to rebuild a working vCenter | Always included |
| Stats, events, tasks | Historical performance statistics, event and task records | Optional. It makes the backup larger and slower, so include it only if you need the history after a restore. |
File-based backup vs image-level backup
There are two ways administrators back up a VCSA. They solve slightly different problems.
| Approach | How it works | Strengths | Watch out for |
|---|---|---|---|
| Native file-based backup (VAMI) | vCenter streams its data to a remote server you define | Supported by VMware, small, schedulable, restores into a freshly deployed appliance | Restore needs the VCSA installer and a new appliance; takes some time |
| Image-level VM backup (snapshot/VADP tools) | Your backup software captures the whole VCSA virtual machine | Fast whole-VM recovery in familiar tools | Consistency and restore behaviour depend on the tool, and you cannot restore the VM if vCenter-dependent steps are broken. Treat it as a complement, not a replacement. |
My recommendation: make the native file-based backup your primary method, because it is the one Broadcom documents and supports for vCenter restore. If your organisation also uses image-level backup of the VCSA VM, keep it as a second layer, and test its restore too.
The 12 best practices
1. Schedule automatic daily backups
Do not rely on remembering to run a manual backup. Configure the scheduled backup in VAMI, and pick a quiet time. For busy or fast-changing environments, consider a more frequent schedule. A vCenter that is restored from a week-old backup comes back with a week-old picture of the world.
2. Store backups away from the thing you are protecting
Never put the only copy on the same host, datastore or cluster the vCenter runs on. Broadcom’s knowledge base notes you can point a backup at an ESXi host datastore over SFTP, but that is fine only for a quick one-off. If that host or storage fails, you lose both the vCenter and the backup.
3. Follow the 3-2-1 rule, and add an immutable copy
Keep at least three copies on two kinds of media with one off site. For ransomware resilience, copy backups to storage with immutability or an air gap, so an attacker who gets into your environment cannot also delete your recovery point.
4. Use a secure protocol
vCenter supports FTP, FTPS, HTTP, HTTPS, SFTP, NFS and SMB as backup targets. Broadcom’s documentation states that FTP and HTTP are not secure protocols. Prefer SFTP, FTPS, HTTPS or SMB with a hardened server. Note that mixing IPv4 and IPv6 between the vCenter and the backup server is unsupported.
5. Encrypt the backup and protect the password
Set an encryption password so the backup file is unreadable if someone copies it. If you encrypt, you must supply the same password to restore. Store it in your password vault, separately from the backup location, and record it in your disaster recovery runbook.
6. Use a dedicated, least-privilege backup account
Create a service account on the backup server that can write to one target folder and nothing else. Do not reuse administrator credentials. Rotate the password on a schedule, and update it in VAMI afterwards. A stale password is one of the most common reasons scheduled backups quietly fail.
7. Give each vCenter its own folder
The backup creates a folder named vCenter with timestamped subfolders at the location you specify, and Broadcom advises making sure no unrelated folder of that name already exists there. A Broadcom article also describes intermittent scheduled-backup failures on vCenter 8.0 Update 3i and later, and 9.x, when several vCenter Server appliances share the same backup target. Use a separate path per vCenter, for example /backups/vcenter-prod/ and /backups/vcenter-dr/, and read KB 435925 if you see “server validation failure” errors.
8. Choose sensible retention
VAMI lets you set how many backups to keep, and shows an estimate of the space they need. Keep enough local copies to cover a bad change discovered a few days later, then use your backup platform to retain monthly or pre-upgrade copies for longer. Only the configured number is retained on the target, so long-term retention needs a separate copy job.
9. Take a manual backup before every significant change
Before patching or upgrading vCenter, replacing certificates, changing identity sources or making large inventory changes, run Backup Now in VAMI. If you also take a VM snapshot, keep it short-lived and delete it once the change is verified.
10. Monitor backup success, do not assume it
Check the Activity view in VAMI, and verify on the backup server that new timestamped folders appear on schedule and have a sensible size. Add a simple alert for “no new backup in 36 hours”. A backup job that has been failing for three months is only discovered when you need it.
11. Document everything a restore depends on
The backup file is not the whole story. Record and store safely:
- The vCenter FQDN, IP address, subnet, gateway, DNS servers and NTP sources.
- The deployment size, vCenter version and build number.
- Root and SSO administrator credentials, and the backup encryption password.
- Any custom or CA-signed certificates and their chain.
- Identity sources such as Active Directory, plus license keys.
- Exports of key objects where relevant, such as distributed switch configurations.
12. Test restores regularly
An untested backup is only a hope. At least twice a year, restore into an isolated network to prove the files are usable, the encryption password works and your runbook is accurate. Record how long it took, so you know your real recovery time.
How to configure the backup in VAMI
- Prepare the backup server. Create a dedicated folder and a service account with write access, and confirm there is enough space.
- Sign in to VAMI at
https://<vcenter-fqdn>:5480as root or an administrator user. - Open Backup in the left menu and choose to configure a schedule (or Backup Now for a manual run).
- Enter the location in the form
protocol://server-address:port/folder/subfolder, then the backup server’s user name and password. - Set the schedule and time, then the number of backups to retain.
- Set an encryption password and choose whether to include stats, events and tasks.
- Save, run one backup now, then check Activity in VAMI and look at the files on the backup server.
# Example backup locations (protocol://server:port/path)
sftp://backup01.example.local/backups/vcenter-prod/
smb://filer01.example.local/vcenter-backups/prod
nfs://nas01.example.local/exports/vcenter/prodHow restore works (so you can plan for it)
File-based restore does not overwrite a running vCenter. You deploy a new VCSA from the installer and restore your backup data into it. At a high level:
- Download the VCSA installer ISO that matches the backed-up version, as described in Broadcom’s restore documentation.
- Start the installer and choose Restore.
- Provide the backup location and credentials, and the encryption password if you used one.
- Stage 1: deploy the new appliance with the network settings the restore needs.
- Stage 2: restore the data into the new appliance, then verify services and inventory.
- Validate hosts, clusters, networking, permissions and integrations before declaring success.
Common pitfalls and limitations
| Pitfall | What to do |
|---|---|
| Backup stored only on the same cluster or datastore | Move it to separate storage, and keep an off-site copy. |
| Using FTP or HTTP | Switch to SFTP, FTPS, HTTPS or SMB. Broadcom documents FTP and HTTP as insecure. |
| Lost encryption password | You cannot restore an encrypted backup without it. Keep it in a vault and in the runbook. |
| Scheduled backups fail silently | Monitor Activity and the backup server. Alert when no new backup appears. |
| Several vCenters write to one target folder | Use a separate folder per vCenter and review KB 435925 for 8.0 U3i or later and 9.x. |
| Expired backup-server password | Rotate credentials deliberately, and update them in VAMI at the same time. |
| Mixed IPv4 and IPv6 between vCenter and backup server | Use the same IP version on both sides. Mixed mode is unsupported. |
| Restoring from an old backup after changes | VM views in vCenter and ESXi can be out of sync after a restore. Newly registered or cloned VMs may appear missing or orphaned until vCenter rediscovers them. |
| vCenter High Availability (VCHA) in use | Broadcom notes restore requires VCHA to be reconfigured. Include this in your runbook. |
| vSAN environments | Restoring from a backup may cause inconsistencies in vSAN. Check Broadcom’s guidance before relying on a restore here. |
| Backup taken during in-flight operations | Avoid scheduling backups during large relocations or maintenance windows. |
Backup policy checklist
| Item | Recommended baseline (my suggestion) |
|---|---|
| Method | Native file-based backup via VAMI, plus optional image-level as a second layer |
| Frequency | Daily scheduled, plus manual before changes |
| Destination | Separate storage and failure domain from vCenter |
| Protocol | SFTP, FTPS, HTTPS or SMB (avoid FTP and HTTP) |
| Encryption | Enabled, password stored in a vault |
| Retention | Several recent copies locally, monthly and pre-upgrade copies off site |
| Copies | 3-2-1 with one immutable or offline copy |
| Monitoring | Alert if no new backup in 36 hours |
| Restore test | At least twice a year, in an isolated network |
| Runbook | Versions, IPs, FQDN, certificates, credentials and restore steps |
If you run VMware, Windows Server and hybrid infrastructure, more practical guides are on VMoreCloud.
Frequently asked questions
What is the best way to back up vCenter Server?
Use the built-in file-based backup in the VAMI on a daily schedule, send it to a separate server over a secure protocol, encrypt it, and keep an off-site copy. Test a restore regularly.
Which protocols can I use for vCenter backups?
FTP, FTPS, HTTP, HTTPS, SFTP, NFS and SMB. FTP and HTTP are not secure, so prefer SFTP, FTPS, HTTPS or SMB.
Does the vCenter backup include my virtual machines?
No. It protects vCenter’s own configuration, inventory and optional historical data. Virtual machines and datastores need a separate backup solution.
Do I need the encryption password to restore?
Yes. If you encrypt the backup, you must supply the same password during restore, so store it safely and separately from the backup.
How often should I test a vCenter restore?
At least twice a year, and after major version upgrades, using an isolated network so the restored appliance does not conflict with production.
Should I also back up the vCenter VM with my backup software?
It can be a useful second layer, but the native file-based backup is the method VMware documents for vCenter restore. Use image-level backup as a complement and test both.
Sources and further reading
- Broadcom TechDocs: File-Based Backup and Restore of a vCenter Server Environment (8.0)
- Broadcom KB 375278: Manually make a vCenter backup from VAMI
- Broadcom KB 435925: Scheduled file-based backups fail when multiple vCenters share a target
- VMware docs: Considerations and limitations for backup and restore
- Veeam Community: Do not back up the vCenter appliance with image-level backup alone, use file-based backup
This guide is based on Broadcom and VMware documentation and community articles available on October 26, 2026. Menu names, supported options and limits can change between vCenter releases, so check the documentation for your exact version. Retention and frequency recommendations are general guidance, not vendor requirements.
