06. Windows Instances Backup

Contents

 

Windows Instances Backup

From the point of view of the AWS infrastructure, there is not much difference between backing up Linux/Unix instances or Windows instances. You can still run snapshots on EBS volumes. However, there is one substantial difference regarding recovering instances:

  • In Unix/Linux instances, you can back up system volumes (root devices), and later launch instances based on the snapshot of the system volume. You can create an image (AMI) based on the system volume snapshot and launch instances.
  • This option is currently not available for Windows Servers. Although you can take snapshots of the system volume of a Windows Server, you cannot create a launchable image (AMI) from that snapshot.

Because of this limitation, CPM needs an AMI to start a recovery of a Windows instance. CPM will still make sure all the volumes, including the root device (OS volume) will be from the point-in-time of the recovered backup. By default, CPM will create an initial AMI when you start backing up a Windows instance. That AMI will be used as the default when recovering this instance.

 

6.1 – Configuring CPM Thin Backup Agent

If crash-consistent backup is sufficient for your needs, you do not need to install any agent. However, to use VSS or run backup scripts, you will need to install CPM Thin Backup Agent. Any Windows instance in a policy can have a backup agent associated with it.

 

6.1.1 – Associating an Agent with a Policy

After adding your Windows instance in the backup targets page (see section 4.2.2), the next step is to configure its agent by associating it with a policy.

 

To associate an agent with a policy:

  • In the instance target line, select the Configure check box. The Policy Instance and Volume Configuration screen opens.

06. Windows Instances Backup

Figure 6‑1

  1. In the Application-consistent backup list, select Enabled. The fields relevant for configuring an application aware backup will appear:
    • Enable VSS on Agent – By default, VSS quiescence will be activated for this policy.

    Note: In case the agent represents a Windows 2003 instance, VSS will fail every time. You need to turn off this option and use only backup scripts. If you have a Windows 2003 instance and you do not need scripts, there is no use installing an agent, so just perform backups without one.

    • Volumes for shadow copies – (This option is used only if VSS is enabled.) If you leave this field empty, VSS will create shadow copies of all of the volumes of this instance. If you want it to create shadows for only part of the volumes, you can type in drive letters with commas between them, e.g. C:, D:. For more information about VSS, see chapter 6.
    • Backup Scripts – Whether to enable running backup scripts locally on the Windows instance.
    • Scripts Timeout – The time given for a script to run before the CPM terminates it.
    • Script Output – Whether to capture the output of the scripts as a log. It will capture anything the script printed to the stderr socket. The log will be viewable from the recovery panel screen.

 

6.1.2 – Installing the Agent

You can download the installation package of the agent from the link download thin backup agent at the bottom of CPM’s main screen. It will download a standard Windows msi package. The agent can be installed on any Windows 2003, 2008, 2012, or 2016 instance, 32 or 64-bit. After accepting the license agreement, the Setup screen opens.

06. Windows Instances Backup

Figure 6‑2

 

The required fields are:

  • The address of the CPM server that is reachable from this instance.
  • The default port is 443 for HTTPS communication. Change it if you are using a custom port.

 

After finishing the installation, the CPM agent will be an automatic service in your Windows system.

Important: After the Agent is installed and configured and a policy with target that points at it is configured and enabled, the users must wait to see it registered in the remote agent screen in the CPM. It may take a few minutes until the CPM connects.

 

6.1.3 – Changing Agent Configuration

To change the configuration of the backup agent after installation, edit the backup agent configuration file.

 

To change the agent configuration file:

  1. Before proceeding, it is recommended to make a copy of the cpmagent.cfg file, which resides in the CPM Agent installation folder.
  2. If the address or port of the CPM Server had changed, edit the agent configuration file manually. Make the change after the equation sign.
  3. After making the changes, restart the CPM Agent Service, in the Windows Service Manager console.
    • As an alternative, you could uninstall and reinstall the agent.

 

6.1.4 – Using the Agent with an HTTP Proxy

If the Windows instance the agent is installed on can reach the CPM server only through a proxy, CPM agent supports such a configuration.

 

To configure the agent with an HTTP proxy:

  • See section 6.1.4 about editing cpmagent.cfg, and:
    • Add the following lines under the general section:
proxy_address=<dns name or ip address of the proxy server>

proxy_port=<port for the proxy (https)>

 

  • If your proxy server requires authentication, add the following two lines as well:
proxy_user=<proxy user name>

proxy_password=<proxy password>
  • Restart the CPM Agent service from the Windows Service Manager.

 

 

6.2 – Using VSS

VSS, or Volume Shadow Copy Service, is a backup infrastructure for Windows Servers. It is beyond the scope of this guide to explain how VSS works. You can read more at http://technet.microsoft.com/en-us/library/cc785914%28v=WS.10%29.aspx. However, it is important to state that VSS is the standard for Windows application quiescence, and all recent releases of many of the major applications that run on Windows use it, including Microsoft Exchange, SQL Server, and SharePoint. It is also used by Windows versions of products not developed by Microsoft, like Oracle.

 

CPM supports VSS for backup on Windows Servers 2008 or 2012 only. Trying to run VSS on older Windows OSs will always fail. VSS is turned on by default for every Windows agent. For unsupported OSs, you will need to disable it yourself. This can be done in the instance configuration screen, see section 6.1.1.

Any application that wishes to be backup aware has a component called VSS Writer. Every vendor who would like to support copying the actual backup data (making shadow copies) provides a component called a VSS Provider. The operating system comes with a System Provider, which knows how to make shadow copies to the local volumes. Storage hardware vendors have specialized Hardware Providers that know how to create shadow copies using their own hardware snapshot technology. Components that initiate an actual backup are called VSS Requestors.

When a requestor requests a shadow copy, the writers flush and freeze their applications. At the point of time of the shadow copy, all the applications and the file systems are frozen. They all get thawed after the copy is started (copy-on-write mechanisms keep the point in time consistent, similar to EBS snapshots). When the backup is complete, the writers get notified that they have a consistent backup for the point in time of the shadow copy. For example, Microsoft Exchange automatically truncates its transaction logs when it gets notified that a backup is complete.

6.2.1 – CPM’s Use of VSS

The CPM Agent performs under the role of a VSS Requestor to request the VSS System Provider to perform shadow copies. The process is:

  • When CPM initiates a backup, it requests the CPM Backup Agent to invoke a backup of all relevant volumes. The agent then requests the VSS System Provider to start the shadow copy.
  • VSS only creates differential copies, which means that in order for the CPM to fully backup each volume, a few extra MBs are needed for the backup to complete. The amount of MBs depends on the size of the volume and the amount of data written since last backup. Once the backup is complete, the CPM agent will request the VSS Provider to delete the shadow copies. The CPM Agent will notify all relevant VSS writers that the backup is complete, only after making sure all the EBS snapshots are completed successfully.

 

You can see the process depicted in Figure 6‑3.

 

06. Windows Instances Backup

Figure 6‑3

 

6.2.2 – Configuring VSS

By default, VSS is enabled when a CPM Thin Backup Agent is associated with an instance in a policy. In many cases, you will not need to do anything. By default, VSS will take shadow copies of all the volumes. However, you may want to exclude some volumes. For example, since the system volume (typically C:\) cannot be used to recover the instance in a regular scenario, you may want to exclude it from the backup.

 

To make shadow copies of only some of the volumes:

  • In the Instance and Volume configuration screen, change the value of Volumes for shadow copies.
  • Type drive letters followed by a colon, and separate volumes with a comma, e.g. D:, E:, F:.

 

6.2.3 – Excluding and Verifying VSS Writers

Writer exclusions and inclusions are configured using a text file, not the GUI.

 

You may wish to exclude VSS Writers from the backup process in cases where the writer is:

  • Failing the backup.
  • Consuming too many resources.
  • Not essential for the backup’s consistency.

To exclude VSS writers:

In the subfolder scripts under the installation folder of the Thin Backup Agent (on the backed-up instance), create a text file named vss_exclude_writers_<policy name>.txt. with the following structure:

  • Each line will contain a writer ID (including the curly braces)
  • If you write in one of the lines all, all writers will be excluded. This can be handy sometimes for testing purposes.

 

In some cases, you want to make sure that certain writers are included (verified) in the shadow copy, and if not, fail the operation.

To verify writers:

In the subfolder scripts under the installation folder of the Thin Backup Agent (on the backed-up instance), create a text file named vss_verify_writers_<policy name>.txt with the following structure:

  • Each line will contain a writer ID (including the curly braces).
  • all is not an option.

 

An example for a line in either of the files is:

{4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f}

 

6.2.4 – Troubleshooting VSS Issues

When a VSS-enabled policy runs, you will see its record in the backup monitor tab of CPM’s main screen.

  • If it finished with no issues, the status of the record will be Backup Successful.
  • If there were issues with VSS, the status will be Backup Partially Successful.

 

To troubleshoot:

  • To see the errors that VSS encountered, look in the backup log.
  • To see the output of the exact VSS error, click Recover.
  • To view the VSS Disk Shadow log, click its link in the recovery panel. There is a link for each of the agents in the policy, with the instance ID stated.
  • In most cases, VSS will work out of the box with no issues. There can be a failure from time to time in stressed system conditions.
  • If the writers do not answer to the freeze request fast enough, the process times out and fails. Often, the retry will succeed.
  • When VSS is constantly failing, it is usually a result of problems with one of the writers. This could be due to some misconfiguration in your Windows system.
  • In most cases the problem is out of the scope of CPM. The best way to debug such an issue is to test VSS independently. You can run the Diskshadow utility from a command line window and use it to try and create a shadow copy. Any issue you have with VSS using CPM should also occur here.
  • To learn how to use the Diskshadow utility, see: https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/diskshadow
  • You may see failures in backup because VSS times out or is having issues. You will see that the backup has status Backup Partially Successful. Most times you will not notice it since CPM will retry the backup and the retry will succeed.
  • If the problem repeats frequently, check that your Windows Server is working properly. You can check the application log in Window’s Event Log. If you see VSS errors reported frequently, contact N2W Software support.

 

6.2.5 – VSS Recovery

Recovering instances using CPM is covered in chapter 9. When recovering a Windows Server that was backed up with VSS, you need to revert back to the shadow copies in the recovery volumes to get the consistent state of the data.

To revert back to shadow copies after VSS recovery:

  1. Connect to the newly recovered instance.
  2. Stop the services of your application, e.g. SQL Server, Exchange, SharePoint, etc.
  3. Open an administrator command line console and type diskshadow.
  4. In the recovery panel screen, click the VSS DiskShadow Data link to find the IDs of the shadow copies made for the required backup.
  5. Type revert {shadow id} for each of the volumes you are recovering, except for the system volume (C: drive). After finishing, the volumes are in a consistent state.
  6. Turn the services on and resume work.

 

If you wish to recover a system disk, it cannot be reverted to the shadow copy using this method. The system volume should not contain actual application data as it is not a recommended configuration, and, therefore, you should be able to skip this revert operation. However, you can expose the system disk from the shadow and inspect its contents.

To expose the system disk from the shadow:

  1. In the diskshadow utility, type: expose {shadow id} volletter:
  2. After finishing, remember to unexpose the disk.
  3. To avoid unnecessary resource consumption, delete the shadow: (delete shadow {shadow id}).

 

Reverting to a shadow copy for a system volume

If you have a strict requirement to recover the consistent shadow copy for the system volume as well, do the following:

  1. Before reverting for other volumes, stop the instance; wait until it is in stopped state.
  2. Using the AWS Console, detach the EBS volume of the C: drive from the instance and attach it to another Windows instance as an “additional disk”.
  3. Using the Windows Disk Management utility, make sure the disk is online and exposed with a drive letter.
  4. Go back to the process in the previous section (VSS Recovery), and revert to the snapshot of drive C which will now have a different drive letter. Since it is no longer a system volume, it is possible to do so.
  5. Detach the volume from the second Windows instance, reattach to the original instance using the original device, which is typically /dev/sda1, and turn the recovered instance back on.

Note: Shadow copy data is stored by default in the volume that is being shadowed. However, in some cases it is stored on another volume. In order for you to be able to recover, you need to make sure you also have the volume the shadow copy is on included in the backup and the recovery operation.

Important: If you revert a volume that contains another volume’s shadow data the reversion will take the volume to a state where it no longer contains the second volume’s backup data, as the second volume would need to be reverted before the first volume can be reverted. If you accidentally restore the shadow copies in the wrong order, just delete the recovered instance and its data volumes and begin the recovery operation again from CPM, taking care to revert the shadow copies in the correct order.

 

 

6.3 – Using Backup Scripts on Windows

  • Besides VSS, there is also the option to run backup scripts to achieve backup consistency. It is also possible to add backup scripts in addition to VSS.
  • You enable backup scripts in the Instance and Volume Configuration screen of the instance in the policy.
  • As opposed to Linux, Windows backup scripts run directly on the agent. All the scripts are located in the subfolder scripts under the installation folder of CPM Thin Backup Agent.
  • If the CPM user that owns the policy is not the root user, the scripts will be under another subfolder with the user name (e.g. …\scripts\cpm_user1).
  • All scripts are named with a prefix plus the name of the policy.
  • There are 3 types of events. If scripts are used, a script must be provided for each of these events. If all of the scripts are not defined, CPM will treat the missing script as a failing script.
    • Before the VSS backup – BEFORE_<policy name>.<ext>
    • After the VSS backup started – AFTER_<policy name>.<ext>
    • After the VSS backup has completed. COMPLETE_<policy name>.<ext>
  • Scripts can have any extension as long as they are executable. They can be batch scripts, VBS scripts, Power Shell, or even binary executables.
  • Scripts are launched by CPM Thin Backup Agent, so their process is owned by the user that runs the agent service. By default, this is the local system account. However, if you need to run it under a different user you can use the service manager to change the logged-on user to a different one. For example, you might want to run it with a user who has administrative rights in a domain.
  • All scripts need to exit with the code 0 when they succeed, or 1 (or another non-zero code) when they fail.

 

6.3.1 – Before Script

The before_<policy name>.<ext> runs before backup begins. Typically, this script is used to move applications to backup mode. The before script leaves the system in a frozen state. This state will stay for a very short while, until the snapshots of the policy start, which is when the after script is started.

 

6.3.2 – After Script

The after_<policy name>.<ext> script runs after all the snapshots of the policy start. It runs shortly after the before script, generally less than 2-3 seconds. This script releases anything that may have been frozen or locked by the before script.

 

This script accepts the success status of the before script. If the before script succeeded, the argument will be 1. If it failed, crashed, or timed out, the argument will be 0.

Note: This is the opposite of the exit status. Think of it as an argument that is true when the before script succeeded.

 

6.3.3 – Complete Script

The complete_<policy name>.<ext> script runs after all snapshots are completed. Usually the script runs quickly since snapshots are incremental. This script can perform clean-up after the backup is complete and is typically used for transaction log truncation.

 

The script accepts one argument. If the entire backup was successful and all the previous scripts were successful, it will be 1. If any issues or failures happened, it will be 0. If this argument is 1, truncate logs.

Important: When you enable backup scripts, CPM assumes you implemented all three scripts. Any missing script will be interpreted as an error and be reflected in the backup status. Sometimes the “complete” script is often not needed. In this case, write a script that just exits with the code 0, and the policy will not experience errors.

 

6.3.4 – Capturing the Output of Backup Scripts

You can have the output of backup scripts collected and saved in the CPM Server. See sections 7.2.4 and 4.2.5.