When a NAS Backup runs, the archive offload process appears to be included in the job length calculation. This often causes erroneous "Unusual Job Duration" alerts on our NAS backups even when the actual backup was normal.
In a future update would it be possible to exclude the archive offload from the backup job duration calculation?
It would more useful to monitor offload jobs separately based on their average upload speed as the size of an archive offload job can vary massively from day to day.
-
- Influencer
- Posts: 22
- Liked: 4 times
- Joined: Jan 15, 2021 2:53 am
- Full Name: Daniel Davis
- Contact:
-
- Veteran
- Posts: 3077
- Liked: 455 times
- Joined: Aug 07, 2018 3:11 pm
- Full Name: Fedor Maslov
- Contact:
Re: Unusual Job Duration when archive offload triggered in file backup
Hi Daniel,
Thanks for reaching out.
I've passed that to our QC team for reproduction. Do you have a support case where we could get additional details on this issue?
Thanks
Thanks for reaching out.
I've passed that to our QC team for reproduction. Do you have a support case where we could get additional details on this issue?
Thanks
-
- Veeam Software
- Posts: 745
- Liked: 191 times
- Joined: Nov 01, 2016 11:26 am
- Contact:
Re: Unusual Job Duration when archive offload triggered in file backup
Hello Daniel,
We've identified an issue. It will be fixed in future product versions.
Thanks
We've identified an issue. It will be fixed in future product versions.
Thanks
-
- Veteran
- Posts: 3077
- Liked: 455 times
- Joined: Aug 07, 2018 3:11 pm
- Full Name: Fedor Maslov
- Contact:
Re: Unusual Job Duration when archive offload triggered in file backup
Hi Daniel,
Unfortunately, we are not able to exclude the archival process from the alarm triggering logic, as the archival is performed as a part of a normal backup job session (job run). Actually, it's even a part of a lower-level entity - a task session backing up a dedicated file source. These task sessions may run both in parallel and one after another constituting a job session.
The options we have are:
1. We can make the alarm not trigger at all when archiving is configured in the file backup job settings which essentially means it will never trigger for jobs with such configuration.
2. Leave the behavior as it is which may be useful in certain situations. For example, it may help to identify that the archival has become enabled and now the duration of the job increased. After a few successful runs with archiving, the alarm will stop triggering because the duration of the latest run will eventually match the average duration of the previous ones. At the end of the day, the goal of the alarm is to highlight situations when the job duration has increased, regardless of what caused this.
Right now, you may try to increase the "Analysis depth" parameter in the alarm settings and see if that helps to work around the issue. This parameter defines the number of latest job sessions to be analyzed. If that does not help, I would recommend excluding the file backup jobs with configured archiving from the alarm using the corresponding alarm setting.
Look forward to your reply. Thanks.
Unfortunately, we are not able to exclude the archival process from the alarm triggering logic, as the archival is performed as a part of a normal backup job session (job run). Actually, it's even a part of a lower-level entity - a task session backing up a dedicated file source. These task sessions may run both in parallel and one after another constituting a job session.
The options we have are:
1. We can make the alarm not trigger at all when archiving is configured in the file backup job settings which essentially means it will never trigger for jobs with such configuration.
2. Leave the behavior as it is which may be useful in certain situations. For example, it may help to identify that the archival has become enabled and now the duration of the job increased. After a few successful runs with archiving, the alarm will stop triggering because the duration of the latest run will eventually match the average duration of the previous ones. At the end of the day, the goal of the alarm is to highlight situations when the job duration has increased, regardless of what caused this.
Right now, you may try to increase the "Analysis depth" parameter in the alarm settings and see if that helps to work around the issue. This parameter defines the number of latest job sessions to be analyzed. If that does not help, I would recommend excluding the file backup jobs with configured archiving from the alarm using the corresponding alarm setting.
Look forward to your reply. Thanks.
Who is online
Users browsing this forum: No registered users and 1 guest