Skip to main content
All CollectionsKnowledge BaseEnterprise WorkloadsTroubleshooting - Enterprise Workloads
Possible causes for Phoenix backups failing with the backup window expired error
Possible causes for Phoenix backups failing with the backup window expired error
Updated over a week ago

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.

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:

  1. Comparing the older job logs of the same server with this current one.

  2. 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:

  1. USN journal has issues.

  2. 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 -

  1. 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.

  2. Backup is stuck on a particular file/ folder. We can verify this through the debug logs. Contact Druva support for details.

  3. 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

  1. Run a manual backup using Backup Now to complete the backup of the changes.

  2. 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

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.

See also

Did this answer your question?