Free space on datastore.

[jpesick]

I just upgraded to V5 and now I am getting the following error when I run a backup.

Checking free space on source datastore
Production datastore is getting low on free space (408.00 MB left), and may run out of free disk space completely due to open snapshots.
Insufficient free disk space on production datastore.

I am wondering what feature on the new version is requiring more free space on the datastore then the old version did? How much free space am I going to need on each datastore for a backup to complete?

Thank you

[Gostev]

Hi Jason, please check out the What's New document, it explains this new feature in-depth. Hopefully this should prevent what has been quite common Severity 1 support issue for us with previous versions. Thank you!

[Gostev]

By the way, I am fairly sure that 2GB limit is customizable via registry, I can try to find this out for you with developers tomorrow. However, I highly recommend to stick with 2GB threshold for your own good.

[jpesick]

Thank you for the reply Gostev. I increased the size of the datastore so that it had 2GB of free space and everything is working great now.

[durandl]

Hi Gostev,
Could you tell me which feature this is exactly and if I can disable it?

[Sethbartlett]

Tools > Options > Notifications. You can lower the percentage or turn it off.

[durandl]

is there a way to store the snapshots veeam uses in a separate datastore?

[Gostev]

Yes, the snapshot location for each VM can be customized using the workingDir VM parameter (this is VMware functionality though, has nothing to deal with Veeam).

Please note that this parameter works very differently in vSphere 4 and vSphere 5 (because vSphere 5 had changed some rules around the default snapshot placement). VMware has pretty detailed recent blog post about workingDir here, this covers both old and new behavior of both snapshot placement and workingDir parameter.

[tsightler]

Also note that "workingDir" is overwritten if you use storage vMotion and can lead to long term management problems if you have VMs that might be moving around. It's more of a temporary solution that a long term fix. Ideally you should organize your infrastructure to provide space for snapshots.

[ErikZandboer]

Hi all,

Ran into the same problem after upgrading to v6: One VM uses a "data" datastore and the vmdk fills up the datastore completely. There is nothing wrong with that, especially since the vmdk is independent plus the snapshot for the VM is not put on that particular datastore. So there is no harm in completely filling up that particular datastore.

It would be a great addition to the product if it featured some more intelligence on this part. For example I have a second VM, with a similar configuration. That "data only" datastore has some more free space left, so the backup does run "out of the box" (eg without disabling the production store free space warning), but it ends every single day with a warning that the datastore is nearly full, while this datastore is NOT the datastore used to store snapshots.

I don't like backups completing with warnings. It makes me check every single day just to find this issue is really not the issue. Turning the warning off from the tools menu solves this problem, but at the same time makes me blind for any REAL issues. It would be great to see Veeam Backup being able to intelligently find the location of the snapshot-to-be, and only warn/refuse when THAT particular store reached a watermark.

[Gostev]

Hi Erik - I guess the only issue here is that this logic needs to be adapted to vSphere 5 - apparently, right now it still uses vSphere 4 default snapshot placement rule. Thanks!

[ErikZandboer]

Cool. I understand there are many priorities and much to build/rebuild - You are doing a great job and these issues are really minors when it really comes down to it - backing up your environment.

[durandl]

Excellent, I was not aware that the snapshot.redoNotWithParent = "TRUE" was needed on v5 datastores. This was beginning to be troublesome as the backup would cause the datastore to completely fill and bring down the VM

I will give that a shot. Thanks again.

[durandl]

This did not work. I made the change and re-registered the VM and the job failed with the Production datastore is getting low on free space message. I then went into the GUI and disabled this warning and it failed again with the following message:

1/3/2012 9:34:38 PM :: Error: File <unspecified filename> is larger than the maximum size supported by datastore '<unspecified datastore>

This is beginning to be very frustrating as I have created a support case over 24 hours ago, they asked me for the logs 12 hours ago and I have yet to hear back. In addition the wait time on the phone support was over an hour.

I need to get this resolved ASAP as we have no backups of our production file server!

[ErikZandboer]

I think I know what is going on; there is some issue with the blocksize of datastores. I think you may have a mixed environment when looking at VMFS blocksizes. You need to make sure that the Veeam VM is sitting on a datastore with the largest blocksize (8MB probably).

The underlying problem is VMware related, and is this: A VM running on a datastore with a small blocksize cannot hotadd disks that are larger than the maximum filesize allowed by that particular blocksize. So migrating the Veeam VM to a datastore with 8MB blocksize, you will probably fix the issue.

Just my 2 cents...

[durandl]

Hi Erik,
The VMDK is stored on a 8MB block datastore. The datastore I configured to store the snapshots to is 4MB. Should I change this to 8MB just to keep them the same?

[ErikZandboer]

I'm not sure actually... It should not matter for the hotadd functionality, but maybe vSphere is bothered by the fact that the snapshot file COULD potentially grow as big as the original VMDK?? Still, in that case you would be unable to create a snapshot manually as well... Have you tried this?

[Gostev]

Erik is spot on. Durand, please search the forum for your error, there are a few dozens of posts regarding this issue.

[durandl]

Creating a manual snapshot results in the same <unspecified datastore> message. I will be updating the workingDir later tonight and will let you know if moving that to a 8MB block datastore will fix this.

[ErikZandboer]

Please do, would be cool to know what the issue is here.

[durandl]

Seems to have worked. Very strange that this would all of a sudden come up. This backup had been going for a long time without issues...

[ErikZandboer]

Seems to have worked. Very strange that this would all of a sudden come up. This backup had been going for a long time without issues...

Good thing it is solved though Maybe Veeam support can find the underlying reason, but it appears to be a VMware issue and not a Veeam issue.

[Dale.E]

I am new to Vmware and to Veeam Backup, so please bear with me and my learning curve

Before virtualization I used Ghost to create disaster recovery images.
I am now planning our new disaster recovery scheme and testing Veeam Backup to create the needed VM images.

It looks good and I have backed up all the small servers no problem, but when I tried our main server I got a space error?!?

"Production datastore 'DataVolume1 Raid 10' is getting low on free space (292.0 MB left), and may run out of free disk space completely due to open snapshots.
Error: Insufficient free disk space on production datastore 'DataVolume1 Raid 10'."

I understand the problem but I am not sure how to work around it.
The root of the issue is with how I laid out the server:
2x300GB Raid 1 Mirror - O/S and boot volume.
8x146GB Raid 10 - Data volume. This is only used by the main server O/S - W2k3 and shared to all domain clients from there.

When I did the p2v I stayed with the basic design and put all the VM O/S's on the raid 1 volume called 'O.S.Volume.Raid1'
and I created a FMFS on the raid 10 array called 'DataVolume1 Raid 10'
The main server O/S was given the data volume and I created a full NTFS volume to be shared from there. So its full, the NTFS is not but according to VMware 'DataVolume1 Raid 10' is full. Now the whole VM is listed as 647.2GB and there is nowhere to create the snapshot.

I like to keep my data separate, and TBU the whole thing once a week with daily changed file backups.
I like to take monthly image snapshots of my O/S for disaster planning.
I appear to be stuck....

Any pointers?

[jjblaster]

All,

I am having a problem backing up a single VM. We are running ESXi 5 and Veeam 6.1.0.205.

This is a remote site with 9 VMs. The backup outgrew the 2 TB storage allocated for the backups repository so I added another 2 TB datastore and mounted it on our Veeam backup VM. We backup the Veeam backup VM OS disks but exclude the 2 - 2 TB disks in the virtual machine options in the Veeam backup job.

Ever since added the new 2 TB datastore I get the following error when trying to backup the VM even though I have the disk excluded in the Veeam Job.

Production datastore 'BackupVM02-BACKUP02' is getting low on free space (2.0 GB left), and may run out of free disk space completely due to open snapshots.

Code: Select all

Error: Insufficient free disk space on production datastore 'BackupVM02-BACKUP02'

If I remove the new 2 TB disk from the VM setting the the job runs fine and I have the original 2 TB mounted and excluded.

Any ideas on why I am not able to exclude the new 2 TB disk I added to the Backup VM?

Thanks

[Cokovic]

Even if you exclude the disk within Veeam they are still included by VMWare in the snapshot creation process. I assume thats the reason why you get that error as you have insufficient space left on the datastore for the snapshot. Now you have two options. Or you reduce the size of the second disk so enough space is left on the datastore for snapshot creation or you edit your VM and configure your second disk as an independent disk. Independent disks are excluded from VMWare snapshot creation process. And they are automatically excluded by Veeam too as backups rely on snapshots.

[habibalby]

Or exclude the disk from being processed for Backup under the Backup Job Configuration -> Exclusions -> Disks..

[Cokovic]

Or exclude the disk from being processed for Backup under the Backup Job Configuration -> Exclusions -> Disks..

This wouldn't exclude the disk from snapshot process by VMWare itself as far as it isn't setup as an independent disk.

[hoogvliet]

Hello,

I have a problem with some VM's in my Veeam Backup Jobs.
Some VM's have a Physical RDM, I only need to backup the VM so at disk exclusion I only choose for the system disk, but when I run the backup i still get the following error:

Production datastore 'RDM_Mappings' is getting low on free space (1.5 GB left), and may run out of free disk space completely due to open snapshots.
Error: Insufficient free disk space on production datastore 'RDM_Mappings'.

I only choose to backup the system disk and still get low free space on 'RDM Mapping' Datastore.
Does anyone know what i can do to fix this?

Thank you!

[Vitaliy S.]

I'm afraid the only solution is to increase free space on your source datastore.

[dellock6]

Uhm, this is however a strange error message. Do you created a dedicated datastore for RDM mapping files? Are there any other files into that datastore? Bacause minimum size of a snapshot is 16 Mb at time of creation, and it then grows as new data are written into it. Since is a physical RDM no snapshot activity should occur on that datastore...
Is the message coming from Veeam or vSphere?

Luca.