Posts tagged backup
vSphere Data Protection 5.1 Impressions
Sep 27th
With the release of vSphere 5.1, VMware has retired VMware Data Recovery (VDR) and replaced it with vSphere Data Protection (VDP). From my experience, there were not a lot of fans of the old VMware Data Recovery product, so this is a welcomed change. I decided to give it a spin, and see how it stacks up and what quirks there are in the first release.
Installation
The virtual appliance comes in three options that correspond to the size of the storage available to store backups: .5TB, 1TB, and 2TB. This sizing is a drawback as there is no way to increase the capacity of the appliance’s attached storage after installation other than adding another appliance.
The appliance can only backup to the attached VMDK, and it cannot backup directly to CIFS, etc. Of course, the CIFS space could be presented as an NFS share to the ESXi host(s) and then the VMDK stored on top, but this is rather kludgy.
Each vCenter can support up to 10 VDP appliances and up to 100 VMs per appliance (1000 total). It’s worth noting that this is the supported limit and not a hard limitation; VMware has not done testing beyond the aforementioned number and will not support more. vCenter 5.1 and the Web Client are required, but will work with ESX >=4.0 hosts.
There are some interesting aspects of the configuration:
- Password requirements: It requires an exactly nine character (no less, no more) password.
- DNS: Both forward AND reverse lookups must work.
Usage
Management is done through the vSphere Web Client, and is not possible through the classic Windows client. The interface is rather straight to the point with not a lot of flare or advanced features.
Deduplication is built-in, but only works within each appliance; for example, data backed up on appliance[n] will not be deduped against data on appliance[n+1].
When creating backup jobs, there is no built-in way to exclude certain VMDKs: it is all or nothing. Six concurrent backups can occur at a time. There is also no way to tell the job not to quiesce the guest, etc.
Only one backup per virtual machine can run each day, as there is no granularity for multiple backups per day. This may be a problem for some.
File-level recovery requires logging in to the appliance from the guest VM that needs the file restored. Individual files cannot be restored from the appliance in the same manner a full virtual machine can be restored. Compared to other products, this is a very different way to restore individuals files, and is rather inconvenient especially for Linux guests that don’t have a GUI. There is no way to restore from the command-line currently.
Overall
The actual functionality of VDP is solid on a great base with EMC Avamar’s engine, and it’s a good product despite the aforementioned. It is limited in what it can do in this release, lacking many simple features that are available in other products (selecting only certain VMDKs, multiple backups scheduled per day, better file level recovery, more granular options on jobs,etc). It is also missing the advanced functionality in other products (running from backup, catalogue of files, etc). It’s likely a great fit for many SMB environments that just need no-frills VM backups, but until it matures in certain areas it is probably best to stick with Veeam, PHD Virtual, or others for more advanced needs.
More Details
- VMware KB: VMware Data Protection (VDP) FAQ
- VMware KB: Required ports for vSphere Data Protection 5.1
- VMware vSphere Blog: Setting the record straight on VMware vSphere Data Protection
- Document: vSphere Data Protection 5.1 Release Notes
- Document: vSphere Data Protection 5.1 Administration Guide
PHD Virtual Backup for VMware – Review
Jun 24th
There are a lot of good virtual backup products out there, and in the past I have used many different flavors. I had not had a chance to work with PHD Virtual Backup personally yet, so I made it a goal of mine to give it a try. On several of the forums I frequent, I have heard great things about the product. One individual of note switched from another large player to PHD Virtual simply due to their great support in comparison to others, and another switched due to the scalability.
I’m going to try to skip too much of generic install, backup setup, restore setup, and other details since PHDVB offers videos and documents that detail these processes much better than I could. Instead, I hope to highlight some of the neat features and methodologies used.
Installation
The suite is packaged in an OVF template and runs on a customized Ubuntu build. Unlike others that require a Windows server, there is no need to pay extra for OS licensing. Since everything is self-contained, it is also one less OS install you have to manage. It also uses a PostgreSQL database, so no dependencies to MSSQL or MSSQL Express, which is a plus. This is very similar to the path VMware is taking with the vCenter Server Appliance.
To start out, you will need to install the console on your workstation, which adds the plugin to your vSphere Client.
 |
 |
Next up is the Virtual Backup Appliance, which is the engine of the product. Rolling out a Virtual Backup Appliance is as easy as deploying the OVF, configuring hypervisor credentials, and adding storage. It’s an extremely quick and easy process. Once finished, if you view the console for the new VBA, it will be a classic text-based interface that you will rarely need to touch again directly, as configuration is done through the vSphere Client PHDVB Console.
I did run into an odd issue where the filesystem on the appliance required a manual fsck. This required me to log into the console directly and run the command, but it was well documented on their knowledge base: PHDVBA contains a file system with errors, check forced.
The last piece to install is the PHDVB Exporter. This is a Windows application, which can reside on your BackupExec server for example, which takes the backups stored by the PHDVBA and converts them into OVF format for backup to tape. This is probably my favorite feature of the product, and will be discussed in greater detail later.
General Usage
This is an area where I think the other major players should learn from. As noted above, PHD Virtual Backup includes a plugin for the vSphere Client that allows the Administrator to manage backups directly within the client, instead of having to RDP to a Windows Server then open up a legacy console then manage everything from within there. Instead, if I need to work on backups then I can do it from the vSphere Client which I always have open anyway. This becomes truly awesome when you need to launch a one-off backup prior to a change or whatnot. It’s such a pain to create a one-off in other products that I tend to use snapshots more than I probably should.
The console itself, instead of a pane inside vCenter, launches a window on top of the vSphere Client from which you can manage some of the more granular items, such as Configuration and Licensing, as well as gain more control of the backup/restore/replicate functions.
Backup Jobs
Backup jobs are a straight-forward process in setting up, and backups work as expected in regards to speed, deduplication, scheduling, stability, etc. You can select which appliance performs the backups to increase efficiency, as well. The additional, special options for a backup job are:
- Verify backup: None/New blocks only/All blocks
- Backup Powered off virtual machines
- Set backups as archived (won’t be deleted via retention policy)
- Quiesce the VM before backing up (Windows only)
- Use Changed Block Tracking
Pretty standard stuff, and it works well. The only oddity I noticed is in regards to the backup retention policy, which is managed on a per-appliance basis instead of a per-job basis. This means if you want a different retention period for a special job, you need a different appliance to do it.
You can select three different options for Storage Type: Attached Virtual Disk, NFS, and CIFS. The neat one here is ‘Attached Virtual Disk’, where it allows you to add a VMDK to the appliance and use it as a backup repository. This is a neat way to utilize the local storage in your hosts, if you so choose; however, performance may be better storing the backups elsewhere. If there ever comes a time the VMDK needs expansion, it is as easy as expanding the disk and then rebooting the appliance; it will expand the actual partition automatically. They have released a white-paper on Storage Best Practices for PHD Virtual Backup that is worth checking out.
Restore Jobs
There are two recovery options: file-level and VM-level. The VM-level jobs are launched via the ‘Jobs’ tab of the Console, and file-level are launched via the ‘File Recovery’ tab. VM-level restores work as expected and restore directly; however, the file-level restores operate in a more unique manner. To restore individual files, an iSCSI target is created on the backup appliance and is then optionally automatically mounted onto the desktop kicking off the restore job. This is a pretty nifty way to access files, and works really well. With Windows, it’s more or less seamless and you will see a disk added that can be browsed to via Windows Explorer.
With Linux guests, it’s a little trickier. Since Windows doesn’t have built-in support for Linux filesystems, external tools are required. The PHDVB User Guide recommends to use either explore2fs or ext2explore (now renamed Ext2Read). Explore2fs claims support for ext2/ext3/LVM2, but has a new beta version called Virtual Volumes which adds support for ReiserFS. Ext2Read claims support for ext2/ext3/ext4/LVM. In the next release, the need for these tools will no longer be required as they’re implementing the ability to mount the backup to the VBA which can then be presented out using CIFS.
Exporter
As I mentioned earlier, this feature is the bee’s knees. The only downside is that it is not managed via the vSphere Client plugin, so it has to be on a Windows server and has a separate console. To start off, the option to share the backup folder via CIFS needs to be enabled on the VBA under the Connectors tab; it’s also worth mentioning, you can enable regular CIFS access inside the same tab in order to view your backups directly as well, but they will not be in OVF format. Once this is enabled, the Exporter Console on the backup server is used to create a job, which is then either stored in a Windows Scheduled Task or manually ran via the command line:
Once the job completes, you will find an OVF inside your specified Staging Location, along with a .txt file stating the VM name, time of backup, and source location. This OVF can be deployed via the typical ‘File -> Deploy OVF Template’ inside the vSphere Client without any requirement on the backup software. This feature will really shine if you have a large outage that also affects your backup infrastructure, whereas with other backup software you will need to reinstall their software.
Final Thoughts
I think it’s worth mentioning that replication is also included, and I have heard good things about it; however, due to my lab size I did not have a chance to give that a test. Finally, in closing, I think PHD Virtual Backup for VMware is a very neat product. My personal highlights that I recommend to check out if you give it a trial in your lab or business are:
- Ubuntu-based Appliance
- No requirement for MSSQL
- Ability to use Attached Virtual Disks for backup storage
- vSphere Client Plugin Interface
- Ease of file-level recovery via iSCSI target
- PHD Exporter transforming backups to OVF format
While there are neat highlights in other products as well, PHD Virtual Backup provides some really unique, handy methods of doing things, and is definitely a product to consider when designing your backup architecture.
Snapshot-based Backups and Virtualized Microsoft Applications
Apr 15th
There is a great post over on thelowercasew.com by Matt Liebowitz, which discusses Microsoft’s stance on virtual machine snapshots in respect to MSSQL and Exchange. The gist being that Microsoft will not support snapshots, and consequently virtual machines restored using this policy.
Some hypervisors include features for taking snapshots of virtual machines. Virtual machine snapshots capture the state of a virtual machine while it’s running. This feature enables you to take multiple snapshots of a virtual machine and then revert the virtual machine to any of the previous states by applying a snapshot to the virtual machine. However, virtual machine snapshots aren’t application aware, and using them can have unintended and unexpected consequences for a server application that maintains state data, such as Exchange. As a result, making virtual machine snapshots of an Exchange guest virtual machine isn’t supported.
Virtualization Snapshots for Hyper-V or for any virtualization vendor are not supported to use with SQL Server in a virtual machine. It is possible that you may not encounter any problems when using snapshots and SQL Server, but Microsoft will not provide technical support to SQL Server customers for a virtual machine that was restored from a snapshot.
As mentioned in the article, most popular virtualization backup tools (Veeam, PHD, BackupExec w/ VMware Agent) all use snapshots for their backup process. Why would Microsoft not support this if it is so popular? As mentioned by Microsoft, plain snapshots (e.g. snapshots taken from the vSphere client) are not application-aware. That’s a problem for applications like SQL and Exchange. Fortunately, backup vendors have added application-awareness into their products. Also, another issue that you may run into is related to the stunning of the VM when deleting a snapshot.
In addition to the above, it’s worth noting that a fairly large number of more novice users treat regular snapshots as backups. VMware’s Snapshot Best Practices (KB 1025279) reiterates that plain snapshots are not backups.
I can certainly see where Microsoft is coming from, and I doubt they will give you trouble if you restore a VM from a backup using one of the popular tools, despite the disclaimer. I predict most instances in which you would call Microsoft support, you would already have restored the VM and you’ve now encountered an issue inside the application. If you have a problem with the restore itself, you’re likely going to head to your backup vendor for support. Microsoft engineers are going to have a hard time telling exactly how you got to the point you’re at unless you explicitly tell them, so it might be worth keeping that close to your chest if possible. Of course, Microsoft support could always try to play hard ball, so it’s certainly worth keeping the fact they’ve stated they won’t support snapshots in mind.
With SQL servers, I have always chosen to back up SQL traditionally in conjunction with our virtualization-based backups, as well. I imagine most others follow the same practice.