Advertisements

EqualLogic Veeam followup

Posted on April 7, 2010 by mellerbeck

So far Veeam has been treating me well. When backing up multiple VM’s at the same time it really does peg out the processor. I’m glad I choose to install into physical instead of virtual.

I of course had an iSCSI attached volume that veeam can’t ‘see’ so I had to remedy that by moving mailboxes all over crime and creation. Gave me a

Discovery phase failed.
Cannot add volumes to the snapshot set.
Cannot add a volume to the snapshot set. Volume name: [\\?\Volume{fca370fa-f010-11de-b405-005056b07383}\].
Cannot add volume to the set of volumes that should be shadowed.
VSS error: VSS_E_PROVIDER_VETO. Code:0x80042306

But this was to be expected. After creating a new volume (I love how easy I can add and remove disk in vsphere!!! too slick) I learned the hard way about block size (mine of course was too small)

This was the error vsphere\veeam threw

CreateSnapshot failed, vmRef “vm-32”, timeout “1800000”, snName “VEEAM BACKUP TEMPORARY SNAPSHOT”, snDescription “Please do not delete this snapshot. It is being used by Veeam Backup.”, memory “False”, quiesce “False”
File <unspecified filename> is larger than the maximum size supported by datastore ‘<unspecified datastore>

After remedying this http://blog.vmpros.nl/2010/02/04/vmware-creating-a-snapshot-for-a-virtual-machine-fails-with-the-error-file-is-larger-than-maximum-file-size-supported-1012384/

So now I am in the process of backing up our Exchange server. I still am researching the whole VSS integration thing, but this post lays it out pretty well

http://virtualy-anything.blogspot.com/2010/02/understanding-vss-in-vmware-backups.html

And this cleared up for me the concept of synthetic backups

http://veeammeup.com/2008/08/veeam-synthetic-backup-explained.html

This also cleared up my question on how I should group my VM’s

We recommend grouping similar VMs (deployed from one template or based on the same OS) to one job to get best de-duplication ratio, in this case with compression enabled (which is the main weapon against white spaces) you’ll save lots of backup storage space.

I also really like the fact that these backups don’t impact the network at all! SAN based backup is awesome!

Advertisements

Filed under: veeam | Leave a comment »

Blocked by block size

Posted on April 7, 2010 by mellerbeck

So even though I read this post by Duncan http://www.yellow-bricks.com/2009/11/10/block-sizes-think-before-you-decide/

It was too late for me. I had already created a VMFS with too small of a block size. It boils down to what is your workingDir. In my case the workingDir was on a 1MB Block size volume. I ran into this almost exact same problem as written here. http://www.yellow-bricks.com/2009/08/24/vsphere-vm-snapshots-and-block-size/

Disk01 – 10GB stored on VMFS001 with a 1MB Block size
Disk02 – 350GB stored on VMFS002 with a 4MB Block size

VMFS001 contains the working directory of the vm “virtualmachine001″. Snapshots are stored in the working directory. In the case of Disk02 this could mean that the delta file grows beyond the maximum file limit of 256GB of VMFS001 where it will be stored.

Luckily, I think I can migrate data back to my Disk01, delete my Disk02 and then storage vmotion off to a bigger blocked Datastore! Hopefully….

Filed under: Uncategorized | Leave a comment »