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.

0 Tudor.Popescu over 9 years ago

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.
0 boom over 9 years ago

Thanks for the answer.
So , yes my datastore is VMFS, and volumes are thin provision. Unfortunately i cannot Vmotion my VMs because we use VMware essentials which does not include VMotion. Though i tried to turn off the VM and migrate them to other datastore , it didnt help. The rescan volumes option (when available. it seem to be available only after CBT reset) did not help either.
I am confident my backups work fine, just backuping and even more replicating (exemple) 1TB of data instead of what should be 200GB is a waste of bandwidth, time and storage.
If the issue comes from VMware API i'll just wait for their next patch and hope it fixes it.
0 Tudor.Popescu over 9 years ago

Hi Boom:
Please check the actual transfer size in the details of a finished backup (the events tab, tasks panel) -- it should show the actual transferred data (before dedupe and compression).

To pick up your example, for a 1TB volume with 200GB of data, the first snapshot (which has to be a base image) should show 200GB transferred and the subsequent one should be consistent with the changes on the volume since the last snapshot, i.e. 10GB, 25GB,15GB. Again this is shown in the Events tab.

If every snapshot is shown (and marked) as a base image, please let me know.
0 boom over 9 years ago

Hi Tudor,

it seem that unfortunately i do not have the same behavior.
this particular VM for exemple:
Lazy zeroed thick
drive1 150GB drive 111GB used
drive2 500GB drive 244 used

on my base image event tab it shows :

Status:Succeeded
Total Work:649.98 GB
Start Time:10/11/2016 3:00:05 AM
End Time:10/11/2016 6:28:57 AM
Rate:55.56 MB/s
Elapsed Time:3 hour(s), 28 minute(s), 51 second(s)

here screen capture that shows the full allocated space, and size of base image.
0 Tudor.Popescu over 9 years ago

True -- the base images show the total allocated space and the calculations suggest that indeed the total allocated space was backed up. However, the next snapshots are clearly incrementals.
0 boom over 9 years ago

Yes other snapshots are incremental.
Thank anyway for the help, ill wait for esxi next patch

Meanwhile i'll open another topic for another problem with RapidRecovery , see you there.