This topic consists of the following sections:
Skipped job
The scheduled job that did not start during the scheduled window due to another running job, remains in the queue until the window is active, and after the window expiry, the job is marked as Skipped. The job is marked as skipped in the following scenarios:
If the first running job is a manually-triggered backup, that is Backup Now that runs with no backup window and the subsequent scheduled job is not picked by the client.
If the first job is a scheduled job with no backup window defined, that is when the Backup Duration is '0', and the subsequent scheduled job is not picked by the client.
If the first job is a scheduled job with a very high backup window, for example, 96 hours, and the subsequent job is not picked by the client.
Please refer error code PHOENIX 230.
Disconnected client
For a Backup Now job, if the client is disconnected when the job is triggered, the backup job fails as follows:
For File server and MS-SQL server: The backup job fails immediately with the PHOENIX 17 error.
For a virtual machine with proxy load balancer disabled: The backup job fails immediately with the PHOENIX 17 error.
The proxy load balancer is disabled if one or more backup proxy client in your registered vCenter are below version 4.6.2.For a virtual machine with load balancer enabled: The backup job fails after 24 hours.
The proxy load balancer is enabled if all the backup proxy clients in your registered vCenter to version 4.6.2 and later.📝 Note
For VMware with load balancer enabled, the job may not be picked by client as all backup proxies in the backup proxy pool may be disconnected or the backup proxy pool is busy. In this case, PHOENIX 229 error message is displayed.
For scheduled jobs, if the job did not reach the client as the client was disconnected throughout the job window.
For File server and MS-SQL server: The backup job will fail after the scheduled window expires with PHOENIX 228.
For a virtual machine with load balancer disabled: The backup job will fail after the expiry of the scheduled window with PHOENIX 227.
The proxy load balancer is disabled if one or more backup proxy client in your registered vCenter are below version 4.6.2.For a virtual machine with load balancer enabled: The backup job will fail after the expiry of the scheduled window with PHOENIX 231.
Proxy load Balancer is enabled if all the backup proxy client in your registered vCenter to version 4.6.2 and later.
📝 Note
After triggering the schedule job with infinite window, if the client is disconnected for 24 hours, the job fails.
Backup proxy pool busy
For a Backup Now job, if the backup proxy pool is busy, the job will fail with the following error:
VMware with Proxy Load balancer enabled: Fail the backup job after 24 hours witherror.
For a Scheduled Backup, if the backup proxy pool is busy during the scheduled window, the job will fail with the following error:
VMware with Proxy Load balancer enabled: Fail the backup after backup window expires witherror.
If the job is in the client queue but was not completed, the job will fail with PHOENIX 158 error.
First backup behavior
Typically, the first backup job for a server requires a lot of time because the data set is large. For a large data set getting backed up, it is possible that the backup duration you specify in the backup policy is not enough for the job to get completed. A backup job is considered complete when a restore point is created at the end of the job. To ensure that the first backup job gets completed successfully, the Ignore backup duration for first backup option is available in the backup policy. By default, this option is enabled to ignore backup duration until the first restore point is created, and the server is backed up for the first time.
While the first backup job is running and the Ignore backup duration for first backup option is selected:
Specified backup duration in backup policy is ignored
Any subsequent scheduled or manual backup jobs triggered during that duration are not triggered in order to ensure the successful run of the first job.
Until the first restore point is created, Druva displays the following message if you trigger a manual backup job during an ongoing backup.
After a restore point is created, all subsequent backup jobs are treated as incremental backups and backup policy settings are applied.
New backup window expired state for jobs
A backup job gets the Backup Window Expired state if there is some data that is backed up but the restore point is not created because backup duration specified in the backup policy is not enough to get the entire data set backed up.
If many jobs end with the Backup Window Expired state, review the backup duration specified in backup policy because it is not enough for the backup to complete. However, a user can ignore this message because the entire data set is eventually backed up when subsequent scheduled jobs are triggered as Druva always performs an ever incremental backup.
Application-aware log backup behavior
The following is the behavior of the transaction log backups on VMware virtual machines with SQL Server aware backups enabled:
The transaction log backup will continue to run in a loop until it fails or gets canceled under the same job ID. See the Progress Logs on the job's Logs tab for details.
The transaction log backup has one of the following statuses: Failed, Cancelled, Waiting for the next schedule.
The transaction log backup can never have the status as Successful. This design was introduced so that the VMware jobs page is not unnecessarily flooded with T-log backups.
The transaction log backups can be cancelled under the following two scenarios:
If a scheduled full backup job is triggered, then the transaction log backup job is canceled.
If an administrator cancels the transaction log backup job.
If transaction log backup jobs fails, a full backup job of the SQL server is automatically triggered and a transaction log backup is triggered as per the schedule. Whenever transaction log backup fails with the log chain error, a full backup triggers automatically as per the design.
Job statistics for backup and restore jobs
Druva provides additional job statistics for backup and restores jobs. The job statistics serve as instrumentation bits for troubleshooting backup performance issues.
The job stats are listed on the Job Details page. The following table captures the behavior of the old, new, and upgraded clients when old or new backup and restore jobs are run.
Client vs. Job | Old Client | New Client | Upgraded Client |
Old Backup Job |
| NA |
|
New Backup Job |
| Summary tab displays the new backup job stats. | Summary tab displays the new backup job stats. |
Old Restore Job |
| NA |
|
New Restore Job |
| Summary tab displays the new restore job stats. | Summary tab displays the new restore job stats. |
Backup job statistics
The following table lists the backup job statistics specific to workloads, such as VMware, File server, MS-SQL server, and so on.
Job Stats | Windows File Server | Linux File Server | UNC Share | MS-SQL server | VMware | Hyper-V | NAS | Oracle |
Status = Running | ||||||||
Source Data Scanned | Yes | Yes | Yes | Yes | Yes | No | Yes | No |
# VMDK(s)/Disks | No | No | No | No | Yes | Yes | No | No |
# Files | Yes | Yes | Yes | No | No | No | No | No |
File Size Distribution | Yes | Yes | Yes | No | No | No | No | No |
# DBs | No | No | No | Yes | No | No | No | No |
Estimated Duration | Yes | Yes | Yes | Yes | Yes | Yes | No | No |
Data Transferred to Cloud | Yes | Yes | Yes | Yes | Yes | Yes | No | Yes |
Data Transferred to CloudCache | Yes | Yes | Yes | Yes | Yes | Yes | No | Yes |
Backup Duration | No | No | No | No | No | No | No | Yes |
Backup Speed | No | No | No | No | No | Yes | No | Yes |
Bandwidth Consumed | No | No | No | No | No | Yes | Yes | Yes |
Disk Read Rate | Yes | Yes | Yes | Yes | Yes | No | No | Yes |
# Network Retries | Yes | Yes | Yes | Yes | Yes | Yes | No | Yes |
Network Retry Duration | Yes | Yes | Yes | Yes | Yes | Yes | No | Yes |
CBT | No | No | No | No | Yes | No | No | No |
Pre Script Status | Yes | Yes | No | No | No | No | No | No |
Post Script Status | Yes | Yes | No | No | No | No | No | No |
Status = Failed / Successful / Successful with errors | ||||||||
Source Data Scanned | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No |
# VMDK(s)/Disks | No | No | No | No | Yes | Yes | No | No |
# Files | Yes | Yes | Yes | No | No | No | Yes | No |
File Size Distribution | Yes | Yes | Yes | No | No | No | Yes | No |
# DBs | No | No | No | Yes | No | No | No | No |
Data Transferred to Cloud | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
Data Transferred to CloudCache | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
Backup Duration | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
Backup Speed | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
Bandwidth Consumed | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
Disk Read Rate | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
# Network Retries | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
Network Retry Duration | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
CBT | No | No | No | No | Yes | No | No | No |
Restore job statistics
The following table lists the restore job statistics specific to the workload, such as VMware, File server, MS-SQL server, and so on.
Job Stats | Windows File Server | Linux File Server | UNC Share | MS-SQL server | VMware | Hyper-V | NAS | Oracle |
Destination Location | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
Destination Share/Druva Store | No | No | No | No | No | No | Yes | Yes |
Restored Data | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
Bandwidth Consumed | No | No | No | No | No | No | Yes | Yes |
File Size Distribution | Yes | Yes | Yes | No | No | No | No | No |
Restore Speed | Yes | Yes | Yes | Yes | Yes | Yes | No | No |
Disk Write Rate | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No |
# Network Retries | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No |
Network Retry Duration | Yes | Yes | Yes | Yes | Yes | Yes | Yes | No |