Chat now with support
Chat mit Support

vRanger 7.8.2 - User Guide

Introduction vRanger overview Configuring vRanger
Configuring vRanger through the Startup Wizard Configuring vRanger manually Supplemental instructions: additional repository types
Using vRanger Backup Restore
Restoring an encrypted VMware VM Performing a full restore for VMware VMs Performing a full restore for Hyper-V® VMs Performing a full restore for VMware vApps Performing a full restore of a physical machine Performing an FLR on Windows Performing an FLR on Linux Restoring from manifest
Replicate VMs Reports Integrating and monitoring vRanger Using the vRanger Console vAPI Cmdlet details About us

Application consistency for physical backups

Previous Next


Backup > Determining application consistency > Application consistency for physical backups

Application consistency for physical backups

vRanger can provide two levels of consistency for physical backups: crash consistent 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 shutdown.
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

Previous Next


Backup > Understanding retention policies and space-saving technologies

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.

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.

Performing optional configurations

Previous Next


Backup > Performing optional configurations

Performing optional configurations

Before you set up a backup job, you may want to make the following optional vRanger configurations:

Enabling VMware Changed Block Tracking (CBT)

Previous Next


Backup > Performing optional configurations > Enabling VMware Changed Block Tracking (CBT)

Enabling VMware Changed Block Tracking (CBT)

VMware® CBT reduces the time needed for incremental and differential backups by only backing up the portions of a disk that have changed since the last backup. By determining which blocks changed within the VMDK file, vRanger only backs up the portions of a disk that have changed since the last backup. This often results in shorter backup operations, and reduced resource consumption on network and storage elements.

VMware vSphere® supports CBT, and most VMs running in this environment can use it. The VMs must be Hardware Version 7 or later, and have been created and hosted in VMware® ESXi™ 6.0 or later hosts. VMs that are created in VMware® ESX® 4 or earlier must be migrated to Hardware Version 7 or later for CBT to be supported. CBT must be enabled for each VM with which CBT is to be used.

Change Block Tracking is enabled or disabled on a per-VM basis. There are two methods to enable CBT:

In the Options Selection page of the vRanger Backup Wizard, select Enable Change Block Tracking.
In the My Inventory view, right-click the VM for which want to change the CBT setting, and then select Enable Change Tracking. The Changed Block Tracking Icon appears next to any VM on which CBT is enabled.
Verwandte Dokumente

The document was helpful.

Bewertung auswählen

I easily found the information I needed.

Bewertung auswählen