Comprehensive data protection for all workloads
Post Reply
psmith
Novice
Posts: 8
Liked: never
Joined: Apr 22, 2009 7:23 pm
Full Name: PSmith
Location: Grand Rapids, Michigan

Worng Free Space Results With Symbolic Links On Backup Jobs

Post by psmith »

Running Veeam 4.1.2 backing up ESX 4.1 host. The backup target is a Linux server with the root on a 20GB logical drive and the backups going to a mounted volume at /mnt/vg001/lvol1/VeeamBackups

Not wanting to type in the full path for every ESX guest machine we are backing up, we created a symbolic link at the root filesystem (VeeamBackups -> /mnt/vg001/lvol01/VeeamBackups).

What we have experienced is that when Veeam goes to check the amount of space available on the backup jobs that have the shortened path, Veeam is getting free space available from the root partition not the actual backup location. We had some log files run large on the root partition and it dropped below 2 GB of free space. Veeam started emailing us that we were out of space during backups even though at the backup location of /mnt/vg001/lvol01/VeeamBackups which has over 5TB of free space still.

Also when you are creating or editing a backup job and you get to the backup destination screen and you click the Check Space button, on the jobs using the link of /VeeamBackups it reads the size of the root partition not where the link is actually pointing to.

Just looking for a way around this. It doesn't stop the backup job, we just unnecessary warnings.

Thanks
Vitaliy S.
VP, Product Management
Posts: 27368
Liked: 2797 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Worng Free Space Results With Symbolic Links On Backup J

Post by Vitaliy S. »

Hello Phil,

It sounds like there is a bug in script that calculates free space, thank you for pointing this out.

We use df command to show the amount of disk space that is free on file systems. The reason why you see the same behavior while receiving emails and checking free space, is that we use the same script in both situations. It seems like the script can't "understand" the link on the root file system properly.

To avoid these situations, you should be using full paths as destination for your backups. I will submit this bug to our internal bug tracking system right now.

Thanks again!
Post Reply

Who is online

Users browsing this forum: Bing [Bot], Paul.Loewenkamp, RubinCompServ and 116 guests