Welcome back to vSphere 8 in the real world. Now we're going to discuss vCenter Server backup configuration.
So backups are file-based, so they'll create a file that's going to push out when you
configure your backup. It's going to back up basically the whole progress database that's
going to be on the vCenter Server. It's going to get backed up and pushed to a share somewhere
on your network, whether it be over NFS, SMB, NFS, or HTTPS. It's going to have to push it
out of your network to some resource you've got configured there. So you can recover the
vCenter Server, and then you would want to, obviously, you need to, once you've recovered it
and rebuilt a new one, if you had to, you could restore this backup to it. You could also use,
a little bit outside the scope of what's on the slides here, but you could also use a program
like Veeam to backup the VM itself, and you could do a restore that way. That's very common as well.
But if you want to just backup the configuration and not have to backup the whole VM,
maybe you want to do that separately, you can also use the backup configuration component
on the vCenter Server configuration screen to do that backup here. And again, you can schedule it,
and you're going to have the HTTPS, HTTP, FTP, FTTPS, secure FTP, NSS, SMB, a lot of different
options, obviously. If you can't use any of these, then you might have a deficit somewhere
on your network. You need to look at patching. Very common is doing some kind of secure FTP,
obviously. So, here's a showing that the first screen is just a generic. When you first open
up the backup wizard, what are you going to see? And then you can say, okay, I want to back it up,
and here they chose HTTPS, and you're going to give it the server's address and what location
that server you want to back it up to, what credentials would you need to use to authenticate
to that, what kind of schedule do you want. Here they're saying daily at a certain time every day.
If you want to encrypt your backup, you can configure an encryption key. Obviously,
you want to keep that somewhere safe. And then you have other options as far as, like,
checking the health of the database and some different options there too, right? So, this is,
you know, very simple, basic backup options. What do you want to back up and where are you
going to back it up to and authentication for that? So, backup, what is backed up? The core
configuration is going to be backed up, right? Meaning, you know, if you have things like
distributed virtual switches configured, if you have data centers configured, if you have clusters
configured, all that's going to be backed up. So, your inventory of all your hosts and all your VMs,
all that inventory type of thing is going to be backed up. And historical data, off of that,
it says your choice. So, basically, you can say how much historical data going back how far
and what level of detail do you want to back up. Just like when you do your logging,
you can see what level of logging you want to back up. Obviously, you can't back up more detail
than what you have, what you've logged, okay? What's not backed up? Anything that, you know,
kind of deleted libraries, anything that you removed from the inventory isn't going to be
backed up. Linked clones. So, if you're using this machine, say, for example, for Horizon,
you have linked clones configured on there, those aren't going to be backed up. But once you restore
your configuration, a service like Horizon should go through and recreate those linked clones for
you again. vCenter HA is going to have to be reconfigured. That configuration is also not
backed up. So, some known issues. Cross vCenter migration of VMs fails with an error. So,
if you're crossing vCenter servers, the new machine going over is going to obviously
communicate between the vCenter servers. Sometimes the problem is firewall configurations can be an
issue on there. So, you might need to check your firewall settings, check your network settings,
make sure the hosts can communicate with each other that are on the different vCenter servers.
So, it's going to be some, you know, basic troubleshooting network type of stuff that
you have to look at. Moving VMs to storage on a different vCenter instance. So, if you're moving
to different storage, right, what can sometimes happen is the host is going from, can't see the
stores that you're trying to push it to, right? So, just again, the matter is making sure that
when you're going across vCenter servers, not always, but oftentimes, they're pretty
disseparate environments. And so, there might be, again, connectivity to storage issues. There might
be firewall issues. There might be latency issues. There's a lot of things you'll need to look at to
make sure that those cross vCenter migrations work. It used to be that they weren't even
supported, but now they are supported. You can migrate a VM from a host in one vCenter server
in one cluster to a host in a different vCenter server on a different cluster. That's pretty cool.
So, linked SDDC. So, what that means is a software-defined data center. An SDDC is a
software-defined data center. And vCenter is, you know, the vCenter environment is a software-defined
data center, but so is a Azure environment. So, is a Google Cloud environment. So, is a AWS
environment. Those are all different software-defined data centers. And vCenter is able
to manage ESXi hosts in your software-defined data center on your property, on your prem that you own.
So, your actual physical data center, as well as in an Azure environment or a colo somewhere or,
you know, AWS. Both Azure, AWS, they sell VMware services. You know, the infrastructure,
the servers and things like that that you can manage with your vCenter server that's in your
environment. So, you can move VMs from servers that you own in your data center to servers that
you are, you know, subscribing to from Azure, for example. And you can just move VMs over and move
your workload into Azure using vCenter's native services. What can happen is if you have a vCenter
cloud gateway. So, what a vCenter cloud gateway is, when you have a vCenter cloud gateway,
you also always have a vCenter server on prem too. And the vCenter cloud gateway is going to
connect your vCenter server up to your vSphere plus subscription in VMware's cloud, right? So,
you can have a vCloud gateway linked to a software-defined data center. And what you're
going to start seeing is you might actually see a vCenter server that is in your linked environment
and one that's not. And the gateway between them, so why it shows up, is that vCenter cloud
gateway, all right? So, a vCenter cloud gateway that's seeing multiple different vCenters will
also make them start showing up in each other's environment when they're not actually linked,
not being managed by each other. So, just realize that's not an expected behavior. It's not
something VMware wants to happen. That'll probably be fixed here pretty soon in a later release.
Maybe it will be by the time this video is out there. But you might see vCenter servers that are
not linked as if they're linked in your vCenter servers. And it's because of your vCenter cloud
gateway. It's because of your vSphere plus subscriptions infrastructure that makes that work.
So, some best practices. vCenter server availability. So, you only want to access
your vCenter server over a management network. So, hopefully you have a management network in
your environment. This might be the network where you, you know, access and manage your switches,
you know, management interfaces, or maybe you have an out-of-band management network for, you know,
accessing your firewalls and things like that. You want to have an out-of-band management network
for your vCenter servers as well, right? So, this would be something where you probably have to get
routed to. It's through a firewall. Maybe you can't even access it that way. Maybe you have to access
it through a jump box that's only on, you know, that network, something like that. So, you want
to have a management network that's isolated from everything else. That's just, you know, security for,
you know, ransomware and things like that. But also, you want the management network isolated
from, for example, your vMotion network or from your, you know, iSCSI storage network, obviously,
right? So, you'll have a dedicated network for accessing the vCenter servers management interfaces,
okay, or management IP addresses is another way of looking at that. So, enforce role-based access
control. Role-based access control is basically saying, it's like the rule of least privilege. You
only want people to have privileges to do the one or two things they're going to do. Now, if someone
does everything, then maybe you make them that administrator that can do everything. But if
you've got a user that all they do is run backups, right? They're not even allowed to restore. They're
only allowed to run backups. And then, if a restore is needed, you have another process you go through
for doing restores. Don't give somebody the backup and restore access, as well as power on VMs,
and power off VMs, and create VMs, and configure networking, if all they do is backup, all right?
So, basically, the least amount of privilege a user has to have to do their job, that's the amount
of privilege you want to give them. It's really common, unfortunately, where you see an environment
where this guy, all he does in vCenter is he logs in and he, you know, verifies the backup ran or he
verifies this and that. He doesn't do anything else. So, all he needs is read access to a small
area of the network. I've seen situations where, yeah, we have these developers and we let them go
ahead and create their own VMs and power on and power off their VMs, but only on these hosts right
here, only with this storage. They only have access to this one network that's sandbox. They can't get
to anything else. But they gave them privileges to everything and then told them to only go there.
But they have privileges to everything. And then, what ends up happening is those developers try to
be a nice guy. They try, you know, to be helpful. Oh, the server that I met my applications on is
having some problems. Let me go in there and, you know, restart this or change that. And all of a
sudden, they start messing things up being helpful, right? So, they shouldn't have had access to those
servers. They should have only had access to the dev environment that they were supposed to work
and play in and that was it. And somebody else managed the production VMs. So, role-based access
control is a way of you just making sure that users only have access to the roles and responsibilities
that they're supposed to be doing. That's what it comes down to. Configure NTP. NTP is an obvious one.
One, it gets you, you know, can ensure access. If you clocked it too far out of sync, also, you
can have difficulty logging into your host or into your vCenter because it'll think your
packets are being spoofed or being retransmitted by somebody else trying to impersonate you.
So, make sure that you have NTP configured so your clocks stay in sync so, you know, you don't lose
access to your systems. Also, really important is it makes it much easier to read your log files.
If you know your time is accurate on your host and on your vCenter server, you know your time stamps
on your logs are also accurate. So, there's multiple reasons why. It makes it much easier
to troubleshoot problems down the road. Enforce a lockout policy. You can do it via single sign-on.
You can configure AD integration, right? And then whatever lockout policy you have in Active
Directory will also kick in on your vCenter access. So, if users try to log into vCenter
too many times unsuccessfully, their AD account gets locked. That account's locked. They can't
access it, right? So, this is just some really common basic security best practices that really
everyone should be following for like almost every aspect of their network. Now, let's go back to our
vCenter environment and I'll show you how to do a vCenter backup. So, here we are back in our
vCenter server management interface and down here at the bottom is our backup option.
So, from here, I can go in and I can click configure and I can configure or schedule
a backup to run and how I want the backup. So, I'll give it a backup location and remember,
it can be quite a few different things. It can be HTTP, SCP, FTP, secure FTP. So,
a bunch of different options you can configure for where you want to backup to.
So, if we were going to do a secure FTP server, we would just say
and then whatever directory we're going to be putting this in,
whatever path you have there for that.
If you have to authenticate with a secure FTP, you know, we would. We would have your username
and then you put a password for whatever the password is for that. So, when do you want this
to run, right? We can say we want to run daily, weekly, or some kind of custom policy. We could
say every day, whoops, every day at, you know, at 10 a.m. Probably not, you know, in the middle
of the day, 10 p.m. might be a better one. Just whatever works for you. If you're going to, you
know, encrypt the backup, you want an encryption key here and then how many backups do you want
to retain? You can say all backups, which means at some point you're probably going to yourself
and start deleting the older backups. Or you can say retain the last, if we're backing up every day,
maybe the last, I don't know, 15, the last two weeks. If I were to say backup weekly,
every Sunday at 10 p.m., I might retain the last like four, like a month's worth is probably fine
for vCenter. And hopefully this VM is being backed up some other way also like through
Veeam or something like that. And then you can say what things do you want to back up? Do you
want to back up staff, events, tasks, your inventory configuration, things like that,
you know, probably yes. And then here it's telling you here how big that backup is going to be.
Your inventory and configuration, 153 megs, and stats and events, that kind of stuff, all your
statistical information, 63 megs. And then you can go in there and you say create, and that would
create that to happen automatically to run every day or every Sunday at 10. Or you can go in there
and say you want to just back up now, give it all the same information pretty much with the
exception of you don't have to give a schedule, right? But we don't actually have backup target
configured, so we aren't actually going to run one. But if you were, again, name, password,
your encryption key to encrypt that, and you'd say start. So it's actually a really simple process,
as you can see. This is a pretty cool handy little tool. It's something, you know, you might
want to run in your environment. One of the best things to do would be, though, to definitely have
your backup tool, whatever you're using to back up your vSphere environment, also back up your
vCenter. And that way you have your retention policies and things like that all built into
that backup software.