Feature Request(s)

[SyNtAxx]

Is there an official method of requesting a feature add to Veeam Backup and Replication or is it done via the forums ?


Thanks,

[Shestakov]

Hello! You can just describe it right here. Thanks!

[SyNtAxx]

Features I'd like to see:

-Simultaneous access to media pool(s). (Would negate the need for a media pool per tape job in order to run multiple tape dumps.)

-When using containers to manage backups, I'd like to see the 'objects in the job' metric show the actual number of vm(s) being backup up, not the container objects. Example, I add vms to backups using tags in vmware, one tag per backup job. It only shows me one (1) object is being backed up. (the tag) I think it would be more useful to know how many objects that tag is comprised of as using object one skews reports/reporting.

-Clearer display of actual backup processing speeds: Processing speed shows one number, yet job logs show another, and same still the brown on the graph shows another. The brown line on graph is the actual job speed correct, as that is what is actually being sent to disk or tape?

-Nick

[SyNtAxx]

Further expanding on the tags/containers: (Maybe I haven't found how to do it yet) If i create a job based on tags/containers it doesn't seem that I can execute pre/post thaw script set for an individual vm. It appears it would be global when using containers. If the container was enumerated within the job declaration you could then create a pre/post script set per vm as needed. (Again, forgive if I haven't figured it out yet.)

-Nick

[Gostev]

Hi Nick, and thank you for your feedback!

Simultaneous access to media pool(s). (Would negate the need for a media pool per tape job in order to run multiple tape dumps.)

Tape related feature request are best put in the corresponding subforum, but I can say that it was requested there before and we are already working on this feature as a result.

When using containers to manage backups, I'd like to see the 'objects in the job' metric show the actual number of vm(s) being backup up, not the container objects. Example, I add vms to backups using tags in vmware, one tag per backup job. It only shows me one (1) object is being backed up. (the tag) I think it would be more useful to know how many objects that tag is comprised of as using object one skews reports/reporting.

Makes sense - are you talking about email report, or some other place? Can you link a screenshot?

Clearer display of actual backup processing speeds: Processing speed shows one number, yet job logs show another, and same still the brown on the graph shows another. The brown line on graph is the actual job speed correct, as that is what is actually being sent to disk or tape?

Yes. If you hover over the graphs, you will see the legend of what color means what.

Further expanding on the tags/containers: (Maybe I haven't found how to do it yet) If i create a job based on tags/containers it doesn't seem that I can execute pre/post thaw script set for an individual vm. It appears it would be global when using containers. If the container was enumerated within the job declaration you could then create a pre/post script set per vm as needed. (Again, forgive if I haven't figured it out yet.)

Yes, this is in fact possible - you can simply add individual VMs to the list in the advanced guest processing setting, and configure custom processing for each VM. This will supersede any settings you have set on the container object. I am talking about adding individual VMs to the middle (second) dialog that you can barely see on this screenshot. You can even have a special tag that defines guest processing rules, and add VMs to that list this way.

[dellock6]

Makes sense - are you talking about email report, or some other place? Can you link a screenshot?

I see what he's referring to into the main interface of the backup jobs, this one for example is saving the entire vCenter tree:



Honestly, it makes sense to say 1 object because the container is one, and I can also immediately see there are 13 VMs in this container, and also that all 13 has been saved successfully in the last run.
Unless we are talking about some other area of the software, but this one is the only I remember...

[Gostev]

Ah. This part is actually by design. Basically, we cannot know the amount of VMs in the job until we enumerate the container. This enumeration happens first thing every time the job is started. Now, of course can show the number of VMs in the session history you are showing (because we know how many VMs we have processed during that session), but we cannot really show this info in the job's grid. This would require constant enum of all jobs.

[dellock6]

Also because the whole idea of containers is that they are "Dynamic" entities, so we can have once 15 VMs, 10 the next run, 100 the third run. Makes sense only in the history of job executions