Feature Request: Storage Snapshot Restore via Quick Rollback

[crackocain]

Hello

We often use quick rollback and loved it. But when we restore from storage snapshot Veeam delete source virtual machine. (Original location Instant Recovery restore)
Thats why all data retrieve from storage (snapshot volume to original volume). When the copy on write storage snapshot technique is used all data write twice to storage.

Why Veeam not use quick rollback engine for this scenario? Or why entire VM restore can't use restore from storage snapshot?

[HannesK]

Hello,
Quick rollback uses VMware change block tracking in the background. Reason: there is no VMware change block tracking between hardware storage snapshots.

Entire VM restore from storage snapshot had only very few requests in the past as instant recovery is faster online again. Having less options make the user interface easier to use and we try to keep it simple.

Best regards,
Hannes

[crackocain]

Hello

I don't understand CBT part. Storage snapshot volume mount ESXi hosts and VM disks are VMDK. So CBT info is inside the VM folder.
So Veeam proxy compare this info and original VM CBT info, restore the virtual machine via quick rollback like backup restore.

Instant VM recovery is good but some storage vendors use Copy on write snapshot technique like IBM Storwize. Last firmware 8.4 enable redirect on write but only deduplication active volumes and Data Reduction Pools.

So when we restore 15 TB volume from storage snapshot we have to 15 TB free space. So we have to delete source virtual machine. This is not good and not working every scenario. But quick rollback fix this problem. Also speed is much lower compare to quick rollback. Quick rollback is like magic

[HannesK]

VMware CBT only works with VMware snapshots. Storage snapshots are usually without VMware snapshots. So it would become a full-scan in the end.

So when we restore 15 TB volume from storage snapshot we have to 15 TB free space. So we have to delete source virtual machine.

uhm, the free space is available because

But when we restore from storage snapshot Veeam delete source virtual machine

I agree that it sounds smart to somehow magically find changed blocks... but it's technically complicated

[crackocain]

VMware CBT only works with VMware snapshots. Storage snapshots are usually without VMware snapshots. So it would become a full-scan in the end.

Yes but quick rollback snapshot created in source machine so it's not relevant repository or storage snapshot. Whats the difference from NAS restore? (via Entire VM quick rollback)

Actually this behaviour create another problem when is storage compression/thin provisioning is used. Because of overprovisioning, Instant Recovery + Migration consume space.

For example we restore 15 TB virtual machine.
If the array doesn't support automatic SCSI UNMAP (most entry-level storage doesn't), the incoming data takes another 15 TB space even if we delete the actual virtual machine.

1. Veeam Delete the original VM (but space not free in array because of UNMAP) 15 TB space is still consume.
2. Veeam migrate to virtual machine snapshot volume to original volume.
3. Another 15 TB is written in array.

BTW SCSI UNMAP is not fast. Deleted data can not freed immediately. So even if the storage array support SCSI unmap this problem continue.

[foggy]

Currently, Veeam B&R just does not store change tracking info for VM disks while creating storage snapshots. And I agree with Hannes, full VM restore from storage snapshot is not a highly demanded feature.

[crackocain]

55% of all restores were file-level recoveries (50% Windows and 5% Linux)
17% of all restores were application item recoveries
14% of all restores were entire VM restores
4% of all restores were instant VM recoveries
2% of all restores were VM file or VM disk restores

Yes but in Anton Gostev told in weekly post most of full restores are entire vm restore.
Forget storage snapshot. If I have to choose one of the two options, i select entire vm restore with quick rollback. Not IR.
Yesterday I restored 7 TB virtual machine in 10 minutes with quick rollback. If i use Instant VM recovery and then migrate all data from backup repository to production volume oh my god i think takes forever. But software team request near RPO. Thats why i have to use storage snapshot Instant Recovery for same virtual machine. How long did it take? 12 hours of migration. The software team or the operation was not affected, but it took too long.

10 minutes quick rollback vs 12 hours of migration? If I could do the quick rollback from the storage snapshot, I would be done in 10 minutes.

I think this feature will be a serious improvement for Veeam. It is important that you can offer such an opportunity even if no one requests it.

Could you you take note of the requests that can be made?

[Mildur]

It looks like you are looking for a DR Solution.
CDP or Replication would be a solution for you as long the required features are not exists and you have a low RPO Requirement.

Yes I know, it will take twice of the storage. But if the feature is not there, then we have to find a workaround for that Replication is the workaround and it is build for big vms like yours.

Veeam releases new big features once every year.
I don‘t see this feature (If veeam decides todo it of course) this year or 2022, because I think, the main features for V12 are already decided. VeeamOn 2021 is soon

[Gostev]

It is important that you can offer such an opportunity even if no one requests it.

This is really not how prioritize missing features though instead, we always focus on top requests from our users.

[crackocain]

“If I had asked people what they wanted, they would have said faster horses.” - Henry Ford

Users not requested because only %4 percent restore is Instant Recovery. I think most parts of backup related instant VM recovery. How many percent use this forum? How many percent use storage snapshot integration? How many user know CoW snapshot and RoW snapshot difference? How many user know SCSI UNMAP and know this process problematic for storage arrays?

Nevertheless i start this phenomenon right now.

By the way How many users have to make requests to make you think the demand is high?

[Gostev]

The analogy does not really apply in situations when people don't even have actual horses.
We'd need to deliver those first, before we even start thinking about faster ones.

I will just say that some still-pending features have hundreds of requests and been waiting their turn for many years now.
This is why delivering features "even if no one requests them" is not really an option for me.

By the way, this has nothing to deal with how many people visit this forum, because it is just one of very many feedback channels.