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.
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).
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.
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)
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.
Mike Resseler wrote: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!
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.
mkretzer wrote: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?
leizerbeam wrote: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.
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
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.
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.
