Source

When using the Delete All option in Snapshot Manager, the snapshot farthest from the base disk is committed to its parent, causing that parent snapshot to grow. When the commit is complete, that snapshot is removed and the process starts over on the newly updated snapshot to its parent. This continues until every snapshot has been committed.

This method can be relatively slow since data farthest from the base disk might be copied several times. More importantly, this method can aggressively use disk space if the snapshots are large, which is especially problematic if a limited amount of space is available on the datastore. The space issue is troublesome in that you might choose to delete snapshots explicitly to free up storage.

This issue is resolved in this release in that the order of snapshot consolidation has been modified to start with the snapshot closest to the base disk instead of farthest. The end result is that copying data repeatedly is avoided.

Just to give an example, 4 snapshots:

Old situation (pre vSphere 4 Update 2)

• Base disk – 15GB
• Snapshot 1 – 1GB –> possibly grows to 13GB
• Snapshot 2 – 1GB –> possibly grows to 12GB
• Snapshot 3 – 1GB –> possibly grows to 11GB
• Snapshot 4 – 10GB

Snapshot 4 is copied in to Snapshot 3, Snapshot 3 in to Snapshot 2, Snapshot 2 in to Snapshot 1 and Snapshot 1 in to your Base disk. After the copy of Snapshot 1 in to the Base disk all Snapshots will be deleted. Please note that the total amount of diskspace consumed before the “Delete All” was 28GB. Right before the final merge the consumed diskspace is 61GB. This is just an example, just imagine what could happen with a 100GB data disk!

New situation

• Base disk – 15GB
• Snapshot 1 – 1GB
• Snapshot 2 – 1GB
• Snapshot 3 – 1GB
• Snapshot 4 – 10GB

Snapshot 1 is copied in to Base disk, Snapshot 2 is copied in to Base disk, Snapshot 3 in to Base disk and Snapshot 4 in to your Base disk. After the copy of Snapshot 4 in to the Base disk all Snapshots will be deleted. Please note that the total amount of diskspace consumed before the “Delete All” was 28GB. Right before the final merge the consumed diskspace is still 28GB. Not only did VMware reduced the chances of running out of disk space, the time to commit the snapshot by using “delete all” has also been decreased using this new mechanism.

NOTE The VSS component gets installed by default when you do a fresh installation of VMware Tools shipped with ESX Server 3.5 Update 2. If you upgrade from an earlier version, you need to install the VSS component manually.

Please be aware that when you want to use VSS on your existing environment you will need to manually upgrade your version of VMware Tools and select the VSS driver. For Windows 2008 and Vista the VSS driver is not installed by default even when doing a clean install this means that you will need to manually add the driver when VSS based backups is a requirement.

ghettoVCBg2

11/17/09 – The following enhancements and fixes have been implemented in this release of ghettoVCBg2. Special thanks goes out to Gerhard Ostermann for assisting with some of the logic in the ghettoVCBg2 script and the rest of the ghettoVCBg2 BETA testers. Thanks for everyones time and comments to make this script better!

Enhancements:

• Email log support
• Include/exclude specific VMDK(s)
• Additional logging + dry run mode

Fixes:

• Independent disk aware
• Large VMDK backups

Original script, but updated with new features and a bug fix:

ghettoVCB

11/17/09 – The following enhancements and fixes have been implemented in this release of ghettoVCB. Special thanks goes out to all the ghettoVCB BETA testers for providing time and their environments to test features/fixes of the new script!

Enhancements:

• Individual VM backup policy
• Include/exclude specific VMDK(s)
• Logging to file
• Timeout variables
• Configur snapshot memory/quiesce
• Adapter format
• Additional logging + dryrun mode
• Support for both physical/virtual RDMs

Fixes:

• Independent disk aware

Latest Released Version: 1.0.1 | 07/09/09 | 176771

You can find the release notes here. I want to highlight the following resolved issue as it has been discussed by several bloggers(eric sloof, scott lowe):

Large Temporary Files Removed as Expected
Data Recovery modifies virtual machines’ vmdk files’ settings so a snapshot can be created for backup purposes. In the past, after the backup has been created, the vmdk file’s settings was sometimes left configured for snapshots even after the backup was complete. This led to these virtual machines being left in snapshot mode while accumulating snapshots that were undetected by vSphere Client. This process has been redesigned so that these temporary files are no longer be left behind. In previous versions of Data Recovery, this issue can be resolved by following the process described in the knowledge base article titled “Delete ddb.delete entries and snapshots left behind by Vmware Data Recovery”.

I haven’t tested it myself so far unfortunately, make sure to test the results of the backup.

Diskeeper is a 3rd party defragmentation product that has the ability to defragment unmounted NTFS volumes that are presented to the VMware Consolidated Backup proxy. This means that it can defragment RDM LUNs. Unfortunately, this creates the possibility of inconsistencies in the file system if there is a virtual machine running on that RDM.

The Automatic Defragment option causes the defragmentation to take place.

Consult your Diskeeper documentation to obtain instructions for disabling this feature in the version of the product that is installed on the VCB Proxy server.

Be aware to not use Diskeeper on your VCB proxy!

In addition to the ESXi backup through VCB that was introduced with version 2.0, Veeam Backup 3.0 now supports ESXi backup without VCB. Veeam Backup is the only VMware backup solution that lets you backup and restore virtual machines running on all existing editions of ESXi, including ESXi free.

Now head over to Veeam and download your trial and start doing full VM backups. Veaam Backup also provides you with a file level restore:

Veeam’s fast file-level recovery feature allows you to restore individual files from your image-level backups and replicas in seconds, without having to extract the full VM image to your local drive.

Just a tip, I would suggest to do a “zero-out” before running the full VM backup!

Leo did a great job in explaining how to build up a decent Template. Leo even included a way to regularly zero out the Linux Filesystem for the purpose of VCB image level dumps with small footprints.

And although Leo’s article talks about Linux only this also applies for Windows. If you will be doing VCB then remember to zero-out your filesystem every once in a while. Linux doesn’t scrub the sectors where the files resided and neither does Windows. I wrote an article on how to do this from within Windows. Yes you can do it by hand via the “shrink disk” option in VMware Tools, but as Leo already pointed out there’s no way of scheduling that one, as far I have discovered.

So most of the stuff written about in Leo’s article applies to Windows, yeah also the partition alignment! DO IT! But the zero-out procedure won’t work, I’ve wrote one a while back and here it is:

Set WshShell = WScript.CreateObject("WScript.Shell")
Dim fso, d, dc
Set fso = CreateObject("Scripting.FileSystemObject")
Set dc = fso.Drives
WshShell.RegWrite "HKCU\Software\Sysinternals\", 0, "REG_SZ"
WshShell.RegWrite "HKCU\Software\Sysinternals\SDelete\", 0, "REG_SZ"
WshShell.RegWrite "HKCU\Software\Sysinternals\SDelete\EulaAccepted", 1, "REG_DWORD"
For Each d in dc
If d.DriveType = 2 Then
Return = WshShell.Run("defrag " & d & " -f", 1, TRUE)'
Return = WshShell.Run("sdelete -c " & d, 1, TRUE)
End If
Next
Set WshShell = Nothing

Be sure to download Sdelete before you start, and remember that this script also does a defrag. If you are running “thin” disks than doing a defrag might not be the smartest thing to do, if so just delete the following line from the vb script:

Return = WshShell.Run("defrag " & d & " -f", 1, TRUE)'

VMware Consolidated Backup needed to have identical LUN ID’s to be able to match LUN’s but that has changed. It doesn’t matter anymore which LUN ID your host and proxy server see cause VCB just compares VMFS signatures. So I can hear you guys thinks, what about my RDM’s? (Raw Device Mappings) Well obvious VCB can’t compare the VMFS signatures, but it can compare the NAA ID’s and that’s what it does as of VCB 1.1. So in other words, as long as you just publish all LUNs you want VCB to backup it doesn’t matter which LUN ID they have.

And if for some reason your SAN doesn’t support NAA ID’s, well then you will be stuck with the “matching LUN ID’s” method you have been using for a while.

By the way NAA stands for “Network Address Authority” and is a unique identifier for you LUNs.