Version 10 - vsphere API for I/O filtering - well done VEEAM

[mcz]

Hi,

just watched the livestream of the veeamON yesterday and got in touch with some new features of v10. Something that I always wannted to have was the ability to backup "the live data" of a running business-critical VM to reduce the loss of data in case of desaster as good as possible. This will now be introduced in v10 using the vsphere API for I/O filtering - well done, VEEAM

The thing is that we are using an old database for our business-critical application which can't be changed that easy in an acceptable amount of time. This database does not have a VSS writer and therefore a hot-backup won't be application aware. We are stopping the service at night via script but of course this cannot be done during business hours. I think the new feature in v10 will be a gamechanger because veeam will be able to backup the write-operations of a VM on datastore level and because of that we should be able to backup our data even during business hours.

Now the question is if my assumption is right or not. I would say in our case if we do regular backup via VSS- and vmware-Snapshot it could be that some changes to the database are written while others are not and this is the reason why the database could or will be corrupted if we do the restore... But the new feature in v10 will backup the sequential written data to the virtual disk and in the end this would be equal to a power loss or bluescreen or whatever a vm could forcible stop from a normal operating. So if my database is able to recover from power loss, it will able to recover from a restore created by the new feature in v10.

Thank you for your thoughts and response!

Mike

[foggy]

Hi Michael, your assumption is correct in the sense that with Veeam CDP you will be able to failover the VM to its crash-consistent state as of any point in time within the specified retention (with default RPO of 15 seconds).

[mkretzer]

... and the nice thing with CDP solutions is the ammount of restore points to choose. If one point does not work use the next one.

Will this only work with replication or also with backup targets?

[nielsengelen]

Replication as a start

[mkretzer]

Ok feature request time: Please add CDP to backup targets as well so that we can restore any server to any point in time as with SQL log backup

[mcz]

Replication as a start

I guess it's currently not possible to use CDP in combination with backup because vmware only certifies for caching and replication purposes, right?
https://code.vmware.com/programs/vspher ... -filtering

[nielsengelen]

Correct.

[johnlong]

Just to clarify, cdp only, no journaling. Is that correct? Journaling would allow me to get rid of my "other solution".

What about licensing?

I'm so happy to finally see this feature!

One other question. Will the replica vm be registered in the target vcenter server or will it need to be registered during recovery? I'm kind of assuming it will function similar to the way the snapshot replication works today, except no point in time recovery, assuming journaling isn't happening.

Thanks,
John

[Mike Resseler]

Hi John,

Can you explain what you mean by journaling? Not sure what the "other solution" means by it. But if it means being able to recover from a certain point in time (15 seconds ago, 30 minutes ago, 2 hours ago or even 2hours, 3 minutes and 45 seconds ago...) Then yes. It will be possible to do this. These are crash-consistent restore points and not application consistent.

The replica VM will indeed be registered and we will have the possibility to start the replica from one of those restore points. Obviously, if you need to go back a serious amount of these recovery points, it might take some time to do that work but we will see more results on that when we are further in the development phase.

We will also provide the possibility to create specific recovery points (for example, a delta every 4 hours or something) and for longer retention there will be possibilities also, including to do a VSS recovery point (application consistent)

From a licensing perspective... To be decided

Hope it answers your questions
Mike

[cbc-tgschultz]

I'm pretty excited for this. We've had to work around issues with snapshot replication by using the mechanisms provided by individual applications (exchange DAG, SQL log shipping/availability groups). In my experience these solutions, when they fail, fail badly. In fact, I'm currently enduring a full database reseed to DR (why exchange has to transfer a 500GB database from scratch instead of doing some kind of diff is beyond me, as is why it can't resume if the connection is interrupted in any way). I'm hoping CDP will be more reliable while also allowing us to replace snapshot replication on servers running products that don't support such a mechanism natively. If I could do it with backups it would potentially allow me to have more offsite backup locations too, since I wouldn't need a vSphere server there.

It'd be great if it didn't require a license above Standard, because it's like pulling teeth to get budget for DR, but sadly I think that's unlikely.

[johnlong]

Can you explain what you mean by journaling? Not sure what the "other solution" means by it. But if it means being able to recover from a certain point in time (15 seconds ago, 30 minutes ago, 2 hours ago or even 2hours, 3 minutes and 45 seconds ago...) Then yes. It will be possible to do this. These are crash-consistent restore points and not application consistent.

The replica VM will indeed be registered and we will have the possibility to start the replica from one of those restore points. Obviously, if you need to go back a serious amount of these recovery points, it might take some time to do that work but we will see more results on that when we are further in the development phase.

That answers my questions. My other solution is another vendor that we use for CDP replication. Journaling is basically what you described. The ability to pick a point in time during the journaling period to recover to. So if corruption is replicated, you can pick a point in time to recover to, like 2hours, 3 minutes and 45 seconds ago just prior to the corruption happening. The amount of data that is retained in the journal could be days depending on the amount of change in your environment and the space you dedicate to journal storage. So if I dedicate 500GB to my journal storage and my change rate is 250GB a day, then I could in theory have 2 days of journaled data that I could recover to at any point in time during that 2 day period. The ability to create checkpoints in the journaled data is icing on the cake!

Thanks,
John

[Mike Resseler]

So I assume you will be beta testing this the moment there is a beta

(And thanks for giving us the feedback)

[johnlong]

Yes, I'll try it out. I just hope the new CDP feature is included in our existing license, wishful thinking, or at the very least doesn't cost more that the maintenance and support renewal for our existing CDP solution.

Thanks,
John

[Mike Resseler]

That is something which isn't decided at this point in time!

[leizerbeam]

Ok feature request time: Please add CDP to backup targets as well so that we can restore any server to any point in time as with SQL log backup

interesting feature request... since CDP is replicating each I/O transaction (or almost every transaction) synchronously - i wonder what your RPO expectations are to backup targets (which are typically slower than primary)? Do you expect improved RPO to… sub hour or sub day (how many hours exactly) to backup targets?

[johnlong]

interesting feature request... since CDP is replicating each I/O transaction (or almost every transaction) synchronously - i wonder what your RPO expectations are to backup targets (which are typically slower than primary)? Do you expect improved RPO to… sub hour or sub day (how many hours exactly) to backup targets?

If there are too many changes to write to the target, the changes are queued. If the queue is exceeded then it will trigger a synchronization, and you might loose part of that point in time until it can catch up. Most likely the bottleneck will be the WAN. If you have a WAN connection fast enough to replicate in real-time (CDP) then you probably have the budget for fast storage at the target site.

With fast enough storage and WAN links you should be able to achieve an RPO of seconds even during peak usage.

At least this is my understanding of how it will work with VEEAM CDP.

[Mike Resseler]

John,

While not everything is written in stone yet, we are looking into various ways to catch queues and to make sure that you don't loose part of that point in time. But as said, it is not written in stone yet so until we are further in the development and we have done some serious testing I can't give much details as they might change

Mike

[StevenMeier]

luved the Veemon conference this year.(went from New Zealand)

Really excited for CDP as we have customers that require this sort of critical Backup.

An as a cloud Service provider , being able to provide this level of "security" without having to use the SANS to do this is awesome.

One thing I cant remember from this was the VMWARE versions CDP will support...

Can you remind me.

Cheers
Steve

[Mike Resseler]

Hi Steven,

Thanks for liking the VeeamON conference. We were also pretty excited about it

The VAIO libraries are available since vSphere 6.0 U1. However, we didn't announce system requirements for Veeam CDP yet and we will only be able to announce those close to release, when our stability testing is done.

Cheers
Mike

[gingerdazza]

Interested to see the deployment of Veeam CDP using the VAIO framework. Sounds good on paper. Is it anticipated that CDP will be able to protect multiple VMs in a single consistency group? Or can it only protect individual VMs? Also, will there be PIT rollback capabilities? - I'm thinking something like Zerto's journal capability to roll back a failed over VM to any point in the last x days with 5 sec granularity.

Thanks

[foggy]

Some information about this functionality can be found in this thread, while more details will be available upon release.