vRanger 7.8 - User Guide

Determining application consistency

The levels of, and methods for providing, application consistency differ between VM backups and backups of physical servers. For more information, see the following topics:

•	Application consistency for virtual backups

•	Application consistency for physical backups

Application consistency for virtual backups

vRanger provides various levels of protection for VMs. The means that each level uses to accomplish its task depends on the type of VM being protected.

•	Application consistency for VMware VMs

•	Application consistency for Hyper-V VMs

Application consistency for VMware VMs

By default, vRanger does not provide quiescing during backups. When you enable the Enable Guest Quiescing option, quiescing in vRanger is provided by leveraging the VMware® Tools installed in the VM.

This feature can provide three different levels of backup consistency:

•

Crash consistent: A crash-consistent backup is analogous to pulling the plug on a server and then backing up the data. The state of the data that is being backed up with respect to the users of the data is indeterminate. Restoring a crash-consistent image is equivalent to rebooting a server after a hard shut-down.

•

File-system consistent: File-system consistency is achieved through standard quiescing by using the VMware Sync Driver, which ensures that no file-system writes are pending when the snapshot is taken. For normal VMs, file-system consistency is adequate, although it can cause corruption in database applications.

•	Application consistent: Consistency of VSS-compatible applications is achieved by freezing application I/Os prior to creating the VM snapshots. This option ensures that all application writes requests in the machines memory are committed to disk before the snapshot is taken.

The level of consistency provided by the Enable Guest Quiescing option depends on the version of VMware® ESXi™ — and the corresponding VMware Tools — and the guest operating system. The following table provides more detail on what is needed to achieve various levels of consistency:

 

Table 1. Achieving consistency

File-level quiescing
	ESXi 6.0	ESXi 6.5	ESXi 6.7
Windows Server 2008 R2 SP1	VMware VSS	VMware VSS	VMware VSS
Windows Server 2012 Windows Server 2012 R2	VMware VSS	VMware VSS	VMware VSS
Windows Server 2016	VMware VSS	VMware VSS	VMware VSS
Application-level quiescing
	ESXi 6.0	ESXi 6.5	ESXi 6.7
Windows Server 2008 R2 SP1	vzShadow.exe	vzShadow.exe	vzShadow.exe
Windows Server 2012 Windows Server 2012 R2	vzShadow.exe	vzShadow.exe	vzShadow.exe
Windows Server 2016	vzShadow.exe	vzShadow.exe	vzShadow.exe

As shown in the preceding table, application consistency is not always available with the basic quiescing options. In these situations, you may use the vRanger VSS Tools — vzShadow.exe — for application-level consistency.

IMPORTANT: Due to the database architecture, vRanger cannot take application-consistent backups of vCenter Server Appliance (VCSA) VMs. Use caution when backing up a VCA VM to ensure reliable recovery.

IMPORTANT: Application-consistent backups are not available for encrypted VMs.

Application consistency for Hyper-V VMs

vRanger can provide two levels of consistency for Hyper-V® VM backups: file-system consistency and application consistency.

•

Crash consistent: A crash-consistent backup is analogous to pulling the plug on a server and then backing up the data. The state of the data that is being backed up with respect to the users of the data is indeterminate. Restoring a crash-consistent image is equivalent to rebooting a server after a hard shut-down.

•

Application consistent: vRanger engages the Microsoft Volume Shadow Copy Services (VSS) to put supported applications into a consistent state during a backup. This option ensures that all application writes requests in the machines memory are committed to disk before the snapshot is taken, which means that the application and data can be reliably recovered from the backup archive.

To achieve either type of application consistency, you must comply with the following requirements:

•	The guest must be operating a Windows® operating system.

•	The guest operating system must have Hyper-V Integration Services installed.

The vRanger agent installed on the Hyper-V host uses the VSS native to the Windows operating system to support the truncation of any supported application transaction logs. Log truncation automatically frees space in the logical log for the transaction log to reuse.

 

IMPORTANT: Backing up a Hyper-V VM using a VSS writer requires a minimum of 300 MB free space on the volume being backed up. If there is less than 300 MB of available space on the volume, the backup job fails with an error message.

 

NOTE: For more information on Hyper-V backups and VSS, see https://msdn.microsoft.com/en-us/library/dd405549(v=vs.85).aspx.

Application consistency for physical backups

vRanger can provide two levels of consistency for physical backups: crash consistent and application consistency.

•	File-system consistent: File-system consistency is achieved without any additional tools or configurations. File-system consistency ensures that no file system writes were lost during the backup process.

•

Application consistent: vRanger engages the Microsoft VSS to put supported applications into a consistent state during a backup. This option ensures that all application writes requests in the machines memory are committed to disk before the snapshot is taken, which means that the application and data can be reliably recovered from the backup archive.

For physical backups, vRanger also supports — through VSS — the truncation of any supported application transaction logs when the VSS snapshot is creating. Log truncation automatically frees space in the logical log for reuse by the transaction log.

Understanding retention policies and space-saving technologies

vRanger retention policies define the minimum number of restorable savepoints to keep in a repository for a backup job. The number of savepoints retained depends on the type of backups being performed — full, differential, or incremental — and where in the full-differential or full-incremental cycle the retention check is being performed.

 

NOTE: vRanger does not retire an expired savepoint if that savepoint is required to restore a differential or incremental savepoint still within the retention period.

A key concept in discussing retention policies is the notion of a “backup set.” A backup set is several savepoints that are grouped for two reasons: The first is to implement the retention policy; and the second is to maintain the parent-child relationships that exist when you choose to use differential or incremental backups. The backup set for each type of backup is different.

•	Full backups: Each savepoint is a complete backup set. Deleting a savepoint has no bearing on the recoverability of any other full savepoint.

•	Incremental backups: Incremental backup jobs backup only the blocks that have changed since the last backup — full or incremental. Restoring an incremental savepoint requires the parent full and every incremental between the full and the selected incremental.

•

Differential backups: A differential backup contains the data that has changed since the last full backup. Each differential backup includes the contents of the previous differential, which in retention terms means that only the parent full and the most recent differential are required for a restore.

Full backups

A backup job consisting only of full backups is the simplest case for retention policy configuration. Each savepoint is independent of the other savepoints, and can be retired without affecting any other savepoints. In other words, a backup set for full backups is equal to one savepoint — only one savepoint is required for a restore.

The following scenario depicts a daily full backup job, with a Savepoint Count of 7:

•	Day 1: A full backup is taken.

•	Day 2: A full backup is taken.

•	Day 3: A full backup is taken.

•	Day 4: A full backup is taken.

•	Day 5: A full backup is taken.

•	Day 6: A full backup is taken.

•	Day 7: A full backup is taken.

•	Day 8: A full backup is taken. The savepoint from Day 1 is removed.

•	Day 9: A full backup is taken. The savepoint from Day 2 is removed.

Incremental backups

Incremental backup jobs back up only the blocks that have changed since the last backup — whether it was full or incremental. Restoring an incremental savepoint requires the parent full and every incremental between the full and the selected incremental.

The following scenario depicts a daily incremental backup job, with a Savepoint Count of 7 and a Threshold Count of 6:

 

Table 2. Incremental backup retention example

Day	Action
1	A full backup is taken.
2	An incremental backup is taken.
3	An incremental backup is taken.
4	An incremental backup is taken.
5	An incremental backup is taken.
6	An incremental backup is taken.
7	An incremental backup is taken.
8	A full backup is taken.
9	An incremental backup is taken.
10	An incremental backup is taken.
11	An incremental backup is taken.
12	An incremental backup is taken.
13	An incremental backup is taken.
14	An incremental backup is taken. All savepoints from Day 1 to Day 7 are removed.
15	A full backup is taken.

Differential backups

Differential savepoints require the parent full backup and the selected differential savepoint to restore. Each differential backup includes the contents of the previous differential, which means, in terms of retention, that only the parent full and the most recent differential are required for a restore.

The following scenario depicts a daily differential backup job, with a Savepoint Count of 7, a Threshold Count of 6, and a Threshold Size of 50%:

 

Table 3. Differential backup retention example

Day	Action
1	A full backup is taken.
2	A differential backup is taken.
3	A differential backup is taken.
4	A differential backup is taken.
5	A differential backup is taken.
6	A differential backup is taken.
7	A differential backup is taken.
8	A full backup is taken. The differential savepoint from Day 2 is removed.
9	A differential backup is taken. The differential savepoint from Day 3 is removed.
10	A differential backup is taken. The differential savepoint from Day 4 is removed.
11	A differential backup is taken. The differential savepoint from Day 5 is removed.
12	A differential backup is taken. The differential savepoint from Day 6 is removed.
13	A differential backup is taken.
14	A differential backup is taken. The differential savepoint from Day 7 and the full savepoint from Day 1 are removed.