I have two NimbleStorage SANs and have been using Veeam with storage integration for over 6 months and have some thoughts for improvements. Please pardon some terminology as Nimble says volumes when other storage vendors say LUNs.
UI changes
In Backup Infrastructure: Application Group, VM selection from storage snapshot should include the name of the source infrastructure (Storage1, Storage2, VeeamRespository1, VeeamRepository2, etc). Knowing the source is helpful for selecting the correct Virtual Lab.
In job schedules, the "After this job" selection list should be grouped by job type and ordered alphabetically.
The job report start time is the same for every line item. This causes the duration to be incorrect. For example, a 37 GB item is listed with a 40+ hours duration when it actually took ~10 minutes.
Configuration
On Storage Infrastructure: It's handy that Veeam can read storage snapshots, even if they aren't Veeam initiated. However this seems to be limited to the LUN which include the .vmx file. If a server has hard drives in another storage volume, I'm not able to browse those with Veeam. At the very least could it me mounted to the local proxy and browsed?
Increased schedule options. Within the Nimble I can have multiple schedules with varied replication and retention. I'd like the same scheduling capabilities within Veeam similar to a GFS schedule for tape jobs. For example, hourly snapshots would be replicated to the secondary SAN and stored for 1 business day. Daily snapshots are stored for 4 weeks on the SAN, maybe longer in the repository.
Not every backup job should result in writing to the repository, sometimes storage replication is sufficient.
Veeam Replication jobs should utilize the storage technology and clone the existing storage snapshot. VM config could still be stored in another location, but I think utilizing the storage snapshot would reduce SAN storage, I/O, and faster availability.
crenstrom wrote:[*]Veeam Replication jobs should utilize the storage technology and clone the existing storage snapshot. VM config could still be stored in another location, but I think utilizing the storage snapshot would reduce SAN storage, I/O, and faster availability.[/list]
This is as well possible, replication jobs can use storage snapshots as a source.
Thanks foggy - I don't think I've noticed the snapshot-only job before, thrilled to learn that exists! If you have a minute, where do I configure a replication jobs to use storage snapshots as a source? I only see repositories in the selection list.
Perhaps I first need a backup job which is snapshot only?