I just came back from a two hour session with Vizioncore about their future products and the direction they are taking. Interessting stuff. What I wanted to bring back to you guys is three features we will see in the upcoming vRanger version 5 release.
- Dedup
- CBT (Change Block Tracking)
- ABM (Active Block Mapping)
These features will all help in their own way to dramatically reduce the backup window.
Dedup will make sure that only unique blocks will be transfered to our backup location.
CBT (A vSphere ESX(i) kernel feature) will make incremental backups highly effiecient.
ABM will make sure that we only backup the active data in the VMDK and not data that has been deleted from within the guest operating system.
I will try to get signed up on the version 5 beta program. I will keep you updated on this.
Frank – you really should check out Veeam Backup… they had all of this back in 2009.
I did not know that veeam had ABM and Dedup? I know about CBT. Can you verify?
Veeam does not have ABM, that’s VZC patented but Veeam does have Dedupe (since 2008) and CBT (since 2009). Veeam Backup & Replication also has full support for the vStorage API’s for data proection (since 2009) and it even works on Windows Server 2008 R2 x86 and x64. Full and proper VSS integration is also included without relying on VMware’s VSS implementation. File level recovery for Windows and *nix (since 2009), full ESXi support (since 2009), Backup and Replication in 1 product for 1 price…the list goes on.
Oh yeah, all the technologies above are available today, no waiting!
I was not clear enough around ABM. Veeam does “synthetic” (forever-incremental) backup, while ABM only makes difference on traditional full backups. vRanger needs ABM to be able to fit backup window because of no synthetic backup – they have to use ABM to speed up fulls. But, it is important to note that ABM only works for Windows guests, while synthetic backup works with any guest OS.
Just a few notes about ABM (Active block Mapping)
1. ABM is the process of mapping deleted data from a windows Guest to the outside of the VMDK, agentless, Scanless and in less than a second.
2. Its helps on the Full, incremental, or Differential’s you pick (in the product today). Of course VM’s delete data in-between backup cycles regardless of the type of backup type you pick. Also, what’s nice about having Full, incremental, or Differential’s is when you sweep to take it will be a small about of files to tape each time and not Large files each time to tape.
3. We also have found that VMware’s CBT (change block tracking) includes deleted data, so if you delete data in-between backup cycles and use the vStorage API to query for the change block map, it will include deleted data. So, we can apply our AMB filter to the CBT info and filter out deleted data from incremental, or Differential’s backups while using CBT. This will reduce backup times and backup foot prints for any backup type.
4. Any backup you do Full, incremental, Differential’s or synthetic, of course you don’t want deleted data stored in these archives, this is what ABM does for you.
Thanks Jason
Jason – of course you could artificially create situation where AMB will make difference during incremental backup, but such situation will not be realistic.
In practice of real world application workloads, ABM is great for fulls, but does not make any difference for incremental backups. Even Vizioncore will honestly tell you this, ask their SEs.
These 2 facts are hard to argue:
1. Data deletion on servers running real-world workloads happens rarely.
2. Those rarely appearing deleted data blocks are instantly reused by new data.
I read about it some days ago in another blog and the main things that you mention here are very similar