Yellow Bricks

by Duncan Epping

VCB

Changes to Snapshot mechanism “Delete All”

· ·

Don’t know if anyone noticed it or not but with the latest set of patches VMware changed the “Delete All” mechanism that is part of the Snapshot feature. I wrote multiple articles about the “Delete All” functionality as it often led to completely filled up VMFS volumes when someone used without knowing the inner workings.

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.

Using the VSS Driver for backups?

· ·

I received an email from one of my readers, Kevin, about using the VSS Driver for Backups. As of 3.5 Update 2 this feature has been introduced. I knew that there was a catch to using the VSS Driver but it seems that many people have overlooked a little detail on page 50 of the documentation of which Kevin was one.

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.

in the ghetto….

· ·

William Lam just updated two of his most popular scripts. If you haven’t looked at them yet, make sure you do as they are worth it. ghettoVCB(g2) enables the backup of virtual machines residing on either an ESX or ESXi host. ghettoVCBg2 is a complete rewritten and enhanced version of ghettoVCB or as William puts it “harder, better, faster, stronger”.

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

VMware Data Recovery 1.0.1 released!

· ·

Although the VMware download section has not been updated VMware Data Recovery 1.0.1 has been officially released. Click on VMware Data Recovery 1.0 in the download section and you will be presented with the following:

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”.

VCB Management Console 1.0.6 Beta

· ·

@lamw pointed me out via twitter to the “diy” VCB Management Console. The “vcbMC” is a front end  for scheduling and creating backup jobs based on VMware Consolidated Backup. As “athlon_crazy” points out you don’t need to remember all the VCB commands and parameters. You can use vcbMC to browse all your VM’s and back them up according to the schedule you created:

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