Have not tried this as yet.  We are working to get Hitachi plugin testing going so I can try it once we have that in place and see.  I am sure it would work well though.

You’re just talking about a normal replication job but with the source being a storage snapshot correct? Not trying to use a multi-node SAN specific functionality type thing are you?

If it’s the former, I’ve done this with Nimble on iSCSI, ran absolutely fine, less ideal for low RPO as you’ve got the storage snapshot overheads for job initialisation, but certainly worth this time when you’re trying to keep a relatively low RPO on a highly transaction SQL/Exchange server.

no trying to keep this as simple as possible, and for the exact same reasons as you stated, highly transactional SQL server, want to limit the impact on of the snapshots on the guest VM.

Storage snapshot overheads that big? Thought it would have just been step 1) take VM level snapshot 2) snap the underlying storage lun , job done. Got to be better than having the VM level snapshots open for a length of time?

I use storage snaps for more and more these days, but haven't tested this.

You actually don’t need to do a VM snap followed by a storage snap if you use Veeam to create the snapshot. 

In the console, under Storage Infrastructure, select your SAN, right click your LUN, then create snapshot.

you can now right click your VM and work with it. 

As I understand it, there’s still a VM snapshot take, just it’s managed by Veeam as part of the LUN snapshot?

Actually no.

When you do a Backup, Veeam does a VMware snapshot, then the SAN takes a snapshot so Veeam can remove the VMware snap to prevent it from growing.  I had a server that grew 3 TB this week having a snapshot on it for a day so busy servers this becomes a HUGE benefit. You can fill up a volume quickly if snapshots are left.

When you do the Storage snap from within Veeam, it doesn’t need to do a VMware snapshot first. I just tested it and there was no activity in VMware at all. Once you take the snapshot, the VM’s show up in the storage Infrastructure window. 

From there you can do an Instant recovery, Instant Disk recovery, Restore guest files or application items. 

If you needed to say backup at this point. you could instant recover the VM into your infrastructure, leave it running, then treat it like a regular VM.  You could back it up, replicate it, whatever you want.

It's just a ANOTHER way that Veeam is flexible. 

If you wanted to copy a VM from one vCenter to another, you could storage snap it, and instant restore it to the other. From there you could clone it, back it up, etc while the instant restore is still running. Or use it for TEST dev. whatever you want. 

@Scott  This contradicts the documentation 

https://helpcenter.veeam.com/docs/backup/vsphere/vm_processing.html?ver=120
 

Backup from Storage Snapshots

Backup from Storage Snapshots lets you speed up backup and replication operations. For Backup from Storage Snapshots, Veeam Backup & Replication complements the VMware vSphere snapshot technology with the storage snapshots technology, and uses storage snapshots as a source of data for backup and replication.

During Backup from Storage Snapshots, Veeam Backup & Replication performs the following actions:

1. Veeam Backup & Replication triggers a VMware vSphere snapshot for VMs whose disks are hosted on the storage system.
2. Veeam Backup & Replication triggers a storage snapshot of the volume or LUN hosting the VM itself and the created VMware vSphere snapshot.
3. The VMware vSphere snapshot on the original storage volume is deleted immediately after the storage snapshot is created. Veeam Backup & Replication accesses the ‘cloned’ VMware vSphere snapshot on the storage snapshot and copies VM data from it.
4. When VM processing is finished, the storage snapshot capturing the VMware vSphere snapshot is removed.

As a result, the VMware vSphere snapshot exists for a very short time, namely several seconds. Delta files do not grow large, and the time of VMware vSphere snapshot commit decreases.

Maybe I'm missing something because I haven't implemented it yet (I'm doing it these days)..can't CDP replication be used as an alternative to VMware snapshots?

@Cragdoo - I don’t use BfSS with Replication, but I do so for Backup jobs, and like @MicoolPaul ..I use Nimble w/iSCSI. And yes, it actually can take a while for the initialization phase of the job to run before the Backup...or Replication, takes place. For my jobs, it can take anywhere from 7-10mins before the job actually starts processing my backup data. The reason I got from @haslund some time ago, was to collect the CBT data, if memory serves. Maybe he can comment & clarify if my memory is incorrect. I don’t use BfSS for my Repl jobs since using Hotadd actually goes a little bit quicker, in my environment at least. Anyway, as mentioned, using BfSS should help lessen the VMW snap time significantly for you on your highly transactive VMs.

Cheeers

You quoted the “Backup from Storage Snapshots” from the manual.

Yes, this does take a VM snapshot, followed by a storage snapshot, then removes the VM snapshot. It is much less load on the VM not having the “stun” effect when the snapshot is removed. I use this in my environment and it is excellent. Very fast too.

What I was suggesting, if you DON’T want to do the VM snapshot, you could simply do a storage snapshot, instant restore that VM from the snapshot to an ESXI host (leave powered off), then use the instant restore VM to prefrom the backup, seed, file level restore, veeamZIP or any other feature.

You can do that and it does not use a VM snapshot. that is why you have to do the instant restore to VMware first. It does add an extra step and restore, but if you have 2 environments on the same SAN it works great to make things more portable. 

BFss is worth it for SQL and SQL Always On clusters if you are experiencing Stun. 

Due to the criticality of our systems this was a must for us.