Recovery Service Vaults Test

The values reported by this measure and its numeric equivalents are mentioned in the table below:

Note:

By default, this measure reports the Measure Values listed in the table above to indicate the current status of the recovery services vault. In The graph of this measure however, the same is represented using the numeric equivalents only.

Use the detailed diagnosis of this measure to know the location, tier, and recovery service type of the vault.

These measures represent the replication health of protected items - i.e., items that are replication-enabled - in the vault.

If an item is in the Critical state, it implies that one or more critical replication error symptoms have been detected in that item. These error symptoms are typically indicators that replication stuck, or not progressing as fast as the data change rate.

If an item is in the Warning state, it implies that one or more warning symptoms that might impact replication are detected in that item.

Ideally therefore, the value of these measures should be 0.

These measures represent the replication health of VMs in the vault.

If a VM is in the Critical state, it implies that one or more critical replication error symptoms have been detected in that VM. These error symptoms are typically indicators that replication stuck, or not progressing as fast as the data change rate.

If a VM is in the Warning state, it implies that one or more warning symptoms that might impact replication are detected in that VM.

Ideally therefore, the value of these measures should be 0.

System Center Data Protection Manager (DPM) is a robust enterprise backup and recovery system that contributes to your BCDR strategy by facilitating the backup and recovery of enterprise data.

With DPM running on a physical server or on-premises VM, you can back up data to a Recovery Services vault in Azure, in addition to disk and tape backup. You can deploy DPM on an Azure VM, and can back up data to Azure disks attached to the VM, or back up the data to a Recovery Services vault.

If the value of this measure grows consistently, it could imply that the vault is taking longer than usual to process backup jobs. This could warrant an investigation.

Ideally, the value of is vaulthis measure should be 0.

Geo-redundant storage (GRS) copies your data synchronously three times within a single physical location in the primary region using LRS. It then copies your data asynchronously to a single physical location in a secondary region that is hundreds of miles away from the primary region.

Compare the value of this measure with that of the Cloud - LRS measure to know which type of redundant storage is excessively utilized by the vault.

Locally redundant storage (LRS) replicates your data three times within a single data center in the primary region.

Compare the value of this measure with that of the Cloud - GRS measure to know which type of redundant storage is excessively utilized by the vault.

Data Deduplication, often called Dedup for short, is a feature that can help reduce the impact of redundant data on storage costs. When enabled, Data Deduplication optimizes free space on a volume by examining the data on the volume by looking for duplicated portions on the volume. Duplicated portions of the volume's dataset are stored once and are (optionally) compressed for additional savings.

If the values of these measures are low, while the values of the Cloud - GRS and Cloud - LRS are consistently growing, it could mean that enough data has not been deduplicated.

A high value is indicative of excessive disk space usage by the backup engine.

A recovery plan gathers machines into recovery groups for the purpose of failover. A recovery plan helps you to define a systematic recovery process, by creating small independent units that you can fail over. A unit typically represents an app in your environment.

A recovery plan defines how machines fail over, and the sequence in which they start after failover. Recovery plans can be used for both failover to and failback from Azure.

Ideally, the value of this measure should be 0.

If this measure reports a non-zero value, it could mean that one/more servers in the vault are missing some important updates. In such a case, it would be wise to update the servers without any delay, as outdated servers can cause backup/recovery failures.

Ideally, the value of this measure should be 0.

If the value of this measure grows consistently, it could imply that the vault is taking longer than usual to process recovery jobs. This could warrant an investigation.

You perform a failover as part of your business continuity and disaster recovery (BCDR) strategy.

As a first step in your BCDR strategy, you replicate your on-premises items to Azure on an ongoing basis. Users access workloads and apps running on the on-premises sources.

If the need arises, for example if there's an outage on-premises, you fail the replicating items over to Azure.

You run a test failover to validate your replication and disaster recovery strategy, without any data loss or downtime. A test failover does not impact ongoing replication, or your production environment. You can run a test failover on a specific virtual machine (VM), or on a recovery plan containing multiple VMs.

In principle, any backup or recovery failure (scheduled or user triggered) would lead to generation of an alert and would be shown as a Critical alert and also destructive operations such as delete backup.

Ideally therefore, the value of this measure should be 0.