How to backup & restore VMware vCSA 8.0 Update 3

Imagine your vCenter Server Appliance (vCSA) suddenly goes down in the middle of a busy day. For any system administrator, this scenario is a nightmare. Backing up your vCSA configuration regularly and knowing how to restore it is critical for quick recovery.

VMware’s built-in File-Based Backup and Restore feature for vCSA (introduced in vSphere 6.5 and improved in 6.7 with scheduling) makes this process straightforward. In this guide, we’ll walk through how to back up and restore a vCSA 8.0 U3 environment step by step, share some pro tips and insights, and compare the native method to other backup approaches. The goal is to help you protect your vCenter configuration with confidence and minimize downtime if disaster strikes. Let’s dive in!

What Is vCSA Backup and Restore?

vCenter Server Appliance Backup and Restore is VMware’s native, file-based method for protecting the vCenter Server configuration and data. Instead of snapshotting the entire VM, the appliance’s configuration, vCenter database, inventory, and (optionally) historical data (like stats, events, tasks) are exported in a consistent state. The backup is not stored on the vCenter VM itself – it’s streamed to a remote storage location over your network using supported protocols (FTP, FTPS, HTTP, HTTPS, SFTP, NFS, or SMB). In other words, you designate an external repository (such as an SFTP server, an NFS share, or a network file server) and vCenter will package its data and send it there.

This file-based backup can later be used to deploy a fresh vCenter Appliance with the same settings and state captured at backup time. It’s essentially a built-in disaster-recovery tool. VMware and virtualization experts strongly recommend using this native backup method as the primary way to protect vCenter, because it ensures the vCenter application data is captured consistently (including the vCenter database) and is fully supported by VMware.

Key points about the built-in vCSA Backup:

• It captures vCenter-specific data: core configuration, inventory (the hierarchy of vSphere objects), and optionally performance metrics and tasks/events history. It does not include the ESXi host installations or VM disk files – those are outside vCenter’s database.
• Off-Appliance storage: Backups are sent over the network to a remote location (you specify a protocol and destination path). This means you need a file server or storage share accessible to vCenter to store backups. The backup is saved as an encrypted bundle (with a .enc extension) accompanied by a metadata JSON file.
• Multiple protocols supported: Common protocols like SFTP and SMB are popular choices. (Be mindful of security – FTP and HTTP are not encrypted and generally not recommended unless in an isolated network. If using HTTP/HTTPS, the web server must support WebDAV for it to work. For FTPS, only explicit mode is supported. Also, you cannot mix IPv4 and IPv6 between vCenter and the backup server – both sides must use the same IP version.)
• Use Cases: The file-based backup is useful not just for disaster recovery, but also for scenarios like migrating vCenter to a new host or VM (you can restore the backup onto a new appliance, even at a new location). It’s version-specific, though – a backup is only restoreable using the same vCenter version that created it, which we’ll discuss more under restore.

Overall, vCSA’s Backup and Restore gives you an easy, VMware-supported way to protect the “brain” of your vSphere environment. Next, we’ll see how to configure and use it in vCSA 8.0 U3.

How to Back Up vCSA 8.0 U3 (Step by Step)

vCenter 8.0 U3’s backup feature is accessed through the vCenter Server Appliance Management Interface (VAMI) – this is the special management UI on port 5480 of the appliance. To get started, open a web browser and log in to:

https://<vCSA-IP-or-FQDN>:5480

Log in as root (the root password for the appliance). On the VAMI home screen, look at the left-hand navigation menu and click “Backup”. You will see two sections on this page: Backup Now (for on-demand manual backups) and Configure (for setting up a scheduled backup job).

Backup Scheduling

Setting up a scheduled backup ensures vCenter is backed up regularly without manual intervention. To configure a schedule in vCSA 8.0 U3:

1. Open the Backup Scheduler: Click Configure on the Backup page. This opens the scheduling form.
2. Enter Backup Location: Provide the destination URL where backups will be stored. This uses the format protocol://server_address:port/path (for example, sftp://backupserver.domain.com:/vcsa-backups). Choose from the supported protocols (FTP, FTPS, HTTP, HTTPS, SFTP, NFS, or SMB) as the prefix. For example, an NFS share might use nfs://192.168.1.10/nfs_share/vcsa as the URL.
3. Enter Credentials: If the target requires authentication (most do, except NFS), enter the username and password that the vCenter should use to connect to the backup target.
4. Choose a Frequency: Select how often the backup should run. The options are:
   1. Daily – runs once every day at the specified time.
   2. Weekly – runs on specified days of the week at the set time.
   3. Custom – you can provide a cron-style schedule for advanced scenarios.
5. Encryption (Optional): You can set an encryption password for the backup. This will encrypt the backup archive file. Be sure to remember or securely store this password, because you will need it to restore an encrypted backup.
6. Retention Policy: Specify the Number of backups to retain. vCenter will automatically prune older backups, keeping only the specified number of the most recent backups. (For example, if you schedule daily backups and set retain=7, it will keep one week’s worth of backups.)
7. Data Options: Choose whether to include historical data (Stats, Events, and Tasks). Including these will make the backup larger and slower, but preserves performance metrics and event history which can be important for analytics or audits. The VAMI interface will show an estimated storage size needed based on this choice.
8. Finalize: Review your settings and click Create (or Schedule). Once saved, the schedule will be active. The Backup page will now show the scheduled job, and the next run time.

After configuring, vCSA will automatically perform backups at the specified times. Each successful backup will be listed in the Backup History on the VAMI page, including the date and a status.

How Backups Are Stored: On the remote backup destination, each backup is stored in a separate directory. The directory name typically includes:

• A prefix S (for scheduled backups) or M (for manual backups),
• The vCenter build version (e.g., 8.0.3 for 8.0 U3),
• A timestamp or date of the backup.

Inside each directory, you’ll find two key files:

• An encrypted archive file (with extension .enc) containing the backup data.
• A metadata JSON file (with extension .json) containing details about the backup (vCenter version, what’s included, etc.).

Backing Up Manually (On-Demand Backup)

Sometimes you may want to take an immediate backup – for example, before making a significant change to the environment. The Backup Now function lets you run a one-time backup on the spot:

1. In the VAMI Backup section, click Backup Now. This will open a dialog to perform a manual backup.
2. Location & Credentials: Enter the backup destination URL and credentials just like in the scheduling steps. If you have already configured a scheduled backup, you can tick an option to reuse those same settings (in vCSA 8.0, there’s typically a checkbox like “Use backup location and user from schedule” to auto-fill the last used location).
3. Encryption & Data: If desired, set an encryption password for this backup (you can use a different password each time or the same as your schedule – just remember it!). Choose whether to include Stats, Events, and Tasks data for this backup.
4. Description (Optional): You can add a text description for the backup (e.g., “Backup before applying patch on ESXi hosts”). This can help identify the purpose of backups in the history list.
5. Start Backup: Click Start (or OK) to begin the backup. You can monitor the progress in the VAMI interface – it will show a progress bar or status. Keep the browser open until it completes.

Once done, the new backup entry will appear in the Backup History list, labeled with an “M” (manual) prefix in its folder name on the destination. You can verify that the files (the .enc and .json) were created on your backup target.

Tip: Whether scheduled or manual, ensure your network connectivity between vCenter and the backup target is reliable. If you’re using SFTP or SMB, vCenter needs permission to write to that location. Firewalls should allow the connection. For example, VMware notes that backup servers should allow at least 10 simultaneous connections for the transfer to succeed (the appliance may multi-thread the upload). If a backup fails, check the VAMI backup logs (/var/log/vmware/applmgmt/) for details.

With backups in place, you have a safety net. Next, let’s look at how to restore vCenter from one of these backups if needed.

Restoring vCSA 8.0 U3 from a Backup

Restoring vCenter from a file-based backup is a two-stage process. Unlike restoring a simple file, you are essentially deploying a brand new vCenter Appliance using the backup data. VMware’s restore procedure uses the vCenter installer (ISO) to create a new appliance and then import the backup into it.

Important: You must use the exact same version of the vCenter installer as the version of the backup. For example, a backup taken from vCSA 8.0 Update 3 must be restored using an 8.0 Update 3 installer. Using a different version (even 8.0 U2 or U3a if not exactly matching) can lead to restore failures or inconsistent results. Always download the same build of vCenter that your backup came from.

Here’s how to perform the restore:

1. Obtain the vCenter Installer ISO: Download the vCenter Server Appliance installer ISO for 8.0 U3 (the same build number) from VMware’s portal. Mount this ISO on a machine from which you can run the installer (your PC or a jump server that has network access to the ESXi/vCenter where the new appliance will be deployed).
2. Launch Restore Wizard: Run the installer.exe (or installer on Mac/Linux) from the ISO and choose “Restore” from the menu. This kicks off a wizard similar to a fresh install, but it will prompt for backup information.

The restore wizard has two stages:

Stage 1: Deploy a New vCenter Appliance

This stage creates a brand new vCenter VM (appliance) in your infrastructure, with the same size/settings as the original, but initially blank (it will get data in stage 2).

Steps in Stage 1:

1. Connect to Backup: Provide the backup location URL and credentials so the installer can access your backup files. This is the same information you used when creating the backup. Once entered, click Next and the wizard will locate the backup set. It should display the backup date and vCenter version found.
2. Select Backup and Enter Password: Choose the specific backup from which to restore (if there are multiple in that folder). If the backup was encrypted, you’ll be prompted to enter the encryption password you set at backup time. The wizard will validate the backup’s integrity.
3. Deployment Target: Specify where to deploy the new vCenter appliance. You need to connect to an ESXi host or vCenter that will host this new VM. Provide the ESXi/vCenter address, administrative credentials, and the desired host or cluster and datastore for the appliance VM. (If your original vCenter was managing the environment, you can point the restore to an ESXi host directly to bypass needing vCenter up.)
4. VM Settings: Enter a name for the new vCenter VM (and optionally an inventory folder). This could be the same name as the old one, but be careful: if the original vCenter VM is still present (even if powered off), having two VMs with the same name or IP can cause conflicts. Ideally, you should power off or rename the old vCenter VM before proceeding if you plan to reuse the same name or IP. Also set a root password for the new appliance (it can be the same as the old one or different).
5. Deployment Size & Storage: Confirm the size of the appliance (Tiny, Small, etc.) and storage provisioning. Usually, this will match the original automatically (based on backup metadata). You can adjust if needed (for example, if you want to increase disk sizes, etc., though in most cases you deploy with the same specs).
6. Network Settings: Configure the network for the new appliance. Ideally, use the same network configuration (IP, subnet, gateway, etc.) that the old vCenter had if you intend for this restore to replace the original. This will allow all hosts and services to reconnect to it as if nothing changed. However, do not attempt to have two appliances running with the same IP! Make sure the old one is off or has a different IP. If you can’t turn off the old one yet, deploy the new one with a temporary IP, and plan to change it later or adjust DNS. (Using the same IP/DNS is simplest for restoration in most cases, to avoid reconfiguring any connected systems.)
7. Review and Finish Stage 1: The wizard will show a summary of the deployment settings. Double-check everything (especially that you picked the correct backup and the network settings). Then click Finish to start the deployment. The installer will now create the VM, upload the vCenter OVA, and power on the new appliance. This can take several minutes.

Once Stage 1 completes, you have a new vCenter appliance deployed and running, but it’s not functional yet – it’s an empty shell awaiting data. The wizard will now proceed to Stage

Stage 2: Restore Data from Backup

After the appliance deployment, Stage 2 will transfer the backed-up data into the new appliance to restore its state.

Steps in Stage 2:

1. Prepare for Data Transfer: The wizard will confirm that it can communicate with the newly deployed appliance (using the temporary network settings from Stage 1). If the backup was encrypted, you’ll need to enter the encryption password again to unlock the data.
2. Review Restore Details: It may show what will be restored (e.g. vCenter version, size, etc.). Simply proceed through the prompts.
3. Begin Restore: Click Finish or Restore to start the data transfer. The appliance will first be reset to a special “restore mode” and then import the backup data. Progress is displayed in the wizard. Note: Do not close the wizard or power off anything during this process. It can take some time, depending on the size of your vCenter database and network speed to the backup files.
4. Completion: When the restore is finished, the wizard will indicate success. The new vCenter appliance will reboot into normal operation with all your configuration and data restored to the point in time of the backup.

At this point, you have effectively cloned your old vCenter’s state into a new VM. The original vCenter appliance (if still around) is not automatically touched by this process – it remains intact and separate. This is by design, to allow a safe recovery without overwriting the original.

If you intend for the restored vCenter to replace the original, make sure the original is powered off to avoid IP or identity conflicts. Only one vCenter should be active on the network with the given identity at a time.

Now, let’s verify that everything is working on the new vCenter.

Post-Restore Validation

After restoring vCenter, don’t assume everything is 100% perfect without checking. It’s important to validate the environment to ensure the vCenter is fully operational and all components are in sync. Here’s a checklist for post-restore validation:

• Login and Interface Check: Log into the vSphere Client (UI) with your usual credentials and also access the VAMI (https://:5480) to ensure you can get into both. This confirms SSO and the appliance services are running.
• Host Connections: In the vSphere Client, check the status of all ESXi hosts. They should show as connected (not disconnected or in error). If any host is disconnected, try reconnecting it (you may need to re-enter host credentials). In most cases, if the new vCenter has the same network info and certificate, hosts will reconnect automatically.
• VM Inventory: Browse your VMs and Resource Pools – verify that all virtual machines, folders, and pools that existed at the time of the backup are present in the inventory. If some are missing or showing as orphaned, there might have been changes after the backup that need addressing.
• Networking (vDS): If you use vSphere Distributed Switches (vDS), ensure that your distributed switches and port groups are visible and hosts are connected to them. Important: The file-based backup does not capture changes to distributed switch configurations made after the backup. If any vDS changes (like new port groups or modifications) were done after the backup, those changes will be absent now. You may need to re-import a vDS configuration if you exported one, or manually re-create any changes that were lost. (It’s a good practice to export your vDS configuration periodically, especially before restores.)
• VM Operations: Try some basic operations in vCenter: power on a VM, vMotion a VM to another host, create a test snapshot, etc., to ensure the core functionality is intact.
• Permissions and Roles: Check that your user accounts, roles, and permissions are all in place. vCenter should have restored all the permission assignments that existed at backup time. Verify that any critical service accounts or domain integrations (e.g., LDAP/AD authentication) are working.
• Integrated Services: If you have other VMware or third-party integrations, now is the time to test them:
  • vSAN: If the vCenter manages a vSAN cluster, check the vSAN health status.
  • NSX or other networking integrations: Verify that the NSX Manager (if present) is showing as connected to vCenter and networking overlay configurations are fine.
  • VMware Horizon, vRealize, etc.: any other tool that hooks into vCenter should be checked to ensure they recognize the “new” vCenter. Usually, since the restored vCenter has the same GUID and certificates if done properly, other services shouldn’t need reconfiguration.
  • vCenter HA: If you were using vCenter High Availability (the active-passive vCenter clustering), note that you will likely need to reconfigure vCenter HA after a restore. The restored appliance is a single node; you’d have to set up the HA clustering again.
• Content Libraries: If you use Content Library, verify that all libraries and items are accessible. Like the vDS, changes to Content Libraries after the backup would not be reflected now. For example, if you deleted a library or item after the backup, the restored vCenter still thinks it should exist (but it won’t actually be present, and it may show an error until you remove the stale entry). Conversely, if you added new library items after the backup, those items won’t be listed in the restored library (though the files might still reside on the storage backing the library). You may need to re-sync or manually fix library content to reconcile any differences.
• Alarms and Events: Check the vCenter alarm definitions (they should be there) and see if any alarms are triggered that need attention. Also, review the Events to see if any errors were logged during the restore or after (e.g., host reconnect events, etc.).
• Logs: It’s good to review vCenter’s logs for any errors or warnings post-restore. You can do this from the VAMI (Monitoring > Logs) or by connecting to the appliance via SSH and checking /var/log/vmware/. Ensure there are no repetitive critical errors.

By methodically validating these areas, you can catch if anything didn’t come through correctly in the restore. In most cases, a file-based restore results in a very accurate clone of the original vCenter at the backup point in time.

Comparison with Other Backup Methods

You might wonder how vCSA’s built-in backup stacks up against other ways to back up vCenter. The common alternatives are image-based VM backups (using a tool like Veeam or snapshots) or manual configuration exports (scripting out vCenter settings). Let’s compare these approaches:

In summary, the built-in file-based backup is the recommended method for protecting vCenter because it’s comprehensive for vCenter’s state and officially supported by VMware. Image-based backups (using your enterprise backup software) can be a good additional safeguard – they protect against scenarios like total loss of the appliance VM or datacenter, and can be quicker for a complete restore, but you have to be cautious about consistency. Manual exports are generally not a standalone backup method, but rather a supplement (for example, exporting distributed switch config or documenting permissions as an extra reference).

For critical environments, you might implement more than one strategy (e.g., regular file-based backups plus occasional image-level backups) to cover all bases. Just ensure you have a plan to restore and practice that restoration process so there are no surprises.

Conclusion

vCSA 8.0 U3’s native Backup and Restore feature provides a robust safety net for your vCenter Server. By scheduling regular backups to a secure external location and knowing the restore procedure, you can dramatically reduce downtime in a failure scenario. The restore process doesn’t touch your original appliance – it deploys a new one with identical settings, which is great for avoiding additional risk. Just remember to retire or disconnect the old vCenter if you’re replacing it, especially if you need to reuse the same hostname or IP address on the new one to avoid network conflicts.

With a successful restore, your vCenter should come back fully functional, with all hosts and VMs just as they were at the backup point. Always perform the post-restore checks to verify everything (networking, cluster status, storage, etc.) is in order and no recent changes were lost unnoticed. If you use advanced features like distributed switches, content libraries, or vCenter HA, take into account the additional steps required to reapply those changes after a restore (export configs, reconfigure HA, etc.).