FlashRestore and vPower: Lower that RTO

20 09 2010

 

VEEAM and Vizioncore (vRanger) both have a feature in their newest backup products that lets you “instantly” restore a vm, so users can get back to work on the machine right away.  Both technologies spin up a vm from the backup right on your backup media.  You dont have to wait for anything to be copied back across the network.  Sweet! 

http://www.veeam.com/go/vPower?ad=backup

http://vizioncore.com/sites/default/files/Flash%20Restore%20Datasheet.pdf





vRanger and VEEAM: Scale Issues

16 09 2010

 

I manage the backups for about 400+ vms on a daily basis.  We are using a mix of vRanger and VEEAM to backup our vms both at our main site, and at a couple of smaller branch sites.  We use vRanger for our main site and VEAAM for the branch sites.  As far as features, vRanger and VEEAM have flip-flopped in the past, with VEEAM usually taking the lead and vRanger following suit 6 months to a year later with certain features (CBT support for instance).  The main differentiator that caused us to choose one over the other for the our production site is SCALE.

vRanger is our choice for VM backups in our production site.  As we must fit all 400 of these backups into reasonable backup windows, we are using the limits available for tasks running per datastore, host, and backup Groups.  By using jobs based on backup groups composed of small numbers of hosts, we dont have to constantly edit jobs to exclude new vms, and we have a small number of jobs to deal with.  The limits per host and datastore ensure that we are running multiple vm backup tasks at any given time.

image  This is the key differentiator from VEEAM.  VEEAM only processes vm backup tasks one at a time.  So if I have 30 vms to be backed up in a job, it will plod through them one at a time.  If it hits a particularly large backup, you are stuck waiting.  On the flip side, with vRanger we can often have 6-8 vm backup tasks all running at the same time.  Sure, it will still take some time to backup the larger vms, but it is working on several others at the same time.  I talked with VEEAM at VMWorld about this a couple of weeks ago, and their answer was to setup additional backup servers to run things simultaneously.  Wrong answer.  Who wants to add another box you have to manage and try to schedule all that out?  No thanks.  The other option presented was to make a job for each vm.  HA!  Don’t even get me started on why that is a nightmare.

 

image

VEEAM is our choice for the smaller branch sites.  These have a small number of vms (about 10).  They all have CBT enabled.  These 2 factors mitigate the sequential nature of VEEAM, as the backups all finish in the nightly backup window just fine.  The killer features that made us use VEEAM for the branches is the Enterprise Manager and the Virtual appliance mode.  Enterprise Manager lets us see all of our backups and history for multiple installs of VEEAM across our branches from a single web page.  Very nice.  Virtual appliance mode will hot-add the vm disks to the VEEAM virtual server installed at each branch for backup, making them faster.  This is much easier to do than trying to “mount” the vmdk’s on a physical box like VCB used to be.

 

What are your thoughts?  How are you backing up your vm infrastructure both big and small?





Oh Snap! Watch your block size!

23 02 2010

             So, here is the scenario.  You have a VM with a regular, lets say 40GB OS drive, and a 300 GB Data drive.  Now you want to backup the vm using something like vranger or veeam.  As part of the backup process, the VM is snapshotted (is that a word?).  Only problem is, you get this lovely error….

image

          Uh oh!  But my OS and Data drive are on separate volumes!  There is plenty of room on both!  What gives?  It all boils down to where your working directory is, and the block size of the volume that it resides on.  As you may know, when you are creating and formatting a volume for use in vsphere, you are asked what block size you would like to use.  By default this is set to 1MB block sizes.  The block size directly relates to how large of a file that can be created on the datastore. Let’s look at a table of the maximums as it relates to block size.

Block Size                            Maximum File Size

1MB 256 GB
2 MB 512 GB
4 MB 1024 GB
8 MB 2048 GB

                As you can see, if you go with the default 1MB block size, you can only have a file of 256GB in size.  One more piece of the puzzle reveals our underlying issue….the working directory.

image

                In vsphere, when a snapshot is created, there are some checks that are done to make sure that files created can fit into the datastore.  BUT this check is done against the datastore that contains the working directory for your VM.  In our example, the OS drive.  If our OS datastore only has a 1MB block size, it thinks that your 300GB snapshot of your data drive wont fit!  It does not base it’s estimation on if it will fit on the datastore where the 300GB vmdk resides, but instead on where the working directory resides……the 1MB block size datastore!  We cant fit a 300GB file on a 1MB block size datastore, so the snapshot fails!

                 Ok great.  It failed.  Now what?  We need to storage vmotion the OS drive and configuration files to a datastore with an 8MB block size.  This is to accommodate a secondary drive all the way up to 2TB, while simultaneously changing the working directory.  Right click the offending vm, choose Migrate, then Change Datastore, then click the advanced button and select a datastore for the config file and hard disk 1 that has a 8MB block size.

image

Once the storage vmotion is complete, you can now snaphot your vm and get it backed up!

 

More info:

http://www.yellow-bricks.com/2009/08/24/vsphere-vm-snapshots-and-block-size/

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1012384





VMWare Data Recovery Manager: Not quite ready for production

22 07 2009

Here is my quick take on data recovery manager for VMWare.

 

PROS:

1.  Deduplication and compression

2.  Runs in a vm, easy to deploy.

3.  Backup window easy to configure…pick a block of time and it runs the backups within the window.

 

CONS:

1.  No tape option or duplicate backup set option.  I realize this is difficult within a vm, but with no offsite option, backup scenarios are limited.

2.  There have been some bug fixes and they were some major glaring ones.  For instance, not deleting old snapshots with 1.00  I’m glad they fixed that issue, but what else is going to show up as more people use it?  It seems to need a few more revisions before I could trust it.

3.  Faulty backup sets…there were quite a few times when the recovery manager would deem a certain backup unfit to be restored from.  Why?  How do I fix it?