Common backup mistakes in virtualisation


Not Backing up Virtual Machines

Seems crazy, right? Failing to backup regardless of environment is an extremely risky proposition but generally, a majority of virtual machines aren’t backed up.

Here’s why:

  • Virtual Machine (VM) Sprawl: Most organizations don’t plan for enough storage when starting virtualisation projects and rarely consider rapid adoption and disaster recovery. Because virtual machines can be built with a few clicks of a mouse, they will be – especially in development labs for testing purposes, but also for full use in production environments. Often IT doesn’t have knowledge of all the VMs that exist or have knowledge but are unfamiliar with assets on their Recovery Point Objectives (RPO)/Recovery Time Objectives (RTO) requirements.
  • Backup Agents: The costs associated with backup agents can be prohibitive and quickly reduce the savings incurred through virtualisation. Every time a new backup software version is made available – there is usually an update required to every agent on every server.
  • Bandwidth Impact: There is often concern over dragging down the host machine and/or network by moving a lot of data for backup. The whole idea of virtualisation is to increase server utilisation/CPU utilisation/network utilisation and if you are successful, there is less “slack in the system” to handle backup loads.

Installing a Backup Agent on Every Guest

Many companies still backup virtual machines by installing a backup agent on every guest – a common strategy because of uncertainty about the ability to recover granularly, as well as other limitations. However, the impact of this approach is significantly higher costs from backup agents and unnecessary management complexity.

Today, virtualisation vendors (VMware, EMC, Microsoft) have improved APIs to support centralized backup with granular restore, and many vendors have the ability to backup at the hypervisor level – all making it unnecessary to install a backup agent on every guest for backup purposes.

Failing to Protect Applications

Failing to protect key applications is the easiest mistake and solution, yet is oddly still a common issue for many IT professionals. Backup is not just for files and data, but also key applications. If a disaster happens, the ability to restore the data in the application state will be important in terms of business continuity. Enterprise end users need applications and databases so when IT virtualizes these applications, it should also ensure they are backed up properly.

Failing to Consider Restore

Backup without the ability to ensure recovery means absolutely nothing – backup is nothing without recovery. In virtualised environments there are considerably more options to restore then in physical environments, so it’s not uncommon the backup of virtualised environments for recovery to be an after-thought.

When considering restore, IT needs to take into account what it wants to restore and its granularity. It’s also wise to consider where to restore to physical or virtual, onsite or offsite, etc.. IT needs to work with key stakeholders to consider objectives and the associated process for restore. It’s also a good idea to have a written plan that all stakeholders agree to, and to test that plan regularly.

Do you have disaster recovery plan? Is virtualisation part of your plan?

Advertisements

2 thoughts on “Common backup mistakes in virtualisation

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s