This chapter covers the following recipes:
The ability to backup and restore a Windows Server has been a feature of Windows since the first version of Windows NT, released in 1993. In the early days, you used NTBackup (via a GUI) to carry out backup and restore activities. With Server 2008, Windows Server Backup replaced NTBackup and offered 15 cmdlets (provided in an old-school PS Snap-in) to augment the GUI. The Snap-in was replaced with a module, WindowsServerBackup, and was improved with Server 2012. The module remains unchanged in Server 2016 and provided 49 cmdlets.
Windows Server Backup (WSB) provides a set of features to enable you to backup and restore files, folders, and Hyper-V VMs as well as an entire system. These features are more than adequate for many organizations and come for free with Windows Server 2016. Nevertheless, some organizations need more functionality. There is a rich third party backup industry with a variety of competing products that deliver more than the in-box Windows Server Backup offers...
With WSB, you create a backup policy that describes what you want to backup from your server (backup source), where you want to put the backup (backup target), and when you want the backup to take place (the backup schedule). You first create an empty policy in memory or get an editable copy of the active backup policy. You then configure the policy object with a backup source and backup to your requirements. You then either save the policy as the (new!) active policy or use it to run a one-off backup. Once you have set an active policy, WSB runs the backup automatically based on the schedule you define when you populate the backup policy.
In this recipe, you create and configure a policy that backs up the C: drive every morning at 06:00. This policy object is the starting point for examining backup with WSB. Later recipes enable you to perform, explicitly, system state backup, one-off backup, selective file backup, and VM backup (and restores)—all of which...
In the previous recipe, you created a basic backup policy that runs a full backup of the C: volume every day at 6:00. This recipe examines the results of the backup and helps you understand the details of the resulting backup.
Before carrying out this recipe, you need to have had a backup job completed. In the recipe Configure and set backup policy, you created a backup job that would run every morning. Thus, you can wait until the day after you set up this daily backup, or you can run a once-off job as shown at the end of that recipe.
The steps for the recipe are as follows:
Get-WBPolicyGet-ChildItem -Path Q: -Recurse -Depth 3 -Directory$Backup = (Get-ChildItem -Path Q:\WindowsImageBackup\Psrv `
-Directory |
Select-Object -First 1).FullName
...In most cases, your server's backup policy is fire and forget. You create and set the backup policy, and from then on backup just happens at the time you specify in the backup schedule. In other cases, perhaps before and after a major system change, you may want to initiate a one-off backup and not wait for WSB to create a scheduled backup. Additionally, you may just want to create a backup of key files. In those cases, you can run a backup based on a one-off policy.
To perform this recipe, you may find it helpful to remove the existing backup policy. This ensures the one-off policy you create in this recipe does not overlap with earlier/later recipes. If you perform this recipe on a live production server, make sure reinstate the backup policy after you have completed your testing.
Removing the policy is straightforward:
If (Get-WBPolicy) { Remove-WBPolicy -All -Force } This recipe also uses a folder C:\Foo. If this does not exist on your system, create...
Performing backups is great, but backups are only useful if you can use them to restore files and folders. The reasons for restoring include recovering from a major system disaster, recovering from a single disk failure, or just restoring a file a user has inadvertently deleted.
In the previous recipe, you saw how you could mount the VHDX that WSB created for you and give it a drive letter. So one way to recover the file is just to mount the backup VHDX and then use Explorer or other tools to copy files from the backup to a new home. This recipe uses the WSB cmdlets to recover to a separate folder. You would do this if you wanted to recover some particular files and did not want to overwrite anything.
There are many ways to back up a Hyper-V VM. You could, of course, use the recipes in this chapter inside the VM to back up your VM's hard drive contents to a network drive. As an alternative, you could use WSB to backup an entire VM and restore it.
Regarding the WSB commands to use when backing up a Hyper-V VM, you have options. You can use the WSB cmdlets, as you have done so far in this chapter. Or, you can use the Wbadmin console application. Wbadmin is a Windows command line tool that pre-dates the PowerShell module. It has the advantage of being higher ranked in search engines—useful if you wish to learn more. You may also find Wbadmin simpler to use in practice. This recipe shows how to use Wbadmin to create a backup of your VM and then restore it.
The Bare metal recovery (BMR) is the process of restoring a backup onto a new machine. Suppose your file server, FS1, has a catastrophic failure and has to be replaced by a new server computer. To get this new host up and running, you could manually run through the setup of the OS, add relevant print drivers, re-define the printers, and then restore the data. Or you could just do a BMR from a backup. This recipe shows how to do bare metal recovery using the PowerShell cmdlets in the WindowsServerBackup module and then the bare metal recovery feature of Windows Setup.
To enable you to see BMR in action on a server, you must first install the Windows backup feature loaded on the server you wish to back up. You run the first part of this recipe on your server to create a backup capable of being restored using BMR. Then, after replacing the hardware, you perform a recovery onto to a new server based on the backup previously taken. This recipe...
In Windows, applications such as the registry can register with WSB. These applications contain a Volume Shadow Copy Service (VSS) writer. WSB uses that writer in the backup process to ensure application data is consistent when WSB takes the backup. The feature enables WSB to restore the application from the backup. In this recipe, you create a backup of a system including the registry and restore the registry from a backup to view the recovered hive.
This recipe uses the application server SRV1. Ensure the server has the WSB feature added, as shown in the Configure and set backup policy recipe. Your VM needs to have a second VHD added and setup as the E: drive. You use this second drive as the backup target. If you are creating a new virtual hard drive to test this recipe, ensure you bring the drive online, initialize it, and format it.
Most backup jobs are fire and forget. You set them up, and they run. In such an environment, it is easy to forget about backups until the time when you need them (that is to recover a file, folder or entire server). One thing you can do is to generate a daily report on the state of backup on a critical server. You can run this report early every morning, and email it to one or more people in your organization to notify them of any issues that may have arisen with processing backups on critical servers.
This recipe creates a scheduled task which sends an email containing a summary of backup operations on your server, in this case: you use the file server FS1. This recipe is in two parts: the first part is a simple script that creates a backup report (on FS1) and the used email to send you the backup report. The second part of this recipe sets up the scheduled task that runs the backup report script. This second script also summarizes the results of setting up the...
The recipes in this chapter, thus far, have been focused on Windows Server Backup. An alternative to performing backups is backing up to the cloud. This recipe demonstrates using Azure Backup as an alternative to the Windows Server Backup product.
For this recipe to succeed, you need a computer to backup from, an Azure account, and you need to have the Azure cmdlets loaded. You also need to load the online backup cmdlets (which you do in this recipe).
In this recipe, you use SRV2 as the server to backup (and restore). You can run this recipe on any server.
To load the Azure cmdlets, you use the Install-Module cmdlet, as demonstrated in the Explore PowerShellGet recipe in Chapter 1, What's new in PowerShell and Windows Server. You use this cmdlet on SRV2 to find and load the Azure Resource Manager cmdlets that you use in this recipe. Then, you can view the newly installed module, as follows:
Install-Module -Name AzureRm -Repository PSGallery...
© 2017 Packt Publishing Limited All Rights Reserved
