CompTIA Network+ N10-008 – Module: Examining Best Practices for Network Administration Part 5

10. 16.9 Disaster Recovery

Disaster recovery refers to the ability to have a network and a group of servers up and operational. If some sort of a disaster occurs, maybe there’s an earthquake and it destroys an enterprise’s data center, or maybe there’s some sort of a fire or flooding. How do we restore when there’s some sort of a disaster like that? Well, one approach is to have backups of our data. So if the server containing the data go down, we’ve got backups that we can restore from.

And there are some different options for doing backup. And I want you to know about these different types of backups. First is a full backup. Maybe we’re backing up to tape or we’re backing up to maybe flash media. Maybe we’re backing up to the cloud, different targets for that backup. But a full backup is going to back up all of the data on, let’s say, a server. A differential backup is going to be smaller. It’s not going to take up as much storage space. It’s only going to back up data that changed since we did the full backup.

For example, let’s say that on Sunday night we do a full backup of a server. On Monday night, we do a differential backup. It’s only going to back up changes made since Sunday night just during that 24 hours period. That’s going to be a smaller amount of storage space. We’re not taking a full backup.

But while it’s quicker to do a differential backup and it takes up less space, when it comes time to do the restoration, it can take a bit longer because first you’ve got to restore the full backup and then you have to overlay that with the differential backup to pick up those changes. There’s another backup that could be even smaller than a differential backup, and it’s called an incremental backup that is going to back up data that has changed not just since the last full backup, but since the last full backup, or since the last differential backup, or since the last incremental backup.

For example, going back to our scenario of doing a full backup of a server on Sunday night and we do a differential backup on Monday night, if I do an incremental backup on Tuesday, it’s only going to back up data that changed since Monday night. If I do another incremental backup on Wednesday, it’s only going to back up the data I changed since Tuesday night. So it’s only backing up data that changed since the last backup of any kind. Now, let’s say I do a differential backup on Thursday. Well, that’s going to back up everything since Sunday night, since the last full backup.

Now, incremental backups, they’re going to take even less space, potentially than a differential backup, and they will take less time to perform because we’re backing up less data. But when it comes time to restore, it could take longer because we might have to restore the full backup then we have to restore the differential backup, and then we have to overlay that with perhaps multiple incremental backups.

And there’s another type of backup we oftentimes see in a virtualized environment. Maybe you’ve got something like VMware ESXi, and it’s running multiple virtual machines on that one physical server. Once you get a server installed, you get it licensed, you get everything configured just the way you want it. What you could do is take a snapshot of that server that’s virtualized, and that’s going to back up not just this file and this file, it’s going to back up the entire image of the server, including what’s in memory right now. So you’re not going to take a snapshot and say, I want to restore this one file, but if you want to restore to a previous state of when that snapshot was taken, you can do that. It’s going to back up the entire server, including what’s in memory. In other words, including state information. And now that we have our backups, let’s talk about some different disaster recovery sites.

And this is going to be a balancing act between how much money do you want to spend versus how quickly do you need to restore operation. Let’s say that we’ve got our main enterprise Data Center, and if something happens to this Enterprise Data Center, we might need to move operations to an alternate site. And I want you to know about the three different types of alternate sites we could select from. One is called a cold site. Now, at this cold site, we’ve identified the room where the servers are going to be installed. There’s already power ready to go. We just have to plug servers in. The challenge is we don’t have servers there yet.

We have to put servers in that room. The HVAC system is already installed, so everything is powered and there’s four space to put the equipment, but we don’t have the equipment there. We’re going to have to install the equipment. Then we’re going to have to restore from our backup media. It’s going to take some time to get a coal site up and operational, but obviously that’s going to be a less expensive option because we don’t have to buy duplicate server hardware until we need it. So we don’t have server hardware living in that coal site waiting to take over in case the Enterprise Data Center were to fail. If we want to recover a bit quicker than using a coal site, we could use a warm site now, like a coal site. Yes, it does have power. It does have an HVAC system.

There is floor space. But as a bonus, we now have server hardware. We don’t have to somehow acquire that and install it. It’s already there, ready to go. We just need to get our backup media and restore that to this existing server hardware and we are ready to go. But for some large enterprises, they cannot afford to be down even for a couple of hours, they might need something like a hot site. Now, this is what we had when I worked down at Walt Disney World in Florida. We had our main data center that ran the Disney World website. It ran the ABC website, massive data center. And it was in the building where I worked. But there was a fiber connection from the building where I worked to the tunnel system underneath the Magic Kingdom called the Util Doors. In the utility doors, there was a smaller data center and there was another computer there.

And anytime a change was made to the computer in the big data center, that change was written over the fiber optic media. It was written to that backup server in the tunnels underneath the Magic Kingdom. That’s a hot site. So a hot site, yes, it does have power. It does have an HVAC system in place. There is forcepace, there is server hardware. But here’s the bonus we get that we don’t have with a warm site, we don’t have to restore from backup because when a change is made in the Enterprise Data Center, it’s automatically synchronized with the hot site. So if the Enterprise Data Center goes down, we can be up and operational almost immediately. That’s going to cost more money, but it’s going to give us the quickest restoration time. And as we prepare to wrap up this discussion of disaster recovery, there are a few terms I’d like you to know. One is an SLA, a service level agreement. If you have customers that you need to provide disaster recovery services for, this is your promise to them. You’re saying to them, we guarantee you as part of this agreement, you’re going to be up, let’s say, 99. 9% of the time. And if we do go down for some reason, here is the maximum amount of time that you should be offline. If there is a disaster, that’s called the RTO, the recovery time objective. And if we don’t have a hot site and we’re not doing synchronization, we might lose some data since the last backup was taken.

So as part of that service level agreement, we also specify what is called the recovery point objective or the RPO that defines the maximum amount of data loss that might happen when a disaster occurs. So if you’re doing incremental backups nightly, you might say that you could lose one day’s worth of data. And if that’s not acceptable to the customer, you may want to do incremental backups more often. A couple of other terms for you, MTBF is the mean time between failure when you’re purchasing equipment.

Oftentimes higher end gear is going to give you the mean time between failures. This is going to be a statistical average of how long this system is going to run before it’s somewhat likely to break down. And hardware that has lower mean time between failures might be less expensive. But you’ve got to weigh that with the fact that it’s more likely to go down. And if equipment does go down, you want to know the meantime to repair. And that’s a look at disaster recovery, where we talked about options for performing backups. We talked about the full backup, the differential backup, the incremental backup. We talked about taking a snapshot, and we talked about different sites we could use in disaster recovery. We had a cold site, a warm site, and a hot site. And then we defined some disaster recovery terms.

11. 16.10 Standards, Policies, and Rules

We might have lots of moving parts within a company and lots of employees. And each employee, they may have their own idea about how things need to be done. And that’s not going to work very well. We’re going to have conflicting viewpoints, and as a result, we can have a breach of security. Security curry we can have things left undone. So a company needs to have a collection of documentation, a collection of standards and policies and rules. And that’s what we’re going to be discussing in this video. We’re going to be taking taking a look at a collection of common standards, policies, and rules. The first is a privileged user agreement. This is where we dictate what level of access that a particular user has. Maybe the manager of a department has one level of access.

They’re the admin user on all of the servers and they’re a regular user on other servers. We might say that based on the position that a person has, that’s going to grant them a certain level of access within the corporation. Or we might define different user groups and give a set of privileges to a group and then put appropriate users in that group. Maybe we have a group of users that all work on a help desk. Well, they can all belong to a group, and they could have the same level of permission to access network resources. Maybe there’s another group for network administrators, another group for network engineers. They each have their own unique sets of permissions, and those permissions are detailed in what’s called a privileged User Agreement. And I’m just going to make a list of these terms as we go through them over here on the right hand side of the screen. And this might be a good opportunity to use Flashcards to go back and review these. Copia says, you need to know these terms, and I want you to know just a brief definition of each of these. The next item is a password policy. I’m sure you’ve seen times when you’re setting up a password and you’re given a set of restrictions. It has to be a certain length at a minimum. Maybe you have to have a mixture of upper and lowercase characters. Maybe it has to have a special character or number.

And a common joke about that is somebody had a really long password. It was the name of all of the seven dwarves from Snow White and then the word Sacramento. And they were asked, what is up with that password? Why is it so long? And they said, Well, I was supposed to create a password with seven characters and a capital. All right, moving right along. The next one is onboarding and off boarding procedures. When we get new employees, we want to give them access to resources, and they should be able to have access to those resources as quickly as possible so they can start doing their job.

Similarly, when somebody leaves the company, we don’t want them to have access after they walk out the doors for the final time. So we need some sort of procedure in place along with all of the other HR things that have to be done when somebody is being hired or when they’re exiting a company. As part of those procedures, we should have procedures for setting up and deleting accounts. Next up on our list of standards, policies, and rules is licensing restrictions.

This might say how a particular license can be used. Maybe we buy a license for a router, but there’s a restriction that says this can only be used on one router. What if we have five routers? Well, we need to buy five licenses. We want to make sure that we’re legal on all of the software and firmware that we’re using. Next up on the list is international export controls. Maybe there is a restriction that a piece of software cannot be exported to another company, oftentimes here in the US. If I’m looking at a Cisco router, there will be an international export control message that’s on the screen, and it explains that the particular version of the router operating system that I’m using cannot be exported to another company because of the encryption standard that’s being used.

I think it uses something like AES 256, and there’s a restriction not to export that to other countries. Next up is data loss Prevention, often written as a DLP, a data loss Prevention policy. This is a policy that is trying to prevent a company’s sensitive information from being shared outside of the company. And we want to follow these procedures so somebody doesn’t inadvertently release information like financial data that should not be released or employees Social Security numbers. We don’t want that released to the outside world. Next up is remote policies. What are permissible ways for remote users to access the corporate network, if any? For example, we need a network administrator to work on this router, but they’re at home today. Maybe they need to connect remotely.

And as part of this policy, we might say, you’re not allowed to use telnet because that is not secure. The passwords are in clear text, but we will allow them, as an example, to connect from home using secure shell, because that is a secure protocol. That’s an example of what you might find in a remote access policy. Next up is incident response policies. If a major event happens in the network, like a server goes down or a router goes down, or we lose a hard drive, what do we do in response to that? We can respond a lot more calmly and effectively if we have a procedure in place.

And an incident response policy might say, what do we do in the event of such an incident? There might be the incident of an Internet connection going down. It might list a series of steps that we should go through to respond to that. Maybe in response to that, somebody needs to contact the Internet Service Provider. While somebody else is installing a static route in a router to redirect traffic temporarily over a backup route, there could be a set of procedures that get followed if a particular incident occurs. Something else that we’re seeing a lot today is people bringing in their own devices from home. They have these smartphones tablets. They want to bring them to work and use them as part of their job. We often hear this referred to as BYOD bring your own device. And there needs to be a policy regarding what sort of devices are allowed on the corporate network.

If a device does not support a certain level of security, then maybe it’s not going to be allowed to connect to the corporate network. Or maybe somebody brings in their smartphone and while it’s allowed to connect to the corporate network, is it really the responsibility of the company’s It staff to support that device? After all, they didn’t tell you to buy that device. You just bought it because you thought it was really cool. So do they really have to support it?

Well, maybe not. That’s the purpose of the BYOD policy. It tells you what level of support your own device is going to get from the corporate It team and if it’s even allowed to join the network. Another policy that is very common is an Acceptable Use policy or an AUP. This says what it’s considered to be, as the name suggests, an acceptable use of corporate resources. If I were to go into a company as an employee and maybe set up my own web server and host my own ecommerce business and start selling things through that corporate server, and I use that as sort of my own private data center for my company, maybe that’s not an acceptable use of corporate resources.

Those are the types of things outlined in an Acceptable Use policy. It might say that employees are permitted to check into their Facebook account, or maybe it says they’re not allowed to log into Facebook on a corporate computer. Those are the types of things we might find in an AUP an Acceptable Use policy. Here’s another acronym for you. An NDA. A nondisclosure agreement. This is a legally binding document. We need to be careful with these. If you sign an NDA, understand what you’re signing, what exactly are you promising not to disclose? This might be where a company is having you sign something, where you’re promising not to give out their corporate secrets to the world. If you have your own personal blog, you shouldn’t say, hey, this company I’m working for, in a couple of months we’re going to come out with this really cool product.

If it’s not been publicly announced, you might not be allowed to do that kind of thing. And a really famous example of somebody violating an NDA happened just before apple’s iPhone X came out. You might have heard about that on the news. There was a wireless engineer that worked for Apple and he had a pre released version of the iPhone X. And his wife and his daughter, they came in to join him for lunch at the Apple Cafe and his daughter did a Vlog a video blog and she’s sitting there and she’s videoing the iPhone ten and she’s doing that before it is officially released. Now it had been released at this point, but it wasn’t yet available for sale. And because she did that, Apple found him to be in violation of his NDA and he was terminated because of that. Another example of an NDA is when you go take your Network Plus exam from CompTIA, they’re probably going to ask you to not share the questions that you’re presented with. You’re not going to be able to share those with anyone. Those are secrets. Next up, we have the system lifecycle, and this could apply to various pieces of hardware. And this describes, I guess we could say, the different stages of life for a piece of hardware. Everything from when we’re initially planning to purchase a piece of hardware to meet a particular need, to the purchase process, to the installation process, to maintaining it and using it and then disposing of it at the end of its life cycle.

There could be details for each of those different phases and those were just some examples of typical phases in a system lifecycle. Some lifecycles are much more detailed. For each defined phase, there could be a set of procedures about how do we purchase the equipment or how do we dispose of this equipment. Next, we have some safety procedures and policies. These are guidelines for conduct that hopefully will make our network environment a safer place to work.

And the specific policies that might apply to you, they can vary widely depending on what you do. Are you working with chemicals? Are you working with electricity? There could be very occupational specific policies and rules for you. And here is the overview of the list of policies and rules and standards that CompTIA has identified that you need to know for their Network Plus exam. My recommendation is to make a series of flashcards, one flashcard for each of these terms. And on the back, just jot down a quick definition for what that term means and review that as part of your Network Plus exam studies.

• Category: Uncategorized