Backing up physical servers and restoring them to previous points in time has always been a little bit tricky in the Windows Server world. When something goes wrong with a server, in most cases it is preferable to fix the issue, rather than to simply rollback to a previous version. If you do want to make the decision to roll back an operating system on a physical server, you are talking about creating downtime. This happens because, whether you are restoring a Windows Backup file, or if you are using some kind of imaging utility that takes a full picture of the hard drive during the backup and is capable of laying that entire image back down in the event of a recovery, you have to stop Windows from running in order to replace its files on the disk. So no matter which technology you have used to take the backup, you must take the server down at least temporarily while you accomplish the restore.
Hyper-V changes everything. When working with our VMs, we have the ability to take and restore Checkpoints whenever we feel the need. This capability was called Snapshots in previous versions of Hyper-V; the term Checkpoints is new in Windows Server 2016. Also new is the choice to create one of two different kinds of Checkpoint - Standard or Production. In this recipe, we will walk through the creation and restoration of both types of Checkpoints to see what benefits each type holds.
All of our backup and restoration work will be accomplished from within Hyper-V Manager on our Windows Server 2016.
We have Hyper-V Manager opened up, and have a number of different VMs running here. Let's explore together the capabilities of Checkpoints:
- Decide on the VM that you want to Checkpoint. I am going to use my new DC3 server. Find that machine in the list, right-click on it, and choose Checkpoint.
- As you will notice, we get a message about the fact that a Production checkpoint has been created for us. It is important that you understand that the production type of checkpoint is going to be the default mode. You will also notice that the Checkpoints section of Hyper-V Manager has now lit up with an entry under the DC3 server. The currently running virtual machine is listed as Now, and you can see a date and timestamp applied above it, which is the Checkpoint we just created.
- The message that presented itself says that backup technology inside the guest operating system was used to create this checkpoint. What does that mean? And more importantly, if we wanted to change back to Standard Checkpoints, where do we accomplish that? Both of these questions can be answered by opening the Settings of your virtual machine. Right-click on DC3, and choose Settings…. Once inside, select the heading that says Checkpoints.
- This is the screen where you can choose whether you want to create Production checkpoints or Standard checkpoints. There is also a good description of each kind. In previous versions of Hyper-V, we could only do Standard checkpoints - called snapshots; we had no other options. Standard checkpoints essentially just create a differencing disk from our VHDX file. When you restore a standard checkpoint, it replaces everything right back to the way it was running, including application level content. Production checkpoints, on the other hand, use backup software inside the guest (VM) operating system. This is more similar to logging into that VM, opening up Windows Backup, and creating a backup file. Except you get to do it in one click, and it only takes a few seconds to accomplish. We will talk about the pros and cons of each type of checkpoint in the How it works… section at the end of this recipe.
- Go ahead and change Checkpoint Type to Standard checkpoints. Then right-click on your VM and choose Checkpoint again. This will create a second checkpoint for us, this one being the Standard type.
- As you can see, there is really nothing distinguishable between the two different checkpoints we have taken, other than the timestamp. Other than our own knowledge, we would not be aware that the 3:27a.m. checkpoint was a production checkpoint, while the 4:00a.m. checkpoint was of the standard variety. If you think you will be taking snapshots of both kinds, it may be helpful to rename these checkpoints, by simply right-clicking on them, to reflect their checkpoint type somewhere in the name of the checkpoint itself.
- Now we want to try restoring these checkpoints, bringing our DC3 server back to those particular moments in time. If you want to test the fact that these rollbacks are really working, you could go make some changes in the operating system at this time. Maybe create some files on the hard drive so that you can verify after accomplishing the rollback that those files have been removed.
- To rollback a VM to a previous checkpoint, simply right-click on the checkpoint that you want to recover, and choose Apply….
- DC3 is immediately reverted back to the standard checkpoint that we created a few minutes ago. It even has all of my applications still up and running on the screen, exactly as the machine was the moment that I created that checkpoint image.
- Now that we have successfully restored a standard checkpoint, let's try restoring the first checkpoint that we created, which was the new Production type. Our procedure is the same: right-click on the checkpoint file and choose Apply….
- This time, however, you will notice that the DC3 virtual machine has turned itself OFF when we chose to restore the checkpoint.
- Click the Start button to bring DC3 back to life, and it boots right up. But this is a fresh boot, not the immediate application-aware restore that happened with our first checkpoint rollback. The VM has now been restored back to that initial Production checkpoint we took. As you have seen, the major difference with our procedure here was that we had to turn the server back on following the restore process.
The capability in Windows Server 2016 Hyper-V to create Checkpoints is a very powerful one. Previous versions of Windows Server called this feature Snapshots, and for the most part Checkpoints work in exactly the same way. The major difference is that we now have two different types of images that we can create when we choose to Checkpoint our virtual machines.
Standard checkpoints are the same as our previous-generation snapshots—they allow for immediate rollback to an image file, keeping the VM online and running, and remembering even application-specific information when the rollback is finished. There is one major problem that has existed with snapshots, and will continue to be a problem with standard checkpoints. This is the issue where certain kinds of servers will fall out of sync with other servers when you apply standard checkpoints. You see, when you create standard checkpoints of servers like domain controllers or database servers, the file that is created is a simple snapshot from the Hyper-V Manager's level—it is supremely uninterested in what is going on inside the virtual machine or its own operating system at that moment in time. This means that, when you restore a standard checkpoint, it just lays the data back down exactly how it was before, with no consideration for the server or what function it performs. This often results in domain controllers falling out of sync with other DCs in your network, and data being skewed after the restore. This causes big problems for companies.
Production checkpoints are the new kid on the block, and are the default option for a reason. Even though they are slower to restore and your VM will shut itself down following the rollback of a production checkpoint, which results in downtime for this server, production checkpoints make use of backup and recovery tools like VSS inside the guest operating system. This means that those checkpoint files will be more comprehensible to the VM itself, and will recover more smoothly in a production environment.