This feature serves a similar purpose to my previously mentioned automatic scheduling request. Essentially it would be a pie chart (representing a full day) and it would demonstrate when each backup job began and when it ended. Thus one could see where there was a heavy preponderance of jobs and move some of them to a different time (preferrably, drag and drop). It wouldn't just show when the jobs are scheduled to begin but also when they are estimated to end as well as an average of their actual end times. For the visualization sort of technology I am envisioning take a look at the open source storage visualization application WinDirStat (windirstat.info).
Dave.
-
- Enthusiast
- Posts: 69
- Liked: never
- Joined: Mar 16, 2009 4:01 pm
- Full Name: David Mackey
- Contact:
-
- Chief Product Officer
- Posts: 31471
- Liked: 7010 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Feature Request: Visual Backup Mapping.
Dave, I have discussed this concept with some folks here at Veeam a few months ago. Personally, I am strong believer this approach would not work in real environments.
Mainly because backup failures are quite common thing for virtual backups (snapshot timeouts, VSS freeze timeouts, iSCSI reservation timeout, intermittent disk/network/connection/load issues, just to name a few - this may be happening almost). Any such issue would screw up all nicely drawn schedule completely, with failed job affecting other jobs by its retry cycles, at the same time completely loosing the time period that should have been originally occupied by failed job. So the static schedule would work under ideal conditions only.
Another reason is this: I believe such manual backup job micro-management might be possible for small environments, but nearly impossible in medium/large businesses due to amount of data and job, and even more environmental problems due to the size and complexity of environment.
But it does not mean your reasoning is invalid. I just think that this feature needs to be implemented differently and be more automated. I have some ideas that I do not want to discuss on public forum, but I can get back to you when we start working on this feature.
Mainly because backup failures are quite common thing for virtual backups (snapshot timeouts, VSS freeze timeouts, iSCSI reservation timeout, intermittent disk/network/connection/load issues, just to name a few - this may be happening almost). Any such issue would screw up all nicely drawn schedule completely, with failed job affecting other jobs by its retry cycles, at the same time completely loosing the time period that should have been originally occupied by failed job. So the static schedule would work under ideal conditions only.
Another reason is this: I believe such manual backup job micro-management might be possible for small environments, but nearly impossible in medium/large businesses due to amount of data and job, and even more environmental problems due to the size and complexity of environment.
But it does not mean your reasoning is invalid. I just think that this feature needs to be implemented differently and be more automated. I have some ideas that I do not want to discuss on public forum, but I can get back to you when we start working on this feature.
Who is online
Users browsing this forum: Google [Bot], Semrush [Bot] and 270 guests