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.
Workloads: File servers, SQL, Hyper-V, NAS
|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
Backups may fail if:
Verify the Upload/Download speed on the source server. Use the Cloud Harmony tool to determine the speed.
|Frequent network disconnects
|Modified data in the backup job has increased as compared to the older backups.
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:
You can verify this by:
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.
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:
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 -
Increase the time window or run a manual backup (Backup Now) to complete this initially.
Hyper-V backups may fail:
|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.
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
4. Stop/Kill any Phoenix Service running in Task Manager.
|VMware CBT (Change Block Tracking)
|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.
Install more backup proxies for load balancing. Druva recommends that you create a dedicated backup proxy pool.
|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
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.