• State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 16 subscribers
  • Views 7484 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

VRanger, since version 7.1, including 7.3, doesn't actually use Active Block Mapping to run backups.

support_52232
over 7 years ago

Since the very first install and through 7.3, VRanger must read the entire VM disk group in order to make a backup. In my case I have 8 VM's with a total of 12TB of space allocated to the Win 2012 R2 volumes in those VM's.

 

The backup must, by time and appearance, read every block of those volumes in order to determine if anything has changed. This means that when using VRanger to do backups, that the backups take 10 hours of a 10GB ethernet connection.

 

I've had this issue since version 7.1 installed in 2014. I have completely uninstalled, reinstalled, etc...

 

After switching to Veeam a full backup takes 3 hours, incremental backups take 20 minutes, for the same VM's. I still have a Vranger contract and have been extremely disappointed with the performance.

 

I see that 7.5 is out and I'll test it, but I don't expect ABM to actually work in 7.5 when it hasn't worked in 7.1 to 7.3.

  • 0 over 7 years ago
    vRanger supports VMware Change Block Tracking (CBT). It's this technology that allows vRanger to very quickly get a list of changed blocks in a virtual machine to speed up incremental (and differential backups). vRanger Active Block Mapping (ABM) is proprietary vRanger technology that further reduces the blocks needed for backup by eliminating the need to back up unused blocks, as well as Windows hibernation and page files.

    In order for CBT to be used by vRanger, it needs to be enabled on each VM. You can enable CBT on the VMware side or from the vRanger My Inventory screen (right-click on the VM). In vRanger 7.5, there is also a new feature to Enable Change Block Tracking on any VMs backed up by the job where CBT is not enabled. If you were testing an existing job created in a prior vRanger version, you'll need to edit the job and explicitly enable this feature.

    If you are sure CBT is enabled and are still experiencing these issues, I'd encourage you to open a support case so our engineers can help you identify the issue.

    Can I also ask you to clarify which version of VMware you are using?

    Thanks.
  • 0 over 7 years ago
    I'm running Esxi 5.5 and update patches for it. I could not find the CBT enable flag in any of the VM's, but, after I upgraded to 7.5 and edited the jobs, I found the flag and have checked it. I have started a new backup in 7.5 and will see how that works. If CBT actually works it will mean a massive decrease in backup time for us.
  • 0 over 7 years ago
    As a side note - I installed 7.5, enabled CBT in the job, and then ran two, back to back. Both jobs took the same amount of time (differential) and both wrote the same amount of data to the backup repository. Since the server I backed-up has little data change, since it was done twice, both were differential, I expected the second immediate differential to take less time and to use less repository space.

    Doing this with Veeam the backup, differential, with change detection, always takes less time and uses less space for a differential followed immediately by the same differential.
  • 0 over 7 years ago
    I have a strong concern about the following statement:
    "Since the server I backed-up has little data change, since it was done twice, both were differential, I expected the second immediate differential to take less time and to use less repository space."

    I always saw it little different. Normally for live VMs each Differential in the same set is larger than previous Diff. Here is from Wiki (en.wikipedia.org/.../Differential_backup)
    "A differential backup is a cumulative backup of all changes made since the last full backup, i.e., the differences since the last full backup."
    So, let's say we have a Full backup, then run 2 Diffs back-to-back. There is no way 2nd Diff will be smaller than 1st one.

    I would recommend to open a support case and provide backup tasks logs for investigation.