Just a few weeks ago, vSphere 7 saw the light of day. And people went crazy! New ESXi servers with vSphere 7 have sprung up like mushrooms. So many people directly upgraded their homelabs, or maybe even their production systems.
This blog post, I know the last post is some time ago, will show you how you can backup your vCenter Server Appliance with their integrated backup functionality, and also how you can restore it, in case something went wrong. Except for two ways, I went through all options for backup targets and tried to find out how to configure it. So there should be at least one way how you can back up your vCenter data to a proper location in your data center.
Why is it a good idea to back up your vCenter
vCenter is your management central in terms of virtualization. You manage all your ESXi server with it, your clusters, your data center networking maybe (with NSX), you’ve got some automation running, got your host profiles, storage policies, etc. in place there. Why lose all the stuff you’ve configured over a longer period, with maybe much tinkering, try and error? Backing up vCenter is not so hard. You need a backup target, a user and a password. In vCenter 6.7 you can even schedule the backup, which makes things even easier than before, where it wasn’t possible to configure a schedule.
Supported protocols for backup
vCenter supports the following protocols for backup:
This guide will show you how to configure all of the above protocols, except HTTP and HTTPS. I didn’t see a sense in setting up such a configuration in my lab, because it doesn’t seem to me as such backup targets would exist in a company either. I also think that these two protocols might be the slowest, compared to all the other protocols available. In data centers, no matter if on-premises or cloud, the often-used protocols are NFS and SMB. So chances are high that there might be already a suitable backup target for vCenter. Or it can be easily created. Also, FTP is still commonly used, and we’ve got also secure options with FTPS and SCP.
To be honest, the backup performance was not my top priority. I wanted to configure and test all supported protocols except HTTP and HTTPS. It’s clear that performance matters, at least to a certain degree. Backup windows might be small, or systems should not be impacted with a heavy load. Before we move on, I’d like to show you how the performance was during my tests.
I’ve set up a new vCenter server appliance for this backup and restore test. It is a tiny deployment with 2 CPU, 10GB memory and default disk size (thin). There is nothing configured within vCenter, no hosts, no clusters, nothing except backup. You can see that the amount of data transferred is the same in all tests. In regards to the duration, we’ve got the SMB protocol on the first place, followed by FTPS on the second, and NFS on the third place. Yes, I’m aware of “but there’s ftp:// and not ftps://”. I’ve configured FTPS as you can see later on the screenshots, but when I executed the backup job, it was logged as “ftp”. You can spot the difference at the port used for FTPS.