Enhancement Suggestions

[tgiphil]

I just upgraded to v6 and I’m very impressed with the improvements over v5! Keep up the good work!

However, I have a few ideas to make Veeam even better:

1. Add the following columns to the Backup & Replication – Jobs:
A. “Last Run” – Date of the last job run
B. “Last Duration” – Length of time of the last job run in HH:MM:SS
C. “Last Transferred” – Transfer size of the last job run in MB

2. Add the “Transfer Rate” over the last minute to the real time statistics of a job in progress. This is more useful and helpful during real-timing monitoring the backup jobs.

3. Create a retention policy option to following to keeping X days (rather than restore points). This makes it easier to comply with retentions policy and regulations requirements. And to be even better, allow users can specify keep the last A hourly, B daily, and C weekly, and D monthly recovery points. Unnecessary incremental data between the periods would not need to be retained.

5. Implement read/process-ahead, store local, and then transmit methodology for backups. The primary benefit would be the reduction in the length of time a snapshot is held for the backup and a lesser I/O impact when the snapshot removal. Another benefit, if implement in conjuration, is to use the local store to assist with de-duplication prior to transmission. This could results in a massive reduction of network bandwidth, particularly during the initial seeding dozens of similar VMs.

6. Determine what blocks are really in use for NTFS partitions and only backup/replicate those blocks that are in use.

Thanks!

[Gostev]

I am really curious about the feature #4 now

[tgiphil]

Sorry, I was trying to order them by increasing implementation challenge and I dropped one in the sort. Here's #4 -

4. Instead of organizing virtual machines in backup jobs, change the backup management to be VM focused. So administrators can specify on a per VM-level the backup schedule and frequency, retention policy, guess processing options, backup repository, etc.

[Gostev]

Would not (4) be simply nightmare beyond a dozen of VMs?

[tgiphil]

Regarding #4 - Obviously having defaults would be important and the ability to make changes to multiple VMs at once time would be helpful. Right now, the challenge is we create different backup jobs to match specific VMs backup requirements (frequency and retention). This would also solve the issue of backup a specific VM or set of VMs on-demand (prior to changes/patches) without having to also backup all the other VMs in the job.

[Gostev]

OK. Just to set the correct expectations right away, per-VM jobs/definitions is not the direction you can expect our product to evolve. However, the other part (on-demand backup) have been requested quite a few times before, and I definitely see this feature as being useful. Thanks!

[tsightler]

So, just to be clear, are you actually requesting "per-VM" jobs? I didn't really read the request like that. I think what many customers would like is the ability to assign VM's to a "protection policy" and then have Veeam intelligently place these VMs into jobs based on those policies. I've got several larger customers that are basically doing that on their own with powershell scripts. Some use very simply scripts, others are quite sophisticated, but the technique is being proven in the field every day and is quite beautiful in action. It's just about the only way to manage environments with 100's or 1000's of VMs.

[tgiphil]

@tsightler suggestion for a per VM "protection policy" would be sufficient too. It would fit our use case. Like some business, we go through a formal risk assessment to determine the level of protection for our data - from the RAID level (yeah, extra party drives), to the frequency of backups, to the length of retention, and to onsite/offsite requirements. This would help us manage part of that implementation.

btw. Don't forget the other 4 suggestions.

[Gostev]

Protection policies as described by Tom are also unlikely to ever be implemented, because they are going to make the product too complex for SMB. If we ever get to building the backup product for thousands of VMs, this is where you can expect to see this kind of functionality.

Regarding other 5 suggestions:

(1) Is unlikely to be added, because there is no space in the grid for extra columns already - but current columns are more important to be present. Unless we add customization of columns displayed - although R&D usually likes to avoid such "bells&whistles" features because they add very little value to the product comparing to other pending features.

(2) This is already shown in the realtime statistics - for each disk separately.

Other suggestions have been requested before and there are separate topics for each - but because you have put them all into single post, I could not really merge your post in any particular topic, so just decided to leave it as is. If you are interested on my feedback on those feature, please just search the forums for the existing discussions. Thanks!

[Bunce]

Just search for my name to get a heap of posts on number 3

I think I saw another request for this posted yesterday.

[tsightler]

Protection policies as described by Tom are also unlikely to ever be implemented, because they are going to make the product too complex for SMB. If we ever get to building the backup product for thousands of VMs, this is where you can expect to see this kind of functionality.

I would not think that such a feature would replace the existing job management, it's more of an extension of the existing job management, that's how users implement it today with Powershell. SMB users wouldn't even need to know the feature existed. That being said, I was not intending to suggest any specific feature, just trying to fully understand the use case and issue at hand, and whether the method I've seen other users use to address this issue would also apply in this circumstance, or if this was a completely different use case. I spend a lot of time thinking and talking about job management and how to best address various requirements, so it's a topic of great interest to me and many Veeam users.

[tgiphil]

@Gostev -

#1 - I hope you reconsider this minor (seemly trivial) request since it would be very helpful to us. As for the concern about no space, the existing scroll bar would accommodate any new columns, if the screen wasn't wide enough.

#2 - Just for the record, the real-time transfer rate information is not anywhere. All the transfer/process/read rates seems to be over the duration of the entire backup - thus not really real-time measurement.

I'll look around for the other forum topics you mention.

Thank for listening.

[chad_c]

In the New Replication Job wizard, on the Guest Processing tab, change the tab order for "Guest OS credentials". I can't tell you how many times I've typed in the username, tabbed, and proceeded to type in the password.

Maybe this is just a "me" issue, and I know it's trivial, but I wonder if anyone else has had similar UI experiences.

[averylarry]

#1 -- Why can you resize vertically, but not horizontally?

#3 -- I can't believe Veeam has made it this long without adding time-based retention policies. Not to mention the almost simplistic scheduling capabilities.

#4 -- From a SMB perspective -- I'm not sure exactly what is being asked for/denied, but it sounds a lot like something I've been wanting. In particular -- since deduplication doesn't span jobs, I would like to put as many VMs as possible in 1 backup job to maximize deduplication. BUT I don't want all my VMs to run on the same schedule OR have the same retention policy (SMB's are more limited on disk space). It seems counterintuitive to separate jobs because I can only have a single schedule/retention policy combination. Maybe I'm describing something different, though . . .

#5 -- Interesting idea. Seems like it could be easily extended into "read once, write many" that's been kicked around (so you can run 2 backups and 1 replication all from a single job/single snapshot reading the data 1 time from the production SAN). Biggest problem I see is having enough storage space such that the cache is actually useful.

[Gostev]

#2 - Just for the record, the real-time transfer rate information is not anywhere. All the transfer/process/read rates seems to be over the duration of the entire backup - thus not really real-time measurement.

Select the VM that is being processed in the real-time statistics window, and you will see the transfer rate next to each disk as it is being processed, and the average rate will remain sitting there once the processing is done.

[Gostev]

#1 -- Why can you resize vertically, but not horizontally?

We build the UI to be usable in 1024x768 resolution, because reportedly too many people are managing backups from tablets which are currently limited to this resolution.

As for other features you commented already have their own topics with big and long discussions, so I'll skip commenting on them here yet again if you don't mind

[tgiphil]

Select the VM that is being processed in the real-time statistics window, and you will see the transfer rate next to each disk as it is being processed, and the average rate will remain sitting there once the processing is done.

Actually, that is the read rate from disk - not the transfer rate over the network. It's obvious when the read rate is several times faster than my WAN link speed! However, I won't belabor this further.

Thanks.

[habibalby]

Hi,

I would also suggest the following enhancement to keep Veeam top Virtualization Backup Product among the rest that available in the market.

1. Multiple job settings for one particular VM. For instant, I can configure Full Backup Job without selecting Incremental which is currently a default setting and must be selected. This should be taken off to have more flexibility of the Backup files.
2. Creating separate Incremental Job / Forward Incremental or Reversed Incremental depends on the customer requirement. This will make sure that files are written to tapes are Full Backup or are Incremental backup. I can bring one example in here which is when I Backup VM in Reversed Incremental Mode, I'm forced to backup only Full Backup without incremental this because the Archive-Bit is resetting from last the job runs. Which force the the product that backing up from Disk to tape to always backup in Full Mode. Agreed for small number of VMs, but when it comes to VMs that have got TBs of Data, I would say Veeam Sorry, I can't backup this VM in Reversed Incremental Mode as it keep changing the original VBK file in every Incremental runs. Thus, the customers can't backup the whole VM and the customer forced to go back to the Legacy Backup application to back his VMs.

Or Veeam.com should do something on how the Reversed Incremental backup works. Reversed Incremental is good and in my onion works better than Forward Incremental specially for those who lacks of disk space to backup to disk, the Retention Policy works perfect, unlike Forward Incremental Backup. If the Reveresed Incremental works without changing the main VBK file to keep track of the last Archive Bit when was reset by the Backup to Tape product, this will save us from running full backup from disk of very BIG VMs.

With Forward Incremental, if Veeam.com get rid of doubling the VBK Files during the second week of Full Backup this will keep backing up to Tape is a great choice in selecting this mode of Backup to Disk and then to Tapes.

3. Veeam.com should introduce Back-to-Tape integration so, VMs directly will be processed to tapes, I know it's a bit slower but it's a safest option customer can adopt.

Thanks,