Storage Snapshots with baie SAN

[totoche]

When using Storage Snapshots, the VM is not blocked by the snapshot VMware during backup.
What Makes tone can not launch a second action on this VM, since it did not snapshot ?
Do you also that same silly limitation?

Thank You.

[Vitaliy S.]

Hi Totoche,

Not sure I fully understand you question. When storage snapshot is used, VM snapshot is also taken and then committed right after storage snapshot is mounted to a proxy server. What action would you like to trigger against the backed up VM?

Thanks!

[totoche]

I would like to use a slow replication over the WAN, and local backup or replication without being limited by a particular order or processing time.
Theoretically, this should be possible because there are no snapshot on the VM.

[foggy]

Each of those actions still require taking a VMware snapshot of the VM, even though it is committed pretty fast back right after the storage snapshot is created. So you still need to make sure they do not overlap in their VM snapshotting attempts.

[totoche]

Each new job generates its own bay snapshot, so there is no overlap!
The problem is not 19 seconds to take the snapshot, but the fact that vm can not be backed up all the time for action.
It must also be noted that on Netapp this limitation does not exist from snapmirror which is based on snapshots storage, then please consider this limitation in Veeam?

Code: Select all

[b]05/05/2016 14:49:48 :: Creating VM snapshot [/b]
05/05/2016 14:49:51 :: Collecting disk files location data 
[b]05/05/2016 14:50:07 :: Removing VM snapshot [/b]
05/05/2016 14:50:28 :: Queued for processing at 05/05/2016 14:50:28 
05/05/2016 14:50:29 :: Required backup infrastructure resources have been assigned 
05/05/2016 14:50:33 :: VM processing started at 05/05/2016 14:50:33 
05/05/2016 14:50:33 :: VM size: 60,0 GB 
05/05/2016 14:50:34 :: Discovering replica VM 
05/05/2016 14:50:36 :: Processing configuration 
05/05/2016 14:51:08 :: Creating helper snapshot 
05/05/2016 14:51:16 :: Using source proxy emm-vprx3.grpmarle.loc for retrieving Disque dur 1 data from storage snapshot 
05/05/2016 14:51:16 :: Using target proxy emm-vprx1.grpmarle.loc for disk Disque dur 1 [hotadd] 
05/05/2016 14:52:07 :: Disque dur 1 (60,0 GB) 24,7 GB read at 98 MB/s
05/05/2016 14:56:51 :: Deleting helper snapshot 
05/05/2016 14:57:03 :: Finalizing 
05/05/2016 14:57:07 :: Busy: Source 69% > Proxy 84% > Network 4% > Target 47% 
05/05/2016 14:57:07 :: Primary bottleneck: Proxy 
05/05/2016 14:57:07 :: Network traffic verification detected no corrupted blocks 
05/05/2016 14:57:07 :: Processing finished at 05/05/2016 14:57:07

[Vitaliy S.]

Each new job generates its own bay snapshot, so there is no overlap!

Even though each job creates its own VM snapshots, Alexander was referring to having no overlap when VSS snapshot is triggered inside the VM. VSS is required if you want to have application-consistent backups.

I would like to use a slow replication over the WAN, and local backup or replication without being limited by a particular order or processing time.

Have you considered using backup files as source for your replication job? Should do the trick, based on your description above.