6 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, N2WS needs an AMI to start the recovery of a Windows instance. N2WS 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, N2WS 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 N2WS 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 N2WS Thin Backup Agent.

The N2WS Thin Backup Agent is used for Windows instances that need to perform application quiescence using VSS or backup scripts.

  • The agent communicates with the N2WS Server using the HTTPS protocol.

  • No sensitive information passes between the backup agent and the N2WS Server.

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 to the backup targets page (section 4.2.2), the next step is to configure its agent by associating it with a cpmdata policy.

To associate an agent with the cpmdata policy:

  1. In the Policies tab, select the ‘cpmdata’ policy and then select Edit.

  2. In the Policy Details tab, select Application-Consistent.

By default, VSS quiescence will be activated for this policy.

If 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.

6.1.2 Downloading and Distributing the Agents Configuration

  1. You can download the installation package of the agent from the Agents tab in the left panel. Select Download Thin Backup Agent to download a standard Windows package (CPMAgentService.msi) to the Downloads folder.

  2. After downloading the agent installation package, select Server Settings and then select Agents Configuration.

  3. Enter the configuration syntax as described in Appendix B, and select Publish.

6.1.3 Installing the Agent

The agent can be installed on any Windows 2003, 2008, 2012, 2016, or 2019 instance, 32 or 64-bit. After accepting the license agreement, the Setup screen opens.

The required fields are:

  • The address of the N2WS 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 N2WS agent will be an automatic service in your Windows system.

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

6.1.4 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 that you make a copy of the cpmagent.cfg file, which resides in the N2WS Agent installation folder.

  2. If the address or port of the N2WS 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.

  4. As an alternative, you could uninstall and reinstall the agent.

6.1.5. Using the Agent with an HTTP Proxy

N2WS supports configurations where the backup agent for a Windows instance can reach the CPM server only through a proxy.

To configure the agent with an HTTP proxy:

  1. See section 6.1.4 about editing cpmagent.cfg, and:

  2. Add the following lines under the General section:

proxy_address=<dns name or ip address of the proxy server>
proxy_port=<port of the proxy (https)>

3. If your proxy server requires authentication, add the following two lines as well:

proxy_user=<proxy user name>
proxy_password=<proxy password>

4. 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.

N2WS supports VSS for backup on Windows Servers 2008, 2012, 2016, and 2019 only. Trying to run VSS on other 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 How N2WS Uses VSS

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

  • When N2WS initiates a backup, it requests the N2WS 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 N2WS 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 the last backup. Once the backup is complete, the N2WS agent will request the VSS Provider to delete the shadow copies. The N2WS 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 below.

6.2.2 Configuring VSS

By default, VSS is enabled when an N2WS 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:

  1. In the Instance and Volume configuration screen, change the value of Volumes for shadow copies.

  2. 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 UI.

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 of 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.

  • 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 view the errors that VSS encountered, look in the backup log.

  • To view the output of the exact VSS error, select Recover.

  • To view the VSS Disk Shadow log, select 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 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 N2WS. 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 N2WS should also occur here.

  • You may see failures in the 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 N2WS 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 N2WS is covered in section 10. 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, select 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}).

To revert 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.

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 that the volume the shadow copy is on is included in the backup and the recovery operation.

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 N2WS, 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 N2WS Thin Backup Agent.

  • If the N2WS 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 three 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, N2WS 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. However, N2WS cannot run PowerShell scripts directly as Windows scripts.

  • Scripts are launched by N2WS 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 must be set with exit code zero 0.

6.3.1 Before Script

The before_<policy-name>.<ext> runs before the 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 one 1. If it failed, crashed, or timed out, the argument will be zero 0.

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 one 1. If any issues or failures happened, it will be zero 0. If this argument is one 1, truncate logs.

When you enable backup scripts, N2WS 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 zero 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 N2WS Server. See section 4.2.4.