Storage integrated backups WITHOUT vSphere snapshots?

[squebel]

Sorry if it's been asked already but I could not find anything on this: Is it possible to take backups of VMware vm's using the storage integration with Nimble arrays WITHOUT having to take vSphere snapshots of the vm's first? We would like to know if this is possible as we have a customer that has a lot of very sensitive vm's that can not withstand even the slightest pause in i/o to the vm's.

[Gostev]

Real backups require VMware snapshots (by real backups I mean an independent copy of production data sitting in the backup repository). These require VMware snapshot due to their reliance on CBT, and varying time of application-aware processing between different VMs in the same job.

There's a new feature for "storage snapshots only jobs" in v10 which allows them to work without VMware snapshots in certain circumstances. Please refer to the Primary Storage Integrations section of the What's New in Veeam Backup & Replication v10 document for important details.

Thanks!

[Gostev]

Alternatively, you can always use an agent-based backup for those few special VMs instead, of course. These certainly don't require VMware snapshots

[squebel]

@Gostev - thank you for the quick response!!

Maybe without understanding exactly how it all works, I'm trying to understand if there is a way to do a backup of a vm, from the storage snapshot, to that independent copy on a backup repo without having to stun the vm with a vmware snapshot. If I understand what you said, that is not possible because Veeam must be able to access the vm's snapshot files in order to leverage CBT even in the point-in-time storage snapshot and without those files, Veeam can not take a backup of the vm in the same way it could if the vm had an open snapshot during the storage snapshot?

Also, in this scenario there is NO expectation of app-aware quiesce or vm-level quiesce required. We understand the pros/cons of that and it is not a requirement in this scenario.

I did just look at the feature you mentioned and if I understand it, it's not exactly what I'm looking to do, but it is worth knowing. Thanks for point that out.

[Andreas Neufert]

Hi, it is not that simple. High level. The VM is located on a filesystem (VMFS) that we can not read natievly. So we need to ask VMware for the details of VMDK placement and then backup APIs give us only the needed details when your create a VM snapshot as this is their base reference point. Potentially we can workaround this but at this time there is no such functionallity in the product.

The only option today to do a backup without VMware snapshots is by installing agents. There is no extra license needed with v10 for this.

[squebel]

Got it, Andreas. Thank you even for the simple explanation that it is not technically possible today.

[Andreas Neufert]

Please let me add with our Backup from Storage Snapshot the VM snapshot exists only for some seconds. Usually this is fine for nearly any application.
You can test it by just creating manually a VM snapshot (without quiescense and without memory dump) and then remove it after 15 seconds. If your application survive this, it will survive the Backup from Storage Snapshot process.

[squebel]

Understood. We are using the integrations in a few places. However, we have a particular customer that is requiring no vmware snapshots no matter how long they are open. We will work around their requirements and may use the agent idea as a solution. Thank you both for the responses!

[Andreas Neufert]

The integration of the Agent Management is pretty awesome. You can distribute the agent from the Veeam Server and can create jobs there as well. It is not far away from the user experience with VM backup. Instant Restore within VMware is as well possible with Agent backups.
https://helpcenter.veeam.com/docs/backu ... ml?ver=100

[Ollo]

Hello, we have some large IBM DB2 Cluster with more than 50 VMDKs per VM and more than 20tb of data. Because of the nightly snapshots the latency rises. Some sensible application don't like these latencies and crashes. Is the only solution a backup per Linux Agent?
we are useing storage snapshots of these VMs, but the crashes still occures

[foggy]

If crashes occur during the snapshot commit phase, then optimizing the storage I/O capabilities could help to make it shorter. But in general, yes, using Agents is a workaround.