Overview
This article clarifies the "Not Scanned" status within the Druva Cyber Resiliency dashboard for VMware workloads. It is intended for backup administrators who see successful backup jobs with "UDA/Data Anomaly scan completed" but still observe a "Not Scanned" status on the Data Anomalies page.
User Scenario
An administrator has enabled Data Anomaly detection and sees successful scan logs in individual backup jobs. However, the Cyber Resiliency dashboard continues to report VMs as "Not Scanned" instead of "Healthy" or "Impacted."
Root Causes of "Not Scanned" Status
A VM is classified as Not Scanned when the system lacks sufficient eligible data to build a stable baseline. Common causes include:
Insufficient File Count: The snapshots do not meet the "Minimum Number of Files in Snapshot" threshold.
Learning Period Incomplete: There are not enough eligible snapshots within the "Data Backup Pattern Analysis Period."
Baseline Instability: Inconsistent backup patterns or varying data volumes prevent the algorithm from establishing a "Normal" state.
Configuration Mismatch: Changes to settings (like analysis windows) may exclude historical data that was previously eligible.
Procedure: Troubleshooting and Resolving "Not Scanned" Status
Prerequisites
Valid guest credentials must be configured for the VMware backup sets.
The VM Operating System must be supported for Data Anomaly scanning.
Ensure the "Data Anomaly" toggle is enabled at the workload or administrative group level.
Step 1: Verify Snapshot Eligibility (File Count)
The engine only uses snapshots that meet a specific file density to build a baseline.
Check the Minimum Number of Files in Snapshot setting (Default is typically 100).
Review your backup metadata. If a VM frequently backs up volumes with fewer files than this threshold, those snapshots are ignored for Cyber Resiliency reporting, even if the scan job technically "succeeded."
Step 2: Evaluate the Analysis Window (Learning Period)
The system requires a consistent history to move a VM out of the "Not Scanned" state.
Check the Data Backup Pattern Analysis Period (e.g., 30 days).
Ensure the VM has enough eligible snapshots (those passing the file count check) within this specific window.
Note: Reducing this window (e.g., from 30 days to 10 days) will immediately change how the dashboard evaluates the VM but will not trigger new scans on old data.
Step 3: Differentiate Job Status from Dashboard Status
It is important to understand the technical distinction between a scan and a classification:
Job Level: "UDA/Data Anomaly scan completed successfully" simply means the agent successfully parsed the snapshot.
Dashboard Level: "Not Scanned" means the Cyber Resiliency engine has determined the collected data is too sparse or too new to provide a reliable "Healthy" or "Impacted" verdict.
Precautions
Settings Changes: Changing Cyber Resiliency settings does not trigger retroactive scans. It only changes the "lens" through which existing scan data is viewed.
Manual Scans: You cannot manually force a "Not Scanned" VM into "Healthy" status; it must organically meet the baseline criteria through successive successful backups.