Problem description

Phoenix backups can fail with the Backup Window expired - PHOENIX158 error for various reasons depending upon the workload for which the backups are configured. The jobs generally fail if the backup window set in the backup policy lapses while the backup is in progress.

Cause

Workloads: File servers, SQL, Hyper-V, NAS

Cause	Possible solutions
If this is the first backup of a server and the Ignore backup duration for first backup setting in the backup policy is unchecked.	See First backup after configuration of the file server fails with Backup Window Expired
Server resources	Backups may fail if: The CPU, RAM, and Space on the Disk are insufficient. See Support Matrix. Other applications on the source server are consuming excessive CPU and RAM. You can check this from Task Manager > More details > Sort by CPU or Memory to determine applications consuming the most CPU/Memory. Manage the applications. Phoenix files are not excluded from antivirus scans. To learn how to exclude applications from scans, see Avoiding third party/anti-virus interference with Phoenix Agent. If maximum RAM space is allocated to SQL resource on the server. If the space on the drive is not sufficient.
Internet speed	Verify the Upload/Download speed on the source server. Use the Cloud Harmony tool to determine the speed.
Frequent network disconnects	Errors for network disconnects can be seen in the Phoenix logs. The error message is `Dropped network connection`. You can monitor the network health of a server using networking tools like Wireshark, Netmon and so on. The `[ERROR]:Error during backup. Retrying in a minute...`error message displays.
Modified data in the backup job has increased as compared to the older backups. OR The amount of modified data in the backup job has increased compared to previous backups.	Determine if new data is added or removed from the backup. New data could be: A drive to a Hyper-V VM. An increase in files or folders Database in a SQL server backup A new NAS share You can verify this by: Comparing the older job logs of the same server with this current one. Click Job id > Compare Source Data Scanned and Data Transferred to Cloud from the Summary tab. This gives us an exact increase in the amount of data scanned and transferred to the cloud. Solution Use Backup Now to manually complete the backup of the newly added or deleted data and then monitor the scheduled backups.
The client was busy processing another job	In the following example the schedule of a backup job is 1 AM to 6 AM. If a manual job (triggered via Backup Now ) is in progress and at the same time a scheduled job kicks in as per its schedule of 1 AM, the scheduled job goes into a Queued state until the manual job completes. If the manual job completes at 5:30 AM, the scheduled backup will begin at 5:30 AM. If this scheduled backup starts at the end of the scheduled time (post 6 AM), then the backup window has lapsed, and the scheduled job will fail. Solution Ensure that you Disable the backups for that backup set so that the scheduled backup is not triggered.
Due to a USN journal mismatch, the backup scan gets converted to a Folderwalk instead of a USNwalk	What is USN? Click Here. Phoenix performs a ‘USNwalk’ for Incremental backups. Backups may fail if: USN journal has issues. USN Journal size is not enough to handle the number of files/folder on that drive. Solution Increase the USN journal size. To learn how, click here.
If the content rule has been modified	See the solution here.
File scan is taking longer than expected	File scan can take time if - There are a large number of small files (e.g. The percentage of files smaller than 1 MB are more than 70% to 80% of the total backup ) that have to be scanned. Backup is stuck on a particular file/ folder. We can verify this through the debug logs. Contact Druva support for details. Incorrect Disk Exclusions. Solution Increase the time window or run a manual backup ( Backup Now ) to complete this initially.
Hyper-V Backups	Hyper-V backups may fail: If there are issues with RCT. Backups will then change to a VSS backup. If a new VHDX is added to a Hyper-V VM and is being backed up for the first time. If the load on a Hyper-V host increases substantially when new and big virtual machines are added to it. If the operating system is Windows 2012 R2 and earlier since these operating systems use a VSS backup (RCT wasn't introduced in Windows 2012 R2 and earlier).
Time Zone	Backup may fail before the end of the backup duration. This can happen if there is a difference in the actual time and timezone set. For example: The Time zone of the server (UTC -8:00), Pacific Time (US & Canada) Time in PST as per World Clock: 10:00 am But the time over the server is 3:00 am
Phoenix Agent Service is hung.	1. Go to affected Server 2. Stop Phoenix Services from services.msc. 3. Go to the task manager and check if any hung/stale Phoenix Process is running. Check if, PhoenixSQLAgent PhoenixFSAgent 4. Stop/Kill any Phoenix Service running in Task Manager. 5. Start Phoenix Services from services.msc

Workload:VMware

Cause	Possible solutions
VMware CBT (Change Block Tracking)	If a large number of files were modified on a VMDK as identified by CBT, the processing time might increase, and the backup job may cross the stipulated time window. If there are issues with CBT, then Phoenix will perform a full scan of the disk, and the backup job may cross the stipulated time window. Solution Run a manual backup using Backup Now to complete the backup of the changes. Reset the CBT and then initiate a manual backup using Backup Now. This triggers a full backup for the manual run and subsequent backups use CBT data. To reset CBT, see this.
VM backup starts at the end of a backup window because the backups of other VMs were in progress.	One backup proxy can run three VM backups at a time. If a VM backup starts at the end of the backup window because other backups were running, the backup fails with Backup Window Expired error. Solution Install more backup proxies for load balancing. Druva recommends that you create a dedicated backup proxy pool.
Network	Frequent network disconnects can cause even small backups to take longer and cross backup windows. You can see the network disconnect errors in the Phoenix logs. The error message is Dropped network connection Verify this through a NIC/network change. You can monitor the network health of a server using networking tools like Wireshark, Netmon, and so on.
Transport mode used changes	See VMware backup fails with the 'Backup Window Expired' error when the transport mode is changed from HotAdd
Addition of new virtual machines or VMDKs	The load on a backup proxy increases if New virtual machines are added in the proxy pool or in the same proxy A large VMDK is added to a virtual machine. Solution Run a manual backup using Backup Now to complete a backup of these additional changes and then monitor the scheduled backups.
Backup of hiberfil.sys and pagefile.sys on Windows virtual machines.	Backup time for the particular server increases if the virtual memory files ( hiberfil.sys and pagefile.sys ) increase in size. Solution Run a manual backup using Backup Now to complete the backup of these servers. Increase the physical RAM or free up the size of the above files from the OS.

Problem description

Cause

See also