cancel
Showing results for 
Search instead for 
Did you mean: 

How much space is required for client side deduplication?

arctics
Level 3

Hello,

We are running BE 2012 on a 3600 R2 appliance.  When attempting to run a backup of SQL located on a vm, it fails with the following error:

Storage device "Appliance_Dedupe_BACKUP:3" reported an error on a request to write a media location identifier (file mark).

Error reported:
A device attached to the system is not functioning.

Veng-sql2-backupVENRetailWindows_V-6.1.7601_SP-1.0_PL-0x2_SU-0x110_PT-0x3 - An unknown error has occurred.

 

However, more importantly, the backup job seems to completely bring down the vm. In discussion with vmware, it appears as though local disk space on the vm is expanding during the backup, and since the disk is configured as thin, it automatically expands causing the entire datastore to fill up, bringing the vm down and preventing it from starting up again until space is freed up.  We were able to bring the vm back by moving the vswp file to another datastore.

 

So my question is, does this sound like a problem with insufficient space required for client side dedupe?  How can we determine how much space is required for this?  When checking the Backup Exec AOFO Store folder on the vm, it's empty, which I understand automatically cleans up after a reboot.  Since this occured on a production server, we can't rerun the backup until we know for sure what caused the issue.

Thanks.

1 ACCEPTED SOLUTION

Accepted Solutions

arctics
Level 3

Thanks for the responses.

Actually, after a lengthy discussion with support, it turned out the cause of the issue was not client side dedupe, but instead database snapshot backups of sql on the vm using the remote agent. 

So the particular vm in question resides on a datastore with very limited space, and is a dedicated sql 2008 vm.  This machine was configured with a remote agent to do file level backups, sql database backups and snapshot backups of the vm.  The file level backups appeared to be running ok, but the sql database backups running into issues, as prior to the backup, a database snapshot is taken, causing disk space usage to increase, and in turn, causing the thin disk to expand, filling up the datastore, and bringing down the vm.

Thanks again.

View solution in original post

3 REPLIES 3

butlercp
Level 3
Employee

Are you backing up the VM using the vStorage APIs through the Backup Exec VMware Agent?  or putting an agent in the VM and backing up over the LAN?

NeerThadarai
Level 5
Employee Accredited Certified

The client side dedupe will only work if you have the Remote Agent installed in the Virtual Machine and you are doing backup using the Remote Agent.

We cannot use the client side dedupe with the AVVI based backups as that would use the vStorage APIs and we cannot install Remote Agent on the ESX host.

For the client side it's recommended to have min. of 2-4 GB of Memory and windows 2003 and above.

 

arctics
Level 3

Thanks for the responses.

Actually, after a lengthy discussion with support, it turned out the cause of the issue was not client side dedupe, but instead database snapshot backups of sql on the vm using the remote agent. 

So the particular vm in question resides on a datastore with very limited space, and is a dedicated sql 2008 vm.  This machine was configured with a remote agent to do file level backups, sql database backups and snapshot backups of the vm.  The file level backups appeared to be running ok, but the sql database backups running into issues, as prior to the backup, a database snapshot is taken, causing disk space usage to increase, and in turn, causing the thin disk to expand, filling up the datastore, and bringing down the vm.

Thanks again.