Virtualization is becoming ubiquitous today as more and more companies realize the benefits of Hyper-V. But as a line of business apps and mission-critical functions are moved from physical hosts to virtual ones, the idea of using “snapshots” to take backups of VMs is simply not enough. They don’t scale, can be confusing to work with, and consume resources much better left for running the production VMs. In this article, we’re going to look at what you want to do to provide a scalable and performant backup solution for your Hyper-V virtual machines running on Microsoft Windows Server 2012, 2012 R2, 2016, and 2019 hosts.

Why Backing Up VMs is Different

It’s important to understand that, while a virtual disk is, at least to the host operating system, a single big file, it’s definitely not just a single big file. Even a simple VM with a single disk for everything has an image of a system volume, with the full directory structure you’d find on any system, along with supporting files for the image, changes, et al. More advanced VMs may also include other image files on other storage arrays to handle databases, or log files, or to host the applications that the VM runs. All of these are likely to be in a constant state of reading and write while the VM is running. When a virtual machine is shut down, you can treat that data like a handful of really big files, but who wants to shut down mission-critical servers every night so you can make a backup? Anybody?

In addition to all the changes going on within the VM’s file systems, which are all reads and writes to that big file, there’s the memory image being written to the swap file of the VM, which is again a bunch of changes being written to that one big file. Trying to “grab” an image of a file that is in an almost constant state of change is what makes backing up VMs so different from backing up files. A file system can be held off from committing a change to disk when a backup application puts a lock on a file to capture it to back up in a second or two, but you cannot do that when you’re trying to back up a virtual disk that may take several minutes to complete. That virtual machine is wanting to write multiple changes per second and cannot just stop when it’s running. And you can’t shut down VMs each night just so you can do backups. If you have multiple machines behind a load balancer, you can take one at a time out of rotation to back things up, but that increases complexity, reduces performance, and risks fault tolerance.

There’s also the method to consider. Physical device backups require software to be running on the host machine or access to the host’s storage over a network share. Running the software on the host may be okay in smaller environments but is not advisable. You want to preserve as much as possible of the host’s resources as you can for the VMs to use. Agent-based backups use a small software service to run on the VM host, while the heavy lifting of the backup application handling things like compression, encryption, deduplication, and the actual jobs of backing up VMs is handled by a server separate from your VM hosts.

Choosing the right application

There are several applications on the market that can do backups of virtual machines, but not all have all of the key features you want to have to protect your mission-critical systems. Here is the shortlist of must-have features you need to have in order to get the best performance and protection for your VMs in the most cost-effective way you can.

• Live backups
  Make sure your backup solution can do backups while the VM is running. Not shut down, not paused, not taken out of the load balancer rotation. Backups should help protect you, not slow you down. Live backups mean you can back up when you want without dropping capacity or staying up late at night.
• Continuous Data Backups
  How many changes a day do your VMs process? 10? 1000? 1M? How much work would it take to bring a machine and its config back to “current” if you had to start from a backup taken last night? Continuous Data Backup lets you backup your VMs throughout the day-as frequently as every five minutes if that’s what you need. That’s a pretty good RPO.
• Deduplication
  Backing up multiple times a day is great for RPO but will need a LOT of storage space to do. Save space by choosing a backup solution that can do deduplication and make sure it can do it inline, not after the fact.
• Automatic Retention Policies                                                                                                                                                                                  Further help keep your storage use in line by choosing a solution that handles retention policies automatically. You don’t have time to go through and dump old backups. Your solution should do that for you.
• Historical Point-in-Time Options                                                                                                                                                                          There are benefits to keeping some older backups for recovery, analysis, and other just-in-case scenarios. Systems that can take and keep yearly or quarterly or monthly or weekly backups so you have a historical point you can go back to is invaluable. Frequently called a “Grandfather-father-son” rotation scheme, make sure your solution can take care of this for you.
• Concurrency
  Even with fast backups that can run while the VMs are live, you don’t have time to do backups serially. Unfortunately, some solutions can only do one VM at a time. Make sure the one you choose offers concurrency so you can back up multiple machines all at once.
• Options options options
  You want options on where your backups go. Disk to disk is okay but can be costly, and if they are all in the same place, a site disaster means you’re toast. Over the wire to an offsite location is much safer, but of course, it requires that you have an offsite location. If you don’t have a second datacenter, make sure your solution supports cost-effective and secure data storage. Azure Blob Storage is a great solution offering secure storage, fault tolerance, and quick recovery, so consider a solution that can use Azure for storing your backups.

Crash Course on VSS (Brief)

We mentioned in the features section live backups. How do you take a backup of a VM that is currently running? Easy. Use a solution that works with VSS. The Volume Shadow Copy Service, or VSS, is where the magic happens. This service, a part of all currently supported versions of the Windows operating system and dating back to Windows XP, enables the operating system and compatible applications to take backups of volumes while other applications or services are actively writing data to them. That’s critical to obtaining consistent and complete backups of large data sets, including databases, complete volumes, and virtual disks. VSS coordinates all the actions needed to create a “shadow copy,” also called a snapshot, of whatever data is being backed up. VSS is useful for more than just backups. You can use it for data mining, disk-to-disk backups, fast data recovery for failed LUNs, and more. In the case of VMs, using VSS to create backups ensures that you get everything that makes up the virtual disk so that you have an application-consistent backup. That way, you have a working VM you can boot if you need to, not just a VHD you can mount to search the file system.

There are four parts of VSS. They include

1. The VSS service, which is a part of Windows and arbitrates the communications between the various other components
2. One or more VSS requestors, which are the backup applications to use VSS. These include the Windows Server Backup Utility (Windows Backup,) System Center Data Protection Manager and many third-party backup software solutions.
3. The VSS writers, which are the components that guarantee that data is complete and consistent when committed to a volume and made available for backup. Microsoft server products like Exchange and SQL Server and, yes, Hyper-V, include VSS writers, as so some third-party server applications that need to rely on VSS.
4. The VSS writer, which is what handles the shadow copy creation and maintenance. This can be software in the operating system or in drivers or can be a hardware solution included in a SAN. Windows’ included VSS writer uses a copy-on-write to ensure all writes are committed to a shadow copy.

VSS writers can write data for shadow copies in three different ways.

1. Complete copy – consider this a clone. Every single block at a given point in time is copied to another volume.
2. Copy on write – this creates a differential copy of all changes (writes) from a given point in time going forward.
3. Redirect on write – similar to the copy on write. This redirects all changes to a different volume.

Please see https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee923636(v=ws.10) if you would like a deeper dive into VSS, including information on I/O and storage costs as well as different providers that are available. For the purposes of backing up Hyper-V virtual machines, it’ enough to understand that you want a VSS-compatible backup solution so that you can take exact point-in-time backups as and when you need it.

What are Production Checkpoints? (2016 & 2019)

Hyper-V in Windows Server 2016 introduced a new type of checkpoint, called the Production Checkpoint. The original checkpoint is now referred to as a “standard checkpoint”. The Production Checkpoint is a point in time image of  VM and leverages the guest operating system’s backup technology to take a complete snapshot of the VHDX at the point in time. Not only is this faster than using a saved state technology, but it’s also fully supported to restore this image for all production workloads, which is a pretty big deal for things like Exchange, SQL, and Active Directory. Standard checkpoints rely upon the host and “grab the state, data, hardware settings, et al” of a running VM but are not supported for production recovery. You can use them for dev and test all you want, but don’t count on them for production if you need to maintain a supported state.

What is Resilient Change Tracking (aka CBT), and why is it Important?

Changed Block Tracking (CBT,) or as Microsoft refers to this, Resilient Change Tracking, is a native change tracking mechanism in Hyper-V 2016 and onward. This is a more flexible and better-performing method of capturing changes to a volume than VSS offers and is a feature VMware admins have enjoyed for a few years. RCT’s most important capabilities are the ability to track and capture changes at the block level, which speeds up performance and can save 30% or more on storage requirements when taking backups of VHDXs. That equates to cost savings for storage.

Use case of a non-VM based VM Backup tool vs. something like Altaro VM Backup.

When it comes down to what solution to use to backup (and restore) your mission-critical virtual machines, you can use any system that can back up files stored for Hyper-V VMs, including the VHDXs, differencing files, configuration files, and memory dumps. If you store all of those in a single location, you can just back up the directory, and Bob’s your uncle. What’s not to love? Actually, quite a bit. There are several to consider. Let’s take a look at a hypothetical organization that runs a mission-critical web application with a three-tier architecture. The front-end web servers, middle-tier application servers, and back-end database servers all work together and all have different backup needs, RPO/RTO targets, and retention requirements. All are running as Windows Server 2016 (in this case but would work with other supported versions) guests on various Hyper-V hosts.

1. Storage requirements-Using Windows Backup or a third-party backup application means taking backups of every single machine in all three tiers. Even though they are all running the same operating system and at the same patch level, each VM is a unique set of files. But when using Altaro VM Backup can reduce storage costs by performing inline deduplication. Since the VMs are running, and the solution is leveraging the guest operating system, files that are common amongst the VMs, like the operating system, can be deduplicated in the backups, saving tons of space.
2. Reduced RPO-Backups of files can take a significant amount of time to start, run, and complete, increasing the elapsed time between your most recent backup and when something bad happens. Continuous Data Protection enables you to take a backup as frequently as every five minutes, ensuring a very short RPO. And that policy can be set at different frequencies for different VMs easily. Take a backup of the web servers once a day, the middle-tier servers four times a day, and the database servers every five minutes, to get a balance between RPO and storage costs.
3. Simplicity-many backup applications are written for file systems and don’t have as much granularity for different needs for different sources, making the setup and maintenance of backups much more work. Altaro is purpose-built to backup virtual machines, and the interface is easy and intuitive, letting you get your backups set quickly.

An Example Backup Job

Still not convinced? Here’s a quick walkthrough of how quick and easy it is to set up a backup of a VM using Altaro, complete with pretty pictures. We’re using our own product as an example here, but many other backup applications targeting virtual machines will work in a somewhat similar manner.

• If you haven’t already, log onto your Hyper-V host, download and install Altaro Backup fromhttps://www.altaro.com/vm-backup/download.php. You can choose a free version that lets you back up two VMs per host forever or a thirty-day trial that lets you try everything for a month before you buy. It’s a “next, next, enter” type install. At the end of the install, you will be prompted to launch the management console like this.

• The console will prompt you to either connect to “This Machine” or to a “Remote Machine” since you can manage more than one instance of Altaro VM Backup from the same console. Choose “This Machine” to set up your job. You can also tick the box to log on automatically next time if you wish.
• You can use the Quick Setup to get a backup job up and running quickly. As you can see in the console, there are three simple steps.                                                                                                                                                                 
• Click Add Hyper-V/VMware Host to add your host physical server. This will switch to the management console once it enumerates the host.
• Select the backup location you wish to use to store your backups. You can select local or network storage, as seen below.

In this example, we will use a Physical Drive, so we click that and then click Next.

• Here we can see the three physical disks connected to our Hyper-V host, and we have selected the G: drive. Note, backups will be stored at the root of the volume, under a folder names AltaroV7, unless you click the “Choose Folder” to pick or create another folder.
  To complete step 2, we just need to select the drive and click Finish.

• Now we need to select the VM or VMs we wish to backup to this drive and simply drag-and-drop them to the drive. Make sure you drag the VMs over the actual drive letter, not just into the middle pane.

You can see in the console pane on the left that there are several options you can configure, including scheduling, retention, and more. For a quick backup, though, we’re just going to click down on Step 3, Take Backup.

• You will be prompted to save changes. Do so, then tick the box next to the VMs you wish to back up and click “Take Backup.”                                                                                                                                                                                   

• Please note, if you have VMs that were created on an older version of Hyper-V, they might be running configuration version 5.0. If you get an error that they cannot be backed up, you need to first shut down the VM, then update the configuration (right-click the VM in the Hyper-V console and select upgrade) and then restart the VM. You’ll be able to back it up then.                                                                                                                   

• As the backups run, you can see the status by moving your mouse over the progress icon.

• When complete, you should see this.

If you click the + sign on the far right, you’ll see some statistics on the backup. Notice the space savings for this particular backup!

If you need to do a restore, the steps are very similar.

1. On the right-hand menu, click Restore.                                                                                                                                   
2. Click the source location, and click Next.
3. Select the VM or VMs you want to restore, and click Next.
4. Choose the options appropriate for your restore job. Notice you can restore to another host, and the default is to restore with the NIC disconnected. Click Restore, and off it goes!

Other options

There are several other options you can select. You can do granular file-level restores from file servers or item-level restores from Exchange servers.

You can also test and verify your backups, which is probably the single most important thing to do with any backup solution but is missed by so many other systems. The very last thing you ever want to do is find out your backups are not working only when you actually need to do a restore!

One other thing you may want to make sure you look at is the Reports section. It gives you just what you need to check and confirm operations completed successfully, without burying you in details you won’t want to read anyway. It tells you the what, when, and how, and that things were successful, or if something wasn’t, why.

You cannot export the reports, but you can see everything you need. If the boss wants a printout, screenshots of the console should suffice.

Setting up scheduled backups and retention policies are both simple drag and drop operations. Pick a default schedule or create your own, drag the VMs to it you want to be covered, and that’s it. It will take you longer to read this paragraph than to set up a backup and retention schedule!

Final thoughts

If your business relies upon virtual machines, then you need backups that you can rely upon. Altaro VM Backup gives you all the functionality you need to backup, and restore VMs and individual items from VM backups with the security and flexibility every business needs, without the costs that only enterprises can afford. You owe it to yourself to get the peace of mind that Altaro VM Backup offers by downloading and installing it today.

The post How to Back Up your Hyper-V Virtual Machines appeared first on Altaro DOJO | Backup & DR.

Although most VMware administrators probably back up their virtualized environments regularly, backups are often centred around the virtual machines and not necessarily on the underlying infrastructure. Even so, it’s a good idea to backup (or at least document) your ESXi host configuration. Doing so will allow you to put things back to normal following a configuration error, boot disk failure, or another minor catastrophe. Fortunately, VMware provides native tools that make the process easy.

Before I Begin…

The approach that you will have to use varies depending on the version of VMware that you are using. If you are running VMware 6.x for example, then you will need to leverage vSphere CLI. However, this tool has been deprecated, which means that a different tool will be needed for those who wish to create a backup of a vSphere 7.x environment.

vSphere 6.x

The VMware tool for backing up host configurations is a command-line utility named vicfg-cfgbackup. There are two important things that you need to know about this utility before using it.

First, vicfg-cfgbackup is designed to be run in the VMware CLI environment. You can download the current version of vSphere CLI here.  This tool adds VMware support to the Windows Command Prompt. Hence, the commands that I will be discussing in this blog post should be entered into a command-line environment, not PowerShell.

The second thing that you need to know about the vicfg-cfgbackup tool is that the vicfg-cfgbackup command’s syntax varies slightly depending on whether or not you are running the command on a Windows system. For this blog post, I will be working in a Windows environment. You will therefore see me adding a .PL file extension to the end of the vicfg-cfgbackup command. The .PL extension should not be used in non-Windows environments.

The reason why the .PL extension is required in Windows environments is because the vicfg-cfgbackup tool is based on Perl. You will therefore need to have Perl installed to use the vicfg-cfgbackup tool. It is also worth noting that your Perl deployment will need to have the XML/LibXML.pm library installed. Otherwise, you will get an error stating that windows “can’t locate XML/LibXML.pm in @INC (you may need to install the XML::LibXML module).”

You can download this library at https://metacpan.org/pod/XML::LibXML

If you happen to be using ActiveState Perl, then you can install the required module by entering the following command:

Ppm install XML::LibXML

You can see what the process of installing the required module looks like in Figure 1.

Figure 1

This is how you install the XML::LibXML module if you are running ActiveState Perl.

Backing Up the Host Configuration

As previously noted, the process of backing up a vSphere host’s configuration is relatively easy. You can do it with a single command. In a Windows environment, that command is:

Vicfg-cfgbackup.pl –server=<the host’s IP address> –username=root -s <output file name>

To give you a more concrete example, I have an ESXi host with an IP address of 147.100.100.224. If I wanted to create a configuration backup named 224CFG and place that backup into my PC’s C:\Data folder, then the command that I would use to do so would be:

Vicfg-cfgbackup.pl –server=147.100.100.224 –username=root -s C:\Data\224cfg

As you can see in Figure 2, upon entering this command, you are prompted to enter the root password. Once you do, the firmware configuration is written to backup.

Figure 2

This is how you create a backup file.

As you look at the figure above, there are a couple of things that are worth paying attention to. First, you will notice that I had to execute the command in the C:\Program Files (x86)\VMware\VMware vSphere CLI\bin folder. This is not the default folder that appears when you open the command prompt environment.

Another thing to note is that when you enter the root password, nothing appears on the screen as you are typing. This is normal behaviour.

One more thing that I want to mention is that VMware allows you to use any filename that you want when creating a backup. I used 224cfg as a file name because 224 is the last part of the host’s IP address, and the cfg portion of the filename indicates that this is a configuration backup. Such a filename is fine for use in a demo environment such as the one that I am using, but in a production environment, there are two things that I recommend including in your filename.

The first thing is some sort of host identifier. Having a host identifier isn’t mandatory, but it is helpful to know which host a backup was created on. The other thing you should include in the file name is a reference to the host’s build number. Knowing the build number will be helpful if you ever have to restore the backup.

Restore vSphere Host Configuration

The single most important thing that you need to know before attempting to restore a host’s configuration data is that the host’s build number must match the build number saved within the backup file.

Suppose for a moment that you were to create a host configuration backup but don’t really have any immediate need for it. Now suppose that some time passes, and during that time, you perform a couple of software upgrades to your ESXi host. If there were suddenly a need to restore the host configuration, you would find that the restore operation would fail because the configuration backup build number is older than the host’s build number.

In a situation like that, there are two options available to you. The first option is to try to force the restoration despite the version mismatch. The vicfg-cfgbackup command supports the use of an -f flag. This flag causes vicfg-cfgbackup to ignore the version mismatch and restore the configuration anyway. Of course, in a version mismatch situation, forcing a restoration can yield unpredictable results.

The other option is to reinstall ESXi onto the host from scratch (being careful to install the correct version). You would then be able to restore the configuration backup and then update the host to the same build number it had been running before the failure. At that point, it would be an excellent idea to create a new configuration backup so that you can avoid having to work through the process that I just described if another restoration becomes necessary.

This brings up another important point. I very strongly recommend retaining copies of the installation media for all of the VMware software versions that you have installed in the past. You cannot simply assume that VMware will always make old versions of its software available for download.

This, of course, raises the question of how you can compare build numbers. There doesn’t seem to be an easy way to derive the build number from the backup file. That’s why I recommend including it as a part of the file name. You can check the host’s build number by using this command:

esxcfg-info -u

Before you restore the backup, you will need to place the host into maintenance mode. Upon doing so, you can restore your backup by using this command:

vicfg-cfgbackup.pl –server=<the host’s IPaddress> –username=root -l <the backup’s path and filename>

If, for example, I wanted to restore the backup that I created earlier, I could use this command:

vicfg-cfgbackup.pl –server=147.100.100.224 –username=root -l c:\data\backup

You will notice that this command contains the -l switch. This switch tells vicfg-cfgbackup that you are performing a restoration, not a backup.

vSphere 7

As previously noted, VMware has deprecated the vSphere CLI (https://kb.vmware.com/s/article/78473), and will not be using it in the future. As such, vSphere 7.x uses a completely different (but easier) method for backing up and restoring an ESXi host configuration.

Rather than using the vSphere CLI, the new technique involves using the ESXi Command line. In order to do so, you will need to be logged in as the root user.

The first step in the process is to synchronize the configuration with persistent storage. To do so, enter the following command:

Vim-cmd hostsvc/firmware.sync_config

Once the synchronization process completes, you can perform the backup. The command used for doing so is:

Vim-cmd hostsvc/firmware/backup_config

This command backs up the host configuration by creating a .TGZ bundle file. Upon the command’s completion, the console will display a URL from which you can download the bundle. At that point, you can simply open a Web browser and download the bundle file.

It is worth noting that downloading the bundle file will require you to make a slight modification to the URL that is provided. The URL includes an asterisk that takes the place of your host’s fully qualified domain name (FQDN). You will need to substitute your host’s FQDN or IP address for the asterisks. Suppose for example that your host’s IP address was 10.1.1.0. In that case, you would change http://*/downloads… to http://10.1.1.0/downloads…

Restoring the vSphere Host Configuration Backup

The process of restoring the backup is just as easy as that of creating the backup. As was the case for vSphere 6.x however, you must make sure that the VMware host is running the same build as was used when your backup was created.

The first step in restoring a backup is to rename your backup file. Remember, the backup is a .TGZ file. In order for you to be able to restore this file, you will need to change its name to configBunfle.tgz. The filename is case sensitive.

The next thing that you will need to do is to place the VMware host server into maintenance mode. You can do so by entering the following command:

Vim-cmd hostsvc/maintenance_mode_enter

Now that the host is in maintenance mode, you will need to copy your backup file to the ESXi host. As an alternative, however, you can copy the file to a datastore. To perform the actual restoration, enter the following command:

Vim-cmd hostsvc/firmware/restore_config 1 /<backup file location>/configBundle.tgz

The number 1 in the command shown above forces an override of any UUID mismatch that may occur. If you do not wish to override such a mismatch, you can omit the 1. It is also worth noting that the host will be rebooted upon the command’s completion.

Conclusion

VMware makes it really easy to backup and restore a host’s configuration, regardless of which version of VMware you are using. The one thing to remember, however, is to keep your host configuration backups up to date as you update your VMware hosts to newer builds.

The post How to back up vSphere Host Configuration Settings appeared first on Altaro DOJO | Backup & DR.

Although most Hyper-V admins meticulously back up their virtualized environments, these backups may sometimes focus on the virtual machines themselves rather than on the underlying Hyper-V infrastructure. Even so, having a backup of an organization’s Hyper-V host servers can be useful for any number of reasons. An organization might, for example, wish to undo an unwanted configuration change on a Hyper-V host or rebuild a host following a boot disk failure. This would be one reason where you would be looking to back up Hyper-V itself, or more specifically, it’s configuration.

Unfortunately, Hyper-V doesn’t contain a “click here to back up the host configuration,” nor does it include a host configuration backup utility like VMware does. Even so, there are several different options for backing up (or at least documenting) a Hyper-V host’s configuration. I will discuss two of the more effective options in this article.

Create an Image Backup

The first option for backing up the host’s configuration is to perform an image backup. An image backup (at least within the context of the technique that I am about to explain) cannot be used to restore individual files and folders. However, this type of backup works really well for reverting a Hyper-V host to a previous state.

Before you can create a system image, you will need to install the Windows Server Backup feature onto your Hyper-V server. You can do this from the Server Manager’s Add Roles and Features Wizard by choosing the Windows Server Backup option from the wizard’s Add Features screen, as shown in Figure 1.Once Windows Server Backup has been installed, you can access it from the Server Manager’s Tools menu.

Figure 1

You will need to install the Windows Server Backup feature.

From within the Windows Server Backup console, click on the Local Backup container, and then click on the Backup Once link. This will cause Windows to launch the Backup Once Wizard. Click Next to accept the default option on the Backup Options screen. You will then be taken to the Select Backup Configuration screen. Choose the Custom option and click Next.  This will take you to the Select Items for Backup screen. Choose the Custom option, and then click Next. You will now be prompted to select the items that you want to back up. Be sure to choose the Bare Metal Recovery option, the System State, the EFI System Partition, and the C: drive, as shown in Figure 2. Since you are not backing up individual virtual machines, there is no need to include volumes containing your VMs. Now work through the remainder of the wizard, and create the backup.

Figure 2

Select the items that you wish to include in the backup.

If you need to restore the host, you can do so by booting from the Windows Server installation media. Upon doing so, select your language, and then click the Repair Your Computer link found on the following screen, as shown in Figure 3.

Figure 3

Click the Repair Your Computer link.

Now, click the Troubleshoot icon displayed on the following screen, and then click the System Image Recovery icon, shown in Figure 4. Now, follow the prompts to restore a system image, as shown in Figure 5.

Figure 4

Click on the System Image Recovery option.

Figure 5

Select the system image that you want to restore.

It probably goes without saying, but Windows Server Backup is a lightweight backup utility that will work in a pinch, but it should not be used for your day to day backups. Look to a third party for that.

Using PowerShell

The previously described method uses backup and restore to reimage the Hyper-V server’s boot drive. While this technique will certainly return the Hyper-V server to a previous configuration, a full-blown backup and restore is going to be overkill unless the server is experiencing significant problems.

A better solution may be to use PowerShell to retrieve the various Hyper-V host configuration settings and write them to a file that you can use as a configuration baseline. If there were ever to be a problem with a Hyper-V host’s configuration, you could use the exact same cmdlets (which can be scripted) to review the server’s current configuration. These configuration items can then be compared to the baseline configuration, thereby allowing you to reconfigure the server to use known good settings.

Unfortunately, there isn’t one PowerShell cmdlet that retrieves every possible configuration item. You will have to use a variety of cmdlets. Before I show you some of these cmdlets, I need to take a moment and talk about file redirection.

The output from a PowerShell cmdlet can be redirected to a file. To create a text file, you would want to append the following line of code to your first PowerShell statement:

| Out-File -Encoding Ascii <filename>

For example, if you were trying to write a list of your server’s VM’s to a text file, you could use a command that looks something like this:

Get-VM | Out-File -Encoding ASCII VMs.txt

If you look at Figure 6, you can see what this command looks like in action. In the screen capture, I have used the Get-Content cmdlet to display the contents of the text file.

Figure 6

I have written a list of VMs to a text file.

For subsequent commands that output Hyper-V configuration information, you will need to append that information to the file created by your first command. Otherwise, the file will be overwritten. The easiest way to accomplish this is to add the -append parameter to the Out-File cmdlet. If, for some reason, I wanted to append another list of VMs to my existing text file, for example, I could do so by using this command:

Get-VM | Out-File -Encoding ASCII -append VMs.txt

You can see how this works in Figure 7.

Figure 7

This is how you append data to an existing text file.

So, what types of data should you focus on exporting? Although not a comprehensive list, it is a good idea to make sure that you focus on networking, storage, and general Hyper-V configuration.

Storage

When it comes to exporting your Hyper-V host’s storage configuration, you will have to consider the type of storage that your server is using. You would use a different technique to export information about direct-attached storage than you would use to export information about remote storage, for example. A few of the more basic cmdlets that might come in handy when documenting your server’s storage configuration include:

Get-Disk

Get-Partition

Get-Volume

You can see examples of these cmdlets in Figure 8.

These are a few cmdlets that you can use to retrieve storage configuration information.

Networking

PowerShell makes it possible to export a plethora of network configuration data. At the very least, though, you should probably export data related to your host’s physical network configuration and to the Hyper-V virtual switch. Here are some commands that you may find useful:

Get-WMIObject -Class Win32_NetworkAdapterConfiguration -Filter IPEnabled=True

Get-VMSwitch

As you can see in Figure 9, the first command shows how the physical network adapters are configured, while the second command displays the Hyper-V virtual switch configuration.

You can use PowerShell to retrieve the physical network adapter configuration and information about your Hyper-V virtual switches.

Hyper-V Host Information

When it comes to retrieving Hyper-V host information, the main command that you should use is Get-VMHost. Keep in mind that this command shows very little information by default, so you should use the Select-Object cmdlet to show all of the available attributes, as shown in Figure 10.

PowerShell displays the Hyper-V host’s configuration.

One thing to keep in mind is that the Get-VMHost cmdlet will not necessarily tell you everything you need to know about your Hyper-V host. You may need to run supplementary commands depending on how the host is set up. For example, if the host belongs to a cluster, you can use the Get-VMHostCluster and the Get-Cluster cmdlets to retrieve cluster-specific data.

Conclusion

As you can see, there isn’t a seamless and straightforward way to back up Hyper-V’s host configuration. With a little imagination, though, you can protect your configuration by either creating an image backup or by exporting configuration information through PowerShell.

The post How to Back Up Hyper-V Host Configuration Settings appeared first on Altaro DOJO | Backup & DR.

Task Scheduler is a built-in Windows utility that does not often get the respect it deserves as a powerful automation tool.  Although it only has a few features, Task Scheduler’s ability to run any script at a scheduled time or be triggered via an event is very useful!

This blog will show you how you can utilize Task Scheduler to make your backups and recoveries more successful, even if you use a basic utility like Windows Server Backup. In fact, even Windows Server Backup, along with other leading backup providers like Altaro, will use the Task Scheduler engine’s via calling the TaskSchd.h APIs.

This blog will show you how you can use Task Scheduler to automate your backup, recovery, and administrative tasks before you even need to start the backup itself.

Task Scheduler for Backups Overview

Let’s review a few relevant features of Task Scheduler, which can be used to improve your backup and recovery procedures:

• Trigger – This defines an action or time which causes a task to begin. There are two trigger types we can use, including:
  • On a schedule – This will let you run a task at a specific time daily, weekly or monthly, such as creating a daily backup. You can also repeat the task multiple times a day in increments of 5 minutes, 10 minutes, 15 minutes, 30 minutes, or once an hour.
  • On an event – This trigger will let you run a task if a specific event is detected in an event log, such as a failed backup attempt.

Figure 1: Task Scheduler is configured to trigger an action if Event 4 (Backup Successful) is written to the event log.

This task will then monitor the event log, and if a matching Event ID is discovered, it will trigger an action.

Figure 2: Event Viewer detects a backup event and causes Task Scheduler to trigger a task.

• Action – This defines what happens once the task is triggered.
  • Start a program – this is almost always used when a task is triggered. It will either start a program or run a script, so you can use this to launch your backup provider once your prechecks have passed.  Since you can run any program with a command-line interface, it gives you the flexibility to use traditional scripting languages or PowerShell.  You can also send files or pass variables into these scripts.

Figure 3: Task Scheduler is triggered to run PowerShell and then provide the location of a script

• Send an email – This feature will connect to an SMTP mail server and send an email to an administrator. Microsoft has deprecated support for this feature, which means that it should work, but Microsoft will not update it and no longer provides technical support for it.

For additional information about Task Scheduler, visit Microsoft’s documentation About the Task Scheduler.

Running a PowerShell Script with Task Scheduler

Since Windows Server uses PowerShell as its primary scripting language, this section offers guidance for running PowerShell from Task Scheduler.  If you are integrating your script with any third-party API, such as your backup provider, you should ensure that they have an API or PowerShell cmdlets that you can use to automate your backup tasks.  Altaro offers both an API and PowerShell, making it easy to perform various automated tasks, such as applying a configuration template, taking an offsite copy, and restoring a VM.

For any task which requires you to run a PowerShell script, you have to be able to launch PowerShell and send it the file path of the script to run.  For Windows or Windows Server, you will usually use the following parameters from the Start a program option:

• Program/script:C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
• Add arguments:
  • Cmdlet such as Start-WBBackup -Policy $Policy -Async
  • File location such as C:\Users\Admin\Scripts\Backup\backup.ps1
• Start in: Directory location to start the command prompt, such asC:\Users\Admin\Scripts\Backup\backup.ps1

If you are using Windows Server Backup with PowerShell, you can find complete documentation here.

Creating a Backup with Task Scheduler

The first collection of tasks you should consider are related to creating a backup.  While every backup provider offers this fundamental feature, they may not allow you to automate pre-backup testing and post-backup verification tasks.  Remember that for a backup to be completed successfully, dozens of sequential actions need to happen correctly before and after the backup.  You can use the following checklist against your system, but be sure to consider any other custom steps in your standard backup workflow.  The order suggests which actions can be run concurrently (1a,1b, etc.) and should be consecutive (4,5, 6, etc.), but you should reorder to whatever makes sense for your infrastructure. The backup process can be triggered by either a manual request, an event, a previous task, or a scheduled time.

Managing your Backups with Task Scheduler

Task Scheduler can help you with regular backup management and maintenance tasks.  Most enterprise backup providers will provide similar functionality, such as Altaro’s VM Backup, which allows you to replicate your backups to Microsoft Azure.

Triggering a Recovery from Backup with Task Scheduler

Whenever there is an outage, you will want to verify which services were affected and whether any data loss happened.  While these tests are running, you may want to also initiate parts of the recovery process so that you can minimize the total service outage.  It is important to automate the detection and recovery because any manual steps will slow down the process. You can find more best practices from Altaro’s blog about how to Recover and Restore your Backups Faster after a Disaster.  The following order and steps may vary based on your infrastructure and recovery solution.

If, at any time during this process, you need to terminate a task that is running, such as detecting a false failure alert, you can use the PowerShell cmdlet to stop any Task Scheduler task.  Keep in mind that this will terminate the task only if it is still managed by Task Scheduler.  If this task has already triggered some other action, such as running a PowerShell script, then that other process must also be terminated.

Task Scheduler offers simple yet powerful tools for managing backups and recovery.  Whether you depend on Task Scheduler or a third-party backup solution to manage your critical data, make sure that your backup infrastructure is also highly-available and resilient.  Windows Server Task Scheduler can even be deployed on a Failover Cluster so that its tasks failover between nodes and will always run.  Check out the documentation on how to use PowerShell to manage Clustered Scheduled Tasks.  With these Task Scheduler tips and tricks, you will now be able to add more resiliency to your backup and recovery workflow.

The post Backup and Recovery Tricks using Windows Task Scheduler appeared first on Altaro DOJO | Backup & DR.

One of the most underutilized features in Windows Server Failover Clustering is the ability to configure and prioritize network traffic of Hyper-V virtual machines (VMs) and their applications.  This is mainly because this feature is hidden from the Failover Cluster Manager GUI and must be accessed using PowerShell.  However, many admins consider this a critical feature to optimize their cluster traffic and build resiliency into their infrastructure.  This blog post will give you the best practices which I learned while I was an engineer on Microsoft’s Clustering Team, focusing on how to optimize your backup and recovery traffic when you really need it.

Remember that your organization is using a failover cluster to provide high availability for your important VMs and applications.  A key tenant of clustering is that all the hardware must be redundant to avoid any single point of failure.  This means that in addition to having multiple servers (hosts) and shared redundant storage, there are also multiple networks connecting each host to the rest of the datacenter.  If any cluster network is being overused, then traffic using that network may be blocked or delayed.  If traffic cannot get through, it can cause adverse effects on the system, such as triggering a false failover.  By using network prioritization to define the importance of each type of traffic, you can eliminate bottlenecks and maximize your traffic flow.

In an ideal world, your cluster should have at least 4 networks, each with a primary role.  If any of these networks fail, then the traffic will be rerouted through a different network.  If you have fewer than 4 networks, you can combine roles, however, you generally want to separate and prioritize the following types of traffic as follows:

1. Cluster and Cluster Shared Volumes (CSV) – The cluster network provides the critical communication path needed for the nodes to interface with each other, perform health checks, and route traffic. This network should be assigned the highest priority because if it is unavailable or nodes cannot communicate with each other, the cluster could pause, trigger a live migration, or a failover, which can incur downtime.
2. Storage – If you are using ethernet-based connections to access your shared storage, such as SMB, iSCSI or Fibre Channel over Ethernet (FCoE), then you want to separate this network and make it your second highest priority. Since the performance of your VMs or applications may be limited by their ability to access storage, generally this network should be optimized and dedicated to only this type of traffic.
3. Public and Applications – This network should be used exclusively to connecting the clustered workloads or VMs to their applications or users. If this network is accessible via the public Internet, then it may be subject to DOS attacks, which flood the network and block other traffic from going through.  For this reason, you should always separate this network so that any interference will not trigger any changes within your cluster.
4. Management & Backup – The lowest priority network is usually the management network which is used support high throughput, yet infrequent traffic. This network will be used for live migration traffic to copy large amounts of memory between hosts; backup and recovery traffic to copy large amounts of critical data; patching traffic to distribute new updates to the hosts; and deployment traffic to copy OS images files, virtual hard disks (VHDs) or snapshots to VMs.  It is usually recommended to be the lowest priority since it only gets used occasionally for specific tasks, and it is a good candidate to be the backup network for all the others.

Based on your hardware, once you’ve made your determinations, you are ready to assign a priority to your networks. Follow the guidance provided in this blog by Altaro on the Hyper-V Network Prioritization and Binding Order.  At a high level, prioritization happens by assigning a value (“Metric”) to each network, with the lowest value being the highest priority.  For example, you may have assigned your 4 networks as follows:

• Cluster Network = 1000
• Storage Network = 2000
• Public Network = 3000
• Management &Backup Network = 4000

Based on these recommendations, the backup network will be considered the lowest priority network as the traffic is irregular, but does that really make sense for such a critical function?  Ensuring that every backup gets completed is important to prevent data loss and decrease your recovery time objective (RTO) and recovery point objective (RPO).  Ensuring that you can restore a backup quickly is even more important for the business, but when using the lowest priority network, it can be challenging to force this traffic through.  This should be especially worrying if there has been a catastrophic failure which causes the cluster to restart, and it will prioritize its own cluster and storage traffic.

The easiest solution is to have a separate network entirely dedicated to backups, and assigning this as the second-highest priority network.  If you have a fifth network that is easy:

• Cluster Network = 1000
• [NEW] Backup/Recovery Network = 1500
• Storage Network = 2000
• Public Network = 3000
• Management Network = 4000

Or you are not using a network for ethernet-based storage, then reprioritize this one so the configuration would look like:

• Cluster Network = 1000
• [UPDATED] Backup/Recovery Network = 2000
• Public Network = 3000
• Management Network = 4000

However, most Hyper-V hosts have only 4 network interfaces and use Ethernet-based storage.  In this case, then you can dynamically change the prioritization of the network using a PowerShell script.  This is easy to do when you are taking a regularly scheduled backup, whether that is hourly, daily, or weekly.  A few minutes before you begin this backup task, run the script to switch the priority of your backup network so it has the second-highest priority.  Then several minutes after the backup has successfully completed, restore it to the original priority order using a second script.

If you have detected that you need to restore a backup to a cluster, then you will follow a similar workflow of dynamically adjusting the prioritization.  This is a little more challenging as it will not automatically be scheduled and must be triggered only when a recovery is actually needed.  Whether this task is run automatically (recommended) or requires manual intervention, make sure that this script has been written and tested in advance.  Testing is critical to ensure regular backups and easy recovery, so if dynamic network adjustment is part of your backup plan, make sure that you are checking the states and priorities of your cluster networks before, during, and after this process.

Even if you follow the recommendation to set your management network as your lowest priority due to the irregularity of its traffic, you now know how to quickly adjust the priority when needed.  This will give you the best chance to optimize your backups and restore them as quickly as possible when a disaster strikes.

The post Configuring Network Prioritization for Cluster Backup and Recovery appeared first on Altaro DOJO | Backup & DR.