Philip Lippard

Please say it ain't so

Backing up to the Cloud

As a result of my recent migration to VMWare ESX Server for my offsite hosted servers, I also needed to consider a backup strategy.  In addition to having a local daily backup option, I also wanted a secondary cloud backup strategy.  I selected the products available from Cloudberry Labs; a software company based out of St. Petersburg Russia.

Content_01 There is a freeware edition of the Cloudberry products, however I selected the Cloudberry Explorer Pro and Cloudberry Online Backup Server Edition.  I have licensed the Online Backup Server Edition for each of my VMWare virtualized servers, and at around 2am each morning Online Backup Server Edition executes their user defined backup plan.

powered_by Cloudberry products support backing up to the cloud services of Amazon S3 (Simply Storage Service), Microsoft Azure, the emerging Google Storage Service and Dunkel Storage (a Amazon S3 compatible service based out of Germany).

The Cloudberry Explorer Pro and Online Backup products both support compression and encryption as features for any backup plan.  The Cloudberry compression feature reduces the amount of data being backed up on an average of 66%; effectively reducing the Amazon S3 storage charge from 15 cents down to 5 cents per GB.   The encryption feature provides an additional of privacy and security for your data.

ESX Server Snapshot Backups

One of the more compelling reasons to use ESX/ESXi Server for virtual server management is the feature called Snapshot backups.  Snapshot backups provide the ESX/ESXi Server administrator with the ability to essentially freeze a virtual machine (VMDK virtual server) at a point in time while scheduled updates or upgrades are being attempted.  Snapshot backups are managed using the VMWare VI Client, discussed in a earlier post.

Take Snapshot When a snapshot is taken all updates (regardless of origin) which occur to the virtual machine will be written to a set of snapshot files, rather than the VMDK virtual machine image; thus providing the administrator with the opportunity to copy the VMDK virtual machine image.  A snapshot can be taken for two reasons;  1) if an administrator wants to copy the VMDK virtual machine, or 2)  if the administrator wants to apply updates or upgrades (update from Microsoft, application upgrades, etc) to the virtual machine. 

Deleting Snapshot Once the VMDK virtual machine has been copied successfully, using simply copy/paste commands against the VMDK Virtual machine, or once the updates/upgrades have been verified as having applied successfully, then the snapshot is customarily deleted.  Snapshot deletion will force ESX/ESXi Server to apply all queued updates/ upgrades (queued in the snapshot set of files) to the actual VMDK virtual machine.

Reverting to Snapshot If the updates/upgrades failed for some reason then the administrator can revert the VMDK virtual machine back to the point in time when the snapshot was originally taken.  If the VMDK virtual machine is reverted to the point in time when the snapshot was originally taken then all updates/upgrades after that point in time will be lost, including the failed updates/ upgrades.

Snapshot backups are indeed a handy tool for virtual machine management.   How many times have you applied an upgrade only to sadly find out that the upgrade failed and it needed to be backed out.

ESX/ESXi Server – Single Server Management Tools

The functionality and performance of VMware ESX and ESXi are the same; the difference between the two hypervisors resides in their architecture and operational management.  VMware ESXi is the latest hypervisor architecture from VMware. It has an ultra thin Linux kernel footprint with no reliance on a general-purpose OS, setting a new bar for security and reliability. The small footprint and hardware-like reliability of VMware ESXi enable it to also be available preinstalled on industry standard x86 servers.

ESXi Server is also available as a no-cost entry level hypervisor.  During my deployment of ESXi Server I found a lack of available information on when ESXi Server is free and at what point ESXi Server incurs a license fee.   Even internal VMWare personnel were unclear about the differentiation between an ESXi no-cost option versus ESXi Server available on a license fee basis. 

One can download ESXi Server for a 60 day evaluation trial period.  The 60 day trial provides one with a restricted function ESXi Server.  It is not always clear what features are restricted, however during my use it appears that functions relating to cloning and backing up of virtual machines are indeed restricted.  One can register their no-cost ESXi Server license to ensure one has a working ESXi Server longer than 60 days, however the functions relating to cloning and backup are still restricted.   The functions relating to cloning and backup appear to only be available once one licenses a VMWare product, such as VSphere Essentials, which includes what is referred to a VMWare Consolidated Backup (VCB).

VI Client The VI Client is a desktop application used to communicate with ESXi Server.   The VI Client can be used to configure an ESXi Server, monitor ESXi Server performance and take snapshot backups, however VI Client cannot easily be used to backup a virtual machine outside of a single ESXi Server environment.   With the VI Client, the best backup one can hope to achieve is taking a snapshot backup to an alternate hard drive, also attached to the same ESXi Server.   ESXi Server backups will be explorer in detail in another blog post.

Other available interfaces for managing the ESXi Server include the VI Command Level interface, essentially a batch like command level interface; commands being issued from a PC to the ESXi Server.

A Secure Shell (SSH) interface can also be enabledvia the ESXi console.   Once enabled, programs like PuTTY and WinSCP can be used to communicate with the ESXi Server.  SSH is available for diagnostic purposes (in theory), however I found the SSH interface to be essential for a stable on-going ESXi Server environment.  I have found PuTTY necessary for monitoring the Linux based file system.  I have had problems where the Linux based file system will fill up due to ESXi log file usage.   I have to login via PuTTY and move log file out of the base Linux file system using either Linux commands or WinSCP.  Once the Linux based file system starts filling up the ESXi Server will either become quite sluggish or an unexpected re-boots may occur.

In summary, I find essential single ESXi Server management tools to be VI Client, PuTTY and WinSCP.   With SSH enabled, I had very little use for the VI Client command level interface.  Having SSH enabled allows me to use PuTTY for what is essentially ESXi Server console access.   I can issue Linux commands and ESXi Server specific commands directly.

VMWare ESX Server Deployment


Over the next several weeks I will be making posts related to my recent experience of deploying VMWare ESX Server.  ESX Server is a bare metal hypervisor offered by VMWare.  Supported guest operating systems include just about any Windows or Linux based server based OS.  For me, I am initially deploying four instances of Windows Web Server 2008 R2.

My principal objective in deploying ESX Server was/is the ability to snapshot backup a running guest OS, thus simplifying software upgrades.  Other reasons include the ability to start-up a new guest server OS for any reason without the need for deploying new hardware.

The principal candidates in the virtualization marketplace include VMWare, Microsoft and the Citrix XEN offering.  I have always found Microsoft to be several steps behind the marketplace with respect to virtualization technology.  I was quite disappointed with Microsoft’s virtualization offerings for the desktop at the time of the Windows 7 release, and as a result I moved from Microsoft Virtual PC 2007 to VMWare’s Workstation 7.0 for my development environment.   I had my share of problems in moving to VMWare Workstation, however I now consider it a smart move.  Many of the issues encountered with the VMWare Workstation migration are outlined in my Sep/Oct 2009 blog posts.

I also had many problems in migrating to VMWare ESX Server, however again, I think it was worth the move.   The forthcoming blog posts will discuss some of the challenges.