WEBVTT 00:00:00.000 --> 00:00:04.640 Welcome back to vSphere 8 in the real world. Now we're going to discuss vCenter Server backup configuration. 00:00:07.760 --> 00:00:12.560 So backups are file-based, so they'll create a file that's going to push out when you 00:00:13.520 --> 00:00:17.040 configure your backup. It's going to back up basically the whole progress database that's 00:00:17.040 --> 00:00:22.000 going to be on the vCenter Server. It's going to get backed up and pushed to a share somewhere 00:00:22.000 --> 00:00:28.400 on your network, whether it be over NFS, SMB, NFS, or HTTPS. It's going to have to push it 00:00:28.400 --> 00:00:34.880 out of your network to some resource you've got configured there. So you can recover the 00:00:34.880 --> 00:00:40.639 vCenter Server, and then you would want to, obviously, you need to, once you've recovered it 00:00:40.639 --> 00:00:45.919 and rebuilt a new one, if you had to, you could restore this backup to it. You could also use, 00:00:45.919 --> 00:00:49.279 a little bit outside the scope of what's on the slides here, but you could also use a program 00:00:49.279 --> 00:00:55.439 like Veeam to backup the VM itself, and you could do a restore that way. That's very common as well. 00:00:55.439 --> 00:01:00.240 But if you want to just backup the configuration and not have to backup the whole VM, 00:01:00.240 --> 00:01:04.959 maybe you want to do that separately, you can also use the backup configuration component 00:01:05.599 --> 00:01:11.360 on the vCenter Server configuration screen to do that backup here. And again, you can schedule it, 00:01:11.360 --> 00:01:18.959 and you're going to have the HTTPS, HTTP, FTP, FTTPS, secure FTP, NSS, SMB, a lot of different 00:01:18.959 --> 00:01:23.839 options, obviously. If you can't use any of these, then you might have a deficit somewhere 00:01:23.839 --> 00:01:29.680 on your network. You need to look at patching. Very common is doing some kind of secure FTP, 00:01:29.680 --> 00:01:36.080 obviously. So, here's a showing that the first screen is just a generic. When you first open 00:01:36.080 --> 00:01:40.879 up the backup wizard, what are you going to see? And then you can say, okay, I want to back it up, 00:01:40.879 --> 00:01:47.680 and here they chose HTTPS, and you're going to give it the server's address and what location 00:01:47.680 --> 00:01:52.160 that server you want to back it up to, what credentials would you need to use to authenticate 00:01:52.160 --> 00:01:57.199 to that, what kind of schedule do you want. Here they're saying daily at a certain time every day. 00:01:57.199 --> 00:02:00.480 If you want to encrypt your backup, you can configure an encryption key. Obviously, 00:02:00.480 --> 00:02:04.080 you want to keep that somewhere safe. And then you have other options as far as, like, 00:02:04.080 --> 00:02:07.599 checking the health of the database and some different options there too, right? So, this is, 00:02:07.599 --> 00:02:12.960 you know, very simple, basic backup options. What do you want to back up and where are you 00:02:12.960 --> 00:02:20.320 going to back it up to and authentication for that? So, backup, what is backed up? The core 00:02:20.320 --> 00:02:24.960 configuration is going to be backed up, right? Meaning, you know, if you have things like 00:02:24.960 --> 00:02:29.520 distributed virtual switches configured, if you have data centers configured, if you have clusters 00:02:29.520 --> 00:02:35.039 configured, all that's going to be backed up. So, your inventory of all your hosts and all your VMs, 00:02:35.039 --> 00:02:39.440 all that inventory type of thing is going to be backed up. And historical data, off of that, 00:02:39.440 --> 00:02:43.839 it says your choice. So, basically, you can say how much historical data going back how far 00:02:43.839 --> 00:02:47.600 and what level of detail do you want to back up. Just like when you do your logging, 00:02:47.600 --> 00:02:51.839 you can see what level of logging you want to back up. Obviously, you can't back up more detail 00:02:51.839 --> 00:02:58.000 than what you have, what you've logged, okay? What's not backed up? Anything that, you know, 00:02:58.000 --> 00:03:01.119 kind of deleted libraries, anything that you removed from the inventory isn't going to be 00:03:01.119 --> 00:03:06.240 backed up. Linked clones. So, if you're using this machine, say, for example, for Horizon, 00:03:06.240 --> 00:03:11.600 you have linked clones configured on there, those aren't going to be backed up. But once you restore 00:03:11.600 --> 00:03:16.160 your configuration, a service like Horizon should go through and recreate those linked clones for 00:03:16.160 --> 00:03:22.720 you again. vCenter HA is going to have to be reconfigured. That configuration is also not 00:03:22.720 --> 00:03:31.039 backed up. So, some known issues. Cross vCenter migration of VMs fails with an error. So, 00:03:32.240 --> 00:03:40.080 if you're crossing vCenter servers, the new machine going over is going to obviously 00:03:40.080 --> 00:03:44.720 communicate between the vCenter servers. Sometimes the problem is firewall configurations can be an 00:03:44.720 --> 00:03:49.440 issue on there. So, you might need to check your firewall settings, check your network settings, 00:03:49.440 --> 00:03:53.839 make sure the hosts can communicate with each other that are on the different vCenter servers. 00:03:53.839 --> 00:03:56.880 So, it's going to be some, you know, basic troubleshooting network type of stuff that 00:03:56.880 --> 00:04:03.759 you have to look at. Moving VMs to storage on a different vCenter instance. So, if you're moving 00:04:03.759 --> 00:04:10.080 to different storage, right, what can sometimes happen is the host is going from, can't see the 00:04:10.080 --> 00:04:14.559 stores that you're trying to push it to, right? So, just again, the matter is making sure that 00:04:14.559 --> 00:04:20.079 when you're going across vCenter servers, not always, but oftentimes, they're pretty 00:04:20.079 --> 00:04:25.519 disseparate environments. And so, there might be, again, connectivity to storage issues. There might 00:04:25.519 --> 00:04:29.200 be firewall issues. There might be latency issues. There's a lot of things you'll need to look at to 00:04:29.200 --> 00:04:35.440 make sure that those cross vCenter migrations work. It used to be that they weren't even 00:04:35.440 --> 00:04:40.399 supported, but now they are supported. You can migrate a VM from a host in one vCenter server 00:04:40.399 --> 00:04:44.880 in one cluster to a host in a different vCenter server on a different cluster. That's pretty cool. 00:04:46.480 --> 00:04:52.239 So, linked SDDC. So, what that means is a software-defined data center. An SDDC is a 00:04:52.239 --> 00:04:58.239 software-defined data center. And vCenter is, you know, the vCenter environment is a software-defined 00:04:58.239 --> 00:05:04.720 data center, but so is a Azure environment. So, is a Google Cloud environment. So, is a AWS 00:05:04.720 --> 00:05:10.480 environment. Those are all different software-defined data centers. And vCenter is able 00:05:10.480 --> 00:05:19.200 to manage ESXi hosts in your software-defined data center on your property, on your prem that you own. 00:05:19.200 --> 00:05:25.920 So, your actual physical data center, as well as in an Azure environment or a colo somewhere or, 00:05:25.920 --> 00:05:33.200 you know, AWS. Both Azure, AWS, they sell VMware services. You know, the infrastructure, 00:05:33.200 --> 00:05:38.320 the servers and things like that that you can manage with your vCenter server that's in your 00:05:38.320 --> 00:05:44.959 environment. So, you can move VMs from servers that you own in your data center to servers that 00:05:44.959 --> 00:05:51.519 you are, you know, subscribing to from Azure, for example. And you can just move VMs over and move 00:05:51.519 --> 00:06:00.160 your workload into Azure using vCenter's native services. What can happen is if you have a vCenter 00:06:00.239 --> 00:06:05.519 cloud gateway. So, what a vCenter cloud gateway is, when you have a vCenter cloud gateway, 00:06:05.519 --> 00:06:10.720 you also always have a vCenter server on prem too. And the vCenter cloud gateway is going to 00:06:10.720 --> 00:06:19.440 connect your vCenter server up to your vSphere plus subscription in VMware's cloud, right? So, 00:06:19.440 --> 00:06:24.160 you can have a vCloud gateway linked to a software-defined data center. And what you're 00:06:24.160 --> 00:06:28.720 going to start seeing is you might actually see a vCenter server that is in your linked environment 00:06:28.720 --> 00:06:35.440 and one that's not. And the gateway between them, so why it shows up, is that vCenter cloud 00:06:35.440 --> 00:06:40.079 gateway, all right? So, a vCenter cloud gateway that's seeing multiple different vCenters will 00:06:40.079 --> 00:06:44.160 also make them start showing up in each other's environment when they're not actually linked, 00:06:44.160 --> 00:06:49.119 not being managed by each other. So, just realize that's not an expected behavior. It's not 00:06:49.119 --> 00:06:54.000 something VMware wants to happen. That'll probably be fixed here pretty soon in a later release. 00:06:54.000 --> 00:07:00.399 Maybe it will be by the time this video is out there. But you might see vCenter servers that are 00:07:00.399 --> 00:07:04.799 not linked as if they're linked in your vCenter servers. And it's because of your vCenter cloud 00:07:04.799 --> 00:07:08.480 gateway. It's because of your vSphere plus subscriptions infrastructure that makes that work. 00:07:11.279 --> 00:07:16.160 So, some best practices. vCenter server availability. So, you only want to access 00:07:16.160 --> 00:07:20.799 your vCenter server over a management network. So, hopefully you have a management network in 00:07:20.799 --> 00:07:25.040 your environment. This might be the network where you, you know, access and manage your switches, 00:07:25.040 --> 00:07:29.119 you know, management interfaces, or maybe you have an out-of-band management network for, you know, 00:07:29.119 --> 00:07:34.000 accessing your firewalls and things like that. You want to have an out-of-band management network 00:07:34.000 --> 00:07:39.519 for your vCenter servers as well, right? So, this would be something where you probably have to get 00:07:39.519 --> 00:07:44.000 routed to. It's through a firewall. Maybe you can't even access it that way. Maybe you have to access 00:07:44.000 --> 00:07:49.519 it through a jump box that's only on, you know, that network, something like that. So, you want 00:07:49.519 --> 00:07:54.799 to have a management network that's isolated from everything else. That's just, you know, security for, 00:07:54.799 --> 00:08:00.480 you know, ransomware and things like that. But also, you want the management network isolated 00:08:00.480 --> 00:08:06.000 from, for example, your vMotion network or from your, you know, iSCSI storage network, obviously, 00:08:06.000 --> 00:08:12.239 right? So, you'll have a dedicated network for accessing the vCenter servers management interfaces, 00:08:12.239 --> 00:08:18.880 okay, or management IP addresses is another way of looking at that. So, enforce role-based access 00:08:18.880 --> 00:08:23.839 control. Role-based access control is basically saying, it's like the rule of least privilege. You 00:08:23.839 --> 00:08:28.959 only want people to have privileges to do the one or two things they're going to do. Now, if someone 00:08:28.959 --> 00:08:34.080 does everything, then maybe you make them that administrator that can do everything. But if 00:08:34.080 --> 00:08:38.320 you've got a user that all they do is run backups, right? They're not even allowed to restore. They're 00:08:38.320 --> 00:08:43.280 only allowed to run backups. And then, if a restore is needed, you have another process you go through 00:08:43.280 --> 00:08:48.719 for doing restores. Don't give somebody the backup and restore access, as well as power on VMs, 00:08:48.719 --> 00:08:54.320 and power off VMs, and create VMs, and configure networking, if all they do is backup, all right? 00:08:54.320 --> 00:09:00.400 So, basically, the least amount of privilege a user has to have to do their job, that's the amount 00:09:00.400 --> 00:09:05.359 of privilege you want to give them. It's really common, unfortunately, where you see an environment 00:09:05.359 --> 00:09:11.280 where this guy, all he does in vCenter is he logs in and he, you know, verifies the backup ran or he 00:09:11.280 --> 00:09:16.400 verifies this and that. He doesn't do anything else. So, all he needs is read access to a small 00:09:16.400 --> 00:09:22.080 area of the network. I've seen situations where, yeah, we have these developers and we let them go 00:09:22.080 --> 00:09:27.280 ahead and create their own VMs and power on and power off their VMs, but only on these hosts right 00:09:27.280 --> 00:09:32.239 here, only with this storage. They only have access to this one network that's sandbox. They can't get 00:09:32.239 --> 00:09:38.960 to anything else. But they gave them privileges to everything and then told them to only go there. 00:09:38.960 --> 00:09:43.919 But they have privileges to everything. And then, what ends up happening is those developers try to 00:09:43.919 --> 00:09:49.359 be a nice guy. They try, you know, to be helpful. Oh, the server that I met my applications on is 00:09:49.359 --> 00:09:53.919 having some problems. Let me go in there and, you know, restart this or change that. And all of a 00:09:53.919 --> 00:09:59.599 sudden, they start messing things up being helpful, right? So, they shouldn't have had access to those 00:09:59.599 --> 00:10:04.080 servers. They should have only had access to the dev environment that they were supposed to work 00:10:04.080 --> 00:10:09.599 and play in and that was it. And somebody else managed the production VMs. So, role-based access 00:10:09.599 --> 00:10:15.440 control is a way of you just making sure that users only have access to the roles and responsibilities 00:10:15.440 --> 00:10:20.559 that they're supposed to be doing. That's what it comes down to. Configure NTP. NTP is an obvious one. 00:10:20.559 --> 00:10:26.159 One, it gets you, you know, can ensure access. If you clocked it too far out of sync, also, you 00:10:26.159 --> 00:10:31.599 can have difficulty logging into your host or into your vCenter because it'll think your 00:10:31.599 --> 00:10:37.039 packets are being spoofed or being retransmitted by somebody else trying to impersonate you. 00:10:37.119 --> 00:10:42.080 So, make sure that you have NTP configured so your clocks stay in sync so, you know, you don't lose 00:10:42.080 --> 00:10:47.280 access to your systems. Also, really important is it makes it much easier to read your log files. 00:10:47.280 --> 00:10:52.640 If you know your time is accurate on your host and on your vCenter server, you know your time stamps 00:10:52.640 --> 00:10:57.039 on your logs are also accurate. So, there's multiple reasons why. It makes it much easier 00:10:57.039 --> 00:11:04.159 to troubleshoot problems down the road. Enforce a lockout policy. You can do it via single sign-on. 00:11:04.159 --> 00:11:08.799 You can configure AD integration, right? And then whatever lockout policy you have in Active 00:11:08.799 --> 00:11:14.960 Directory will also kick in on your vCenter access. So, if users try to log into vCenter 00:11:14.960 --> 00:11:19.599 too many times unsuccessfully, their AD account gets locked. That account's locked. They can't 00:11:19.599 --> 00:11:26.320 access it, right? So, this is just some really common basic security best practices that really 00:11:26.320 --> 00:11:32.559 everyone should be following for like almost every aspect of their network. Now, let's go back to our 00:11:32.559 --> 00:11:37.039 vCenter environment and I'll show you how to do a vCenter backup. So, here we are back in our 00:11:37.039 --> 00:11:42.719 vCenter server management interface and down here at the bottom is our backup option. 00:11:45.039 --> 00:11:50.000 So, from here, I can go in and I can click configure and I can configure or schedule 00:11:50.000 --> 00:11:55.280 a backup to run and how I want the backup. So, I'll give it a backup location and remember, 00:11:55.280 --> 00:12:02.640 it can be quite a few different things. It can be HTTP, SCP, FTP, secure FTP. So, 00:12:02.640 --> 00:12:06.080 a bunch of different options you can configure for where you want to backup to. 00:12:06.080 --> 00:12:10.640 So, if we were going to do a secure FTP server, we would just say 00:12:14.880 --> 00:12:17.919 and then whatever directory we're going to be putting this in, 00:12:18.559 --> 00:12:20.400 whatever path you have there for that. 00:12:24.239 --> 00:12:28.559 If you have to authenticate with a secure FTP, you know, we would. We would have your username 00:12:29.599 --> 00:12:33.840 and then you put a password for whatever the password is for that. So, when do you want this 00:12:33.840 --> 00:12:40.000 to run, right? We can say we want to run daily, weekly, or some kind of custom policy. We could 00:12:40.000 --> 00:12:54.479 say every day, whoops, every day at, you know, at 10 a.m. Probably not, you know, in the middle 00:12:54.479 --> 00:12:57.919 of the day, 10 p.m. might be a better one. Just whatever works for you. If you're going to, you 00:12:57.919 --> 00:13:06.479 know, encrypt the backup, you want an encryption key here and then how many backups do you want 00:13:06.479 --> 00:13:10.159 to retain? You can say all backups, which means at some point you're probably going to yourself 00:13:10.159 --> 00:13:16.000 and start deleting the older backups. Or you can say retain the last, if we're backing up every day, 00:13:17.520 --> 00:13:22.799 maybe the last, I don't know, 15, the last two weeks. If I were to say backup weekly, 00:13:23.520 --> 00:13:29.039 every Sunday at 10 p.m., I might retain the last like four, like a month's worth is probably fine 00:13:29.039 --> 00:13:33.280 for vCenter. And hopefully this VM is being backed up some other way also like through 00:13:33.280 --> 00:13:39.440 Veeam or something like that. And then you can say what things do you want to back up? Do you 00:13:39.440 --> 00:13:43.520 want to back up staff, events, tasks, your inventory configuration, things like that, 00:13:43.520 --> 00:13:48.080 you know, probably yes. And then here it's telling you here how big that backup is going to be. 00:13:48.080 --> 00:13:54.960 Your inventory and configuration, 153 megs, and stats and events, that kind of stuff, all your 00:13:54.960 --> 00:14:00.159 statistical information, 63 megs. And then you can go in there and you say create, and that would 00:14:00.159 --> 00:14:06.159 create that to happen automatically to run every day or every Sunday at 10. Or you can go in there 00:14:06.159 --> 00:14:10.880 and say you want to just back up now, give it all the same information pretty much with the 00:14:10.880 --> 00:14:14.960 exception of you don't have to give a schedule, right? But we don't actually have backup target 00:14:14.960 --> 00:14:19.359 configured, so we aren't actually going to run one. But if you were, again, name, password, 00:14:19.359 --> 00:14:25.520 your encryption key to encrypt that, and you'd say start. So it's actually a really simple process, 00:14:25.520 --> 00:14:30.479 as you can see. This is a pretty cool handy little tool. It's something, you know, you might 00:14:30.479 --> 00:14:35.280 want to run in your environment. One of the best things to do would be, though, to definitely have 00:14:35.280 --> 00:14:39.119 your backup tool, whatever you're using to back up your vSphere environment, also back up your 00:14:39.119 --> 00:14:43.039 vCenter. And that way you have your retention policies and things like that all built into 00:14:43.039 --> 00:14:44.239 that backup software.