Update: Virtual server backup


This article can also be found in the Premium Editorial Download "Storage magazine: Mobile cloud storage best practices."

Download it now to read this article plus other related content.

Rapid virtual server recovery

The next capability to expect from your virtual server backup app is the ability to recover a server very quickly or directly from the backup device. Some of the speed advantage of virtual server recovery

Requires Free Membership to View

derives from the way it encapsulates an entire server into a file. It’s faster to move a file back into place as a module than it is to reassemble that server from potentially thousands of files.

A few software applications have added the capability to recover only the blocks that need to be updated to satisfy a restore request. For example, if a VM needs to be recovered to how it looked five days ago, the software understands that only a percentage of the blocks within that virtual machine have changed during that time. This means the app knows that only those blocks need to be copied back, replacing newer blocks to make the VM look the way it used to. Essentially, this is CBT in reverse.

Another option, often called “recover in place,” is the ability to start a VM directly from the backup device. In every case we’ve seen so far, this means the backup target must be a disk device. With this capability, previous versions or copies of the current versions of a virtual server can be recovered within seconds. Some applications have the ability to automatically isolate the recovered VMs into a private virtual lab so they don’t conflict with production VMs. This brings a lot of flexibility for testing development code or a disaster recovery (DR) situation.

When comparing the two capabilities, CBT has the advantage of putting the VM back on production data storage very quickly but it may take a few moments to recover that virtual machine. Products with recover-in-place technology will have an advantage in their initial return to operations. However, because those VMs will have to initially execute from the backup, device runtime performance may be affected. Backup devices usually don’t offer the same availability as production data storage. This means that at some point the VM will have to be moved back into production via VMware Inc.’s Storage vMotion or a similar product.

Another consideration regarding recover in place is that the performance of the backup device becomes a key factor, making its ability to handle random I/O operations critical. While some access to the application is better than no access, if that application is so slow that it can’t be used, then recover in place is far less appealing than a changed block recovery. Ironically, all the features that make a backup device appealing, like high-capacity drives and data deduplication, may now become problematic. In no case is this considered a “deal breaker,” but it’s a scenario that should be tested and planned for.

This was first published in September 2012

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: