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

Problem with Agentless Allocated space

Hi,

 

i use RapidRecovery  6.0.2.144 to backup about 12 ESXi (6.0.0 4192238) hosted VMs agentlessly.

On some of those machines (thin provision disks)the shown allocated space is wrong (says the disk is full).

The problem is then that my base image are bigger than they should be (600GB instead of 30GB on a computer where only 30GB is used).

I tried resetting the CBT but nothing worked so far.

Any help would be appreciated.

Parents
  • Hi Boom:
    There are a few situations when the issue you described happens. If your datastore is NFS, the volumes will be shown as 100% used by default (VMWare issue). If the volumes are eager zero provisioned, they will show full by default (because they are) -- this is just for the record as is not your case. If your VMs are on VMFS datastores you have two possible options which will bring temporary relief (at some point the issue may re-occur). This is also a VMware API issue but we are working to find a way around it.
    1. Storage V-Motion the VMs to a different datastore (this will re-create the disk block map) and will not include any down time
    2. Use the rescan volume option that may be available on the Summary page. This WILL REBOOT the VM but basically does the same rescanning of the disk block map as storage v-motioning the VM.

    Now the good news :)
    The backups contain only the actual data/incremental data on the protected volumes. You can determine that it is the case by checking the size of the jobs in the Core Events tab, by expanding any finished backup and checking the total work information.

    Hope that this helps.
Reply
  • Hi Boom:
    There are a few situations when the issue you described happens. If your datastore is NFS, the volumes will be shown as 100% used by default (VMWare issue). If the volumes are eager zero provisioned, they will show full by default (because they are) -- this is just for the record as is not your case. If your VMs are on VMFS datastores you have two possible options which will bring temporary relief (at some point the issue may re-occur). This is also a VMware API issue but we are working to find a way around it.
    1. Storage V-Motion the VMs to a different datastore (this will re-create the disk block map) and will not include any down time
    2. Use the rescan volume option that may be available on the Summary page. This WILL REBOOT the VM but basically does the same rescanning of the disk block map as storage v-motioning the VM.

    Now the good news :)
    The backups contain only the actual data/incremental data on the protected volumes. You can determine that it is the case by checking the size of the jobs in the Core Events tab, by expanding any finished backup and checking the total work information.

    Hope that this helps.
Children
No Data