some days ago we had big troubles with our database which was corrupted and refused the connection. I checked when we had a stable state of it and did a quick rollback via veeam so that the disks were exactly in the state of the point in time where the database seemed to be ok. So far so good, everything was working fine and within some minutes we were online again.
But guess what, this was just the beginning of the story... Some minutes later I realized that a specific operation had caused the same problem again and I tried to rollback again via veeam to the same point in time. But this time, veeam didn't use CBT, it took 3 hours to write the whole disk back to the original vm which was very very painful at that moment.
Can please someone explain to me why quick rollback using CBT only worked for the first time?
CBT is resetted at restore as it would otherwise have different block changes with same CBT change number.
Let's say actual change number is 100 you change something and the change number is now 101 with Block 30299 to backup. You backup block 30299 at incremental run.
Now you reset the VM to the old change number 100 (revert the 30299 block to original value).
You do not reset CBT.
Next change you do will be marked as change 101 but your application change block 4539875. So it would not help to restore 30299 which was backed up.
The only option here is to do a full recovery (or Instant Recovery if you need the server available immediately).
Best practices is to create a backup after the restore anyway. In that situation you can do a CBT restore again if you create new backups.
You have a vm and you do a backup. Data changes and during the next backup you only backup changed blocks using vmware's CBT functionality.
Someday you perform a quick rollback which uses CBT, veeam detects which blocks have changed since the point you have choosen to do the rollback and overrides those blocks using the backup as a source. Of course your vm has the same state as it had when you did the backup but the rollback operation itself is still tracked by CBT, right? Or is CBT switched off during restore (than it would be clear to me)?
If CBT will be switched off during restore, I would be curious why veeam decided to do so...
You have a VM and do backup "Restore Point 1"
You change a file "1.txt"
You do a Backup "Restore Point 2"
You do a Quick Restore with CBT restore to Restore Point 1
You change another file "2.txt".
Now you have asked why we do not allow a CBT restore from "Restore Point 2" collected CBT informations to "Restore Point 1".
We would restore then the file "1.txt" because that is what we have collected as change in "Restore Point 2" but you changed file "2.txt" after your restore... That makes no sense... All changes are not exactly similar after restore, so the CBT informations collected in older restore points are useless. That is why we reset CBT, that nobody will run into that mistake.
It is technicaly not possible.
If you want to revert the new changes after your restore, you need to create a new CBT reference point with a new backup.
So if you perform the following it would work....
VM backup "Restore Point 1"
Change a file "1.txt"
Backup "Restore Point 2"
You do a Quick Restore with CBT restore to Restore Point 1 and perform immediately a backup (as CBT informations are not usable it is a snap and scan backup (100% read). => "Restore point 3"
A new change is made to file "2.txt".
then perform a Backup "Restore Point 4".
Restore with quick restore is possbile to the stage of Restore Point 3
However you can always use Instant VM Recovery on any of these restore points if you need a specific stage of your database very quick.
Hi Michael,
please send me your contact details and will take care that one of our Systems engineers or me will contact you. Depending on time zone.
andreas.neufert (at) veeam.com
