Overview
The Backup Window Expired (PHOENIX158) error occurs when a scheduled backup job exceeds the allocated time duration defined in the backup policy. When the policy time limit lapses, Druva Phoenix automatically terminates the job to prevent interference with business hours or subsequent operations.
Quick Diagnostic Checklist
Before troubleshooting workload-specific causes, perform these preliminary checks:
Verify System Clock & Time Zone:
Ensure the server's local time and time zone match the actual physical time. A time drift between the server and the Druva Cloud Console can cause jobs to expire prematurely.Check for Agent Service Issues:
If the Druva Phoenix agent service becomes unresponsive or hangs:
Open services.msc on the host server and stop the Druva Phoenix Services.
Open Task Manager and terminate any remaining processes (e.g., PhoenixFSAgent.exe or PhoenixSQLAgent.exe).
Restart the Druva Phoenix Services.
Verify First-Time Backup Settings:
For newly configured servers, verify whether "Ignore backup duration for first backup" is enabled in the Backup Policy. See First backup after configuration of the file server fails with Backup Window Expired.
Workload-Specific Causes & Resolutions
1. File Servers, SQL Server, Hyper-V, and NAS
Root Cause | Description | Recommended Resolution |
Increased Modified Data Load | Significant additions of new files, folders, databases, or VM disks cause scans and data transfers to take longer. | 1. Compare Data Scanned and Data Transferred in the Job Summary tab against previous successful runs.
2. Run an ad-hoc Backup Now manual job outside business hours to clear the initial delta buildup. |
USN Journal Mismatch / Size Limit | For incremental File Server backups, if the USN Journal fills up or resets, Phoenix falls back from a fast USNwalk to a slow Folderwalk. | 1. Check system event logs for USN Journal truncation.
2. Refer to File server backup fails with the Unable to query USN Journal error to increase USN journal size. |
High Ratio of Small Files | Datasets with millions of files smaller than 1 MB significantly increase file-scanning overhead. | 1. Extend the policy backup window.
2. Run a manual Backup Now run to establish a base state. |
Overlapping Scheduled & Manual Jobs | If a manual job (Backup Now) is active when a scheduled job triggers, the scheduled job stays Queued. If it dequeues near the end of the window, it expires shortly after starting. | Disable or reschedule conflicting automatic backups before launching large ad-hoc manual jobs. |
Hyper-V Resilient Change Tracking (RCT) Failures | If RCT fails or is unsupported (e.g., Windows Server 2012 R2 and older), Phoenix falls back to slower VSS-based full scans. | 1. Resolve Hyper-V VSS writer issues.
2. Upgrade older Hyper-V hosts to newer Windows Server versions supporting RCT. |
Large Virtual Memory Files | Large dynamic files like pagefile.sys or hiberfil.sys being included in backup sets increase total transferred volume. | Exclude paging/hibernation files or configure proper exclusions in the backup content rule. |
2. VMware Infrastructure
Root Cause | Description | Recommended Resolution |
CBT (Change Block Tracking) Issues | If CBT is corrupted or fails, Druva falls back to a full disk scan, heavily delaying completion. | 1. Initiate a manual Backup Now job.
2. Reset CBT for the affected VM in VMware vCenter, then trigger a full manual backup. For details, see Scenarios when incremental VM backup performance is impacted. |
Proxy Concurrency Bottlenecks | A single Druva VMware Backup Proxy processes a maximum of 3 VM backups concurrently. Excess VMs wait in queue and risk expiring. | Deploy additional Backup Proxies and group them into a pool. For setup guidelines, check the Backup Proxy Pool Details Page. |
Outdated Backup Proxy | Running an older Druva VMware Backup Proxy version can cause performance degradation or API incompatibilities with vSphere. | Upgrade the VMware Backup Proxy appliance to the latest release from the Druva Console. |
Transport Mode Fallbacks | Switching from high-speed HotAdd or SAN transport mode to slower NBD (Network) mode extends transfer durations. |
System Resource & Network Troubleshooting
Server & Resource Bottlenecks
CPU / Memory Pressure: High system utilization from other host applications starves the Druva Agent. Check Task Manager / Resource Monitor and adjust host resources or backup schedules according to the Druva Support Matrix.
Antivirus Interference: Antivirus real-time scanning can lock files or inspect Druva processes during scans. Review Avoiding third party/anti-virus interference with Phoenix Agent to configure proper exclusions.
Disk I/O Limitations: Insufficient IOPS on source storage delays read operations.
Network Health & Throughput
Dropped Network Connections: Frequent drops force packet retransmissions. Inspect log files for Dropped network connection errors and use diagnostics tools (Wireshark, ping -t, pathping) to check link stability.
Bandwidth & Speed Verification: Test upload/download throughput on the source host using the Cloud Harmony Tool.
See Also