Hyper-V Backup 

There are five major steps in the Hyper-V backup configuration. This section below explains the work flow of each functionality along with the guidelines.

• Configuring Virtual Machines
• Guest Processing
• Scheduling Backup
• Settings
• Reviewing your selections

You can configure the Hyper-V backup from a Hyper-V Cluster (or) Standalone Hyper-V server (or) SMB server.

Generally, When you add a Hyper-V host through Vembu BDR server for backup Vembu Integration Service agent will be automatically installed in the Hyper-V host, this VIS agent is mandatory for both backup and restore process.

We recommend configuring Host level backups, to ensure all the VMs of Hypervisor can be restored at any point of time

Configuring Virtual Machines

Read this section to know about the stepwise process of configuring VM’s

VM or Disk Exclusion

• You can exclude a particular Disk type either at the host level or VM level using Disk Exclusion option. Under the Exclude Disk(s) tab, you will find the configured host(s) listed. If you have selected Host Level backup, you might want to exclude a specific set of VMs from the backup process. Such VMs can be excluded using VM(s)/Disk(s) exclusion option.
• You can also backup only the System disk, this option allows you to include only the System Disks Generally (0:0) (i.e) the disk that contains the machine configuration and OS files and excludes all the other disks in the machine,

Working of Exclusion

The Exclusion option explains the Working:

• The details regarding the exclusion configuration will be stored in the exclusion_details database.

The following will be checked

• Disk Type (IDE, SCSI) with their control location and control number
• Exclusion Level (Host or VM Level)
• Exclusion Type

The list of disks that are available in the VM will be checked. For example, VM (0:0, 0:1, 0:2) these disks availability will be checked and excluded before the backup data is sent to the Vembu BDR backup server.

Exclude the Page files from the backup job to reduce the Incremental backup size.

Guest Processing - Application Aware

Read this section to know more about Guest Processing

We recommend enabling the Application-aware option for Backup consistency.

Application-Aware 

Application-Aware is a feature available for Hyper-V environments handling high-end application servers. Microsoft Exchange Server, SQL Server, Active Directory, SharePoint are some of the data sensitive applications that require prior steps to be taken before configuring a backup, for data consistency

Vembu BDR server will keep constant communication with Microsoft VSS that ensures all pending application transactions are either committed or rolled back before proceeding with the VM snapshots for backup. This ensures backup data stays uncorrupted for restore.

In Windows environment, Vembu BDR backup server connects to the guest OS through the IP address obtained. It then performs the guest processing if application-aware is enabled. You must provide the Guest OS credentials if you have enabled the Application Aware Settings. Vembu BDR backup server verifies the credentials, in case the credentials are wrong, your backup will fail.

We recommend you to provide correct credentials for the Guest OS machines.

Working of Application-aware

• Vembu BDR backup server checks if the Appwareguestool.exe is present in C:\Windows.
• If the .exe file is not present, then appaware folder will be created and Appawareguestool.exe will be copied at C:\Windows\Appaware. After completion of the above process, the Appawareguestool.exe will be installed with the associated .dll files and VSSRequestor.exe. This VSSRequestor.exe will be used to check the VSS writer status and update in the status.txt file.  
• If the .exe file is already present, it will install the necessary .dll files and VSSrequestor.exe, the VSSRequestor.exe will be used to check the VSS writer status and update in the status.txt file. 
• This process ensures the writer stability. From the C:\Windows\Appaware\status.txt file will be read to check if the status of VSS writers are stable or not. The log truncation takes place at the end of the backup.
• No ports are necessary to be open between the Vembu BDR backup server and VM for Guest OS processing.
• The user should have native administrator privilege on the guest OS to process Application-aware.

The following versions of Microsoft Exchange Server are supported:

• Microsoft Exchange 2016
• Microsoft Exchange 2013 SP1
• Microsoft Exchange 2013
• Microsoft Exchange 2010 SP1, SP2, or SP3

The following versions of Microsoft SharePoint Server are supported:

• Microsoft SharePoint 2016
• Microsoft SharePoint 2013
• Microsoft SharePoint 2010

The following versions of Microsoft SQL Server are supported:

• Microsoft SQL Server 2016
• Microsoft SQL Server 2014
• Microsoft SQL Server 2012
• Microsoft SQL Server 2008 R2
• Microsoft SQL Server 2008

The following versions of Microsoft Active Directory are supported:

• Microsoft Windows Server 2016
• Microsoft Windows Server 2012 R2
• Microsoft Windows Server 2012
• Microsoft Windows Server 2008 R2
• Microsoft Windows Server 2008

Configuring Backup Schedule

When you trigger a backup job for the first time, a full backup will be performed. The backup data is read as a whole data and is stored as chunk files (SGCF) and FBM (Full backup Metadata)  file in your storage repository. The data will be compressed and when a new full backup is triggered, a completely new backup chain will be formed.

We have three options for scheduling your Hyper-V backup, they are - Run Every, Run Daily, Run Weekly. Schedule frequency begins from 15 minutes, select this option only for your critical VMs as RPO will be less than 15 minutes.

Read more on the  Steps of configuring backup schedule

Configuring Settings

Read more to know about the setting and retention policies - Settings

We recommend you to use separate storage for backup jobs. Do not combine your backup data with production data

We do not recommend choosing the OS partition as a storage repository.

Retention

If you have configured retention policies, the previous full backup will be purged according to the retention settings. Note that the incremental backup will be generated based on the changes that happen in the initial full backup and depend on them. Once the full backup schedule is completed, the incremental backups will start. They will be stored in the storage repository as Chunk Files (SGCF).

The backup data is stored in the storage repository in a compressed format. The backup data is compressed so that the amount of data transferred across the LAN is reduced. The compression takes place at the block level using the AES-256 bit algorithm.

If your aim is to store more space efficiently, you can opt for the Forever Incremental process. In this process, only one full backup will be created and from there on, only incrementals will happen.

Since there is only one full backup created in the storage repository, you save a lot of space. Based on the previous incremental file the next incremental file will be created thereby maintaining the backup chain.

We do not recommend to use this method if the incremental changes are frequent, as the merge process takes time.  

Encryption Best Practices

Encryption protects your data from unauthorized users and intruders. Using the AES-256 bit encryption algorithm, your backup data will be encrypted both at rest and on the fly. Without the encryption key, access to the backup data will be blocked. This ensures your backup files are secure.

By default, your backups will be encrypted using the system-generated password even if Encryption is disabled. You can opt to a custom password for extended data protection and you will be required to provide it during recovery. Opting to the custom password will disable integrity check from being performed automatically.

We do not recommend using the same name for Password and its hint to avoid security issues.

You can configure encryption in two ways 

• When you configure the backup schedule
• From the Settings tab, you can select Data Encryption.

Reviewing your selections

The final step in your backup configuration is to review the backup job details. In this backup job summary page, we recommend assigning a unique name to your backup job for future references.

Hyper-V Backup Anatomy

This section explains the detailed work-flow of Hyper-V backup 

Full backup

• Once you have configured the backup job, Vembu BDR server triggers the Full backup and checks for CBT driver in the Hyper-V host. If CBT driver is not available, it will install and load the CBT driver in the corresponding Hyper-V host.
• Vembu BDR server analyses the VM and Disk list (Validation of VM) available for backup, then VSS snapshot will be triggered for the affected volumes. Once the snapshot is created, the CBT driver will track the changes/modification in the disk. As per the below steps,
• The changed block info will be saved in .dat file for each VM and each disk in VMs (.dat file will be created for each disk individually).
• Simultaneously, the backed up data checksum info will be tracked in .dbcm file (if CBT fails, checksum carries out the incremental tracking process).
• Disk data will be read and the backed up data will be stored in the chunk file(SGCF) format. Once the disk read completes the snapshot will be deleted. Database updation takes place and the backup job gets completed successfully

Incremental backup

• The Incremental backup gets triggered according to the backup schedule configured. Vembu BDR server checks for the CBT driver again (takes place for every backup schedule).
• Vembu BDR server validates the VM and disk list for the backup process. Once the validation is completed, the VSS snapshot is created for the affected volumes.
• Changed/Modified blocks information will be gathered from the .dat file for every disk in the VM, by copying the .dat file. 
• If CBT tracking fails for the incremental schedule, the incremental will proceed with the checksum for a particular schedule. For the next incremental schedule, CBT tracking will be initiated.
• Disk data will be read and the incremental backup data will be stored as chunk file (SGCF) format. Once the disk read completes the snapshot will be deleted. Database updation takes place. 
• Once the DB update is executed your incremental backup schedule is completed successfully

We recommend you to ensure that your backups utilize the available disk space efficiently.